Last updated on September 23rd, 2026 at 04:33 pm
I previously leaked an API key to GitHub. I spent Sunday panicking, rotating credentials, and reviewing access logs. That error saved me a whole library on API authentication that no tutorial could.
Authentication is no longer optional when building or integrating APIs. As a first-time dev shipping an endpoint or a security auditor, this guide helps you through the real thing. No nonsense; it is what I would have loved to hear 3 years ago.
Table of Contents
API Authentication Fundamentals
The bargain is this: authentication answers the question, “Who are you?” and authorization is permission: ” What can you do? Most API security attacks happen because developers are confused or absent-minded in implementation.
There are three broad descriptions in production that I have witnessed:
API Keys work like passwords. You create a string, send it in requests, and the server authenticates it. It is simple; it’s also very dangerous if you are not careful.
JWTs (JSON Web Tokens) are like tamper-proof identity cards. They contain user data and cannot be altered without detection. Great for stateless systems.
OAuth 2.0 is the valet key of auth. You grant restricted access to the machine without giving it the master key—ideal where third parties require regulated access to your API.
Each has its place. The secret is deciding which one fits your use case.
API Keys: When to Use and How to Secure
I still use API keys for internal services and basic integrations. They are not wicked–still, they are abused.
When API keys make sense:
- Internal service-to-service communication of your own services.
- Public read-only data (map, weather, etc. APIs, stock, etc.)
- Lighting prototypes use both extremes.
When they don’t:
- Anything touching user data
- Mobile lean code (keys can be ripped out of compiled Android code).
- Card: Third parties where you need fine controls.
Here’s how I secure them now:
First, never hardcode keys. I learned this the hard way. Use environment variables and secret management. I use them in my .NET projects, store them in Azure Key Vault, and retrieve them at runtime.
Second, rotate regularly. Set calendar reminders. I change critical keys every 90 days, and my process takes about 10 minutes.
Third, scope them down. When your API provider is allowing you to generate read-only keys, or restrict the keys to a particular IP address, do it. I used to have a key that could only access two endpoints- in case it leaked, there was a limit to the damage.
Monitor usage patterns. Drastic increase in new IP requests? Your canary in the coal mine.
JWT Implementation in APIs
My aha moment came when I learned how it’s structured. It consists of three parts divided by dots: header.payload.signature.
The header reflects which algorithm it was signed with. The message body contains your data (user identifier, authorization, expiry). The signature attests that no one has tampered with it.
What I like about JWT: You don’t have to do a database lookup with each request. All the identity information is in the token. This shortened my API response times and simplified my architecture.
The gotchas I hit: You can’t take back a JWT until it expires. Mine had a 15-minute expiration on access tokens. Users don’t notice because the system automatically retrieves and replaces them with new refresh tokens (stored securely).
Should not have sensitive information in a payload. JWTs are not encrypted but encoded. Anyone can decode and read them. I once saw a JWT containing an email address and a password reset token in plaintext. Don’t be that developer.
Here’s my current configuration: API calls use short-lived access tokens (15 min) and longer refresh tokens (7 days), delivered in HttpOnly cookies. After the access token expires, the refresh token receives a new one. If someone steals an access token, they have only 15 minutes.
Also, specify that the server must turn off the none algorithm, not just validate it. Attackers can strip signatures off with this ancient debugging option. All JWT libraries have the choice of blocking it- turn it on.
OAuth 2.0 for Third-Party Integrations
OAuth puzzled me for months before I came to see it not as authentication, but as permission delegation.
When you go to a website and click the Google Login button, you are not entering your Google password into the box. You are telling Google, “You know, Google, I would like this site to have access to my email address and profile picture. That’s OAuth.
Most web applications should use the Authorization Code Flow. This is how it is done, practice-wise:
The user is redirected to the OAuth provider (Google, GitHub, or whatever) with your app. There, they don’t stay on your site; they stay on theirs. The provider returns a temporary code. Your backend trades the code for an access token. You can now make API calls on their behalf.
I used this because one of the projects needed Google Drive. Most importantly, I knew which scopes you need. I requested only Drive. Read-only, since I didn’t need to write anything; ask for as few permissions as possible.
Common mistakes I’ve made:
Storing tokens in LocalStorage was prone to XSS attacks. I now save them in HttpOnly cookies, where JavaScript can’t access them.
Failure to validate the state parameter. This happens when CSRF attacks are prevented using this random string. Create one, redirect to the OAuth provider, store it, and when the user returns, validate that it matches.
The Implicit Flow was used as it appeared easier. It has been deprecated because it is easy to replicate tokens in URLs, as browser history and referers can leak them.
OAuth 2.1 is sweeping such problems away. PKCE (Proof Key for Code Exchange) is now compulsory, and this prevents attacks that intercept the codes. Today, when you are implementing OAuth, you should use the 2.1 spec.
API Security Checklist
The following are what I look at when an API is about to be launched:
Authentication layer:
- No embedded keys in the system (grep code deployed to main)
- Dev keys should not work in production; secrets should be environment-specific.
- Limit auth endpoint rate (prevent brute force attacks)
Token management:
- Expiry of access tokens (Expiry of access tokens in short bursts).
- Insecure storage of refresh tokens (Not secure backend storage)
- Authentication of tokens at all secured points.
Transport security:
- Encrypt everything (Free) Recently? HTTPS.
- HSTS headers enabled (forces HTTPS);
- Mobile app certificate pinning.
Access control:
- Minimal access control (users access as little as possible)
- Effective validation of the OAuth tokens.
- Checking fed to all endpoints (do not trust client data)
Monitoring:
- Failed login attempts.
- Alerts on abnormal access.
- Frequent API endpoint security controls.
This is the checklist in Notion, and I revise it before every release.
Protecting API Credentials in CI/CD Pipelines
This is where most leaks happen. To deploy your pipeline, run tests, and integrate with services, your CI/CD pipeline requires API keys. Yet the entire staff can see the pipeline logs.
What I do now:
Take secret management out of your CI/CD platform. GitHub Actions Industries has encrypted secrets. GitLab contains secure variables. Azure DevOps uses variable groups connected to Key Vault. Credentialing: It is recommended that you do not add credentials to your YAML files in a pipeline.
Limit scope: branch/Environment secrets. My API keys can be used in the production pipeline, and only in the production pipeline. Even if someone gets into my dev environment, they won’t be able to reach production.
Mask secrets in logs. Most platforms verify this, though it’s often done automatically. I have also seen API keys displayed in error messages that weren’t masked.
Rotate the secrets used in CI/CD regularly, as you do for production keys. I treat them as equal risk.
Work on limited service-account conditions. My deployment pipeline has an account that not only allows deployment to particular resources, but also doesn’t access customer data or edit other infrastructure.
Wrapping This Up
API authentication, however, is not as nightmarish as it appears. Start by understanding what each method does well—keywords toward straightforward inner things. JWT works well for stateless APIs with control on both ends. OAuth is for limited third-party access.
It is not about choosing the most secure option, but choosing what fits your situation and using it well. I’ve seen flawless deployments of OAuth and JWT systems that ended up being entirely flawed. The means take a back seat to the action.
When you are new, you can start with API keys for internal services. Get comfortable with secret management and rotation. If so, move to JWT for your APIs. Last but not least, address OAuth for third-party integrations. And please do not hard-code credentials. Establish appropriate secrets management nowadays. Your future will be grateful (as will your security team).
Read:
Token-Based Authentication: JWT, Session Tokens & Refresh Tokens
Multi-Factor Authentication (MFA) Explained: Types & Implementation
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
