JWT, OAuth 2.0, and API Keys

JWT, OAuth 2.0, and API keys are often mentioned together, so beginners can easily confuse them. They are three different mechanisms with different purposes, rather than three alternatives for the same task.

→JWT is a token format.
→OAuth 2.0 is a framework for delegated access.
→An API key identifies a client or integration.

For QA engineers, these distinctions provide a basic guide to access mechanisms, beyond architectural theory. Without them, it is difficult to locate the actual problem: the token, permissions, the process for obtaining access, or an unsuitable protection mechanism chosen by the team.

JWT

JWT, or JSON Web Token, is a compact token format that typically contains claims: statements about a user, client, or session. It is most often used as a bearer token: the client obtains a token and then includes it in requests.

Remember that JWT is neither authorization nor OAuth. It is a format for representing data in a token.

→sub: the subject
→iss: the token issuer
→aud: the intended audience
→exp: when the token expires
→iat: when the token was issued
→Roles, scopes, or other custom claims

JWT is convenient because it is compact and well suited to stateless scenarios. Those same properties can also lead to misuse. A common team mistake is treating JWT as trusted JSON that can simply be decoded and accepted as true. As a QA engineer, examine both the payload and how the system validates the token: its lifetime, issuer, audience, signature, revocation status, and whether it is being used outside its intended context.

JWT does not have to be encrypted. Very often, it is only signed, which means its payload may be readable. Do not assume that sensitive data is stored securely in a JWT simply because the string looks complicated.

OAuth 2.0

OAuth 2.0 is a framework that lets one system obtain limited access to a resource on behalf of a user or client without directly sharing a username and password. This distinction matters: OAuth addresses delegated access, beyond simply signing in.

For example, when an application requests access to your Google Drive or calendar, it often uses OAuth 2.0. The user authenticates with the provider and approves permissions, and the application receives a limited access token.

As a QA engineer, you do not need to memorize every grant type as a reference manual. Understand the logic:

→Who issues the token?
→Who requests it?
→Which resource does it provide access to?
→What scopes does the token have?
→How long is it valid?
→Can it be refreshed?
→How does token or access revocation work?

Beginners often assume that OAuth 2.0 itself authenticates the user. In practice, identity scenarios usually add OpenID Connect. If a team describes its implementation as an OAuth login, clarify where the identity layer sits and what the system accepts as proof of the user's identity.

API Keys

An API key is a simpler mechanism. It is usually a unique key that tells the system who is calling it: an application, client, partner integration, internal service, or script.

→Server-to-server integrations
→Restricting API access
→Tracking usage
→Rate limiting
→Distinguishing clients and subscription plans

Avoid overestimating API keys. They work well for client identification, but are generally insufficient on their own to protect sensitive user operations. An API key does not provide a complete user authorization model.

For QA engineers, the implication is straightforward: if a system protects high-risk actions with only an API key and no additional restrictions, examine that architectural choice carefully. This is particularly important if the key can easily be extracted from the client, logs, code examples, or CI configuration.

How their purposes differ

→JWT answers: what format is used to carry the token?
→OAuth 2.0 answers: how was access obtained, and under what conditions?
→An API key answers: which client or integration is making the request?

A real system can use them together.

→An access token can be a JWT.
→An OAuth flow can result in a JWT access token being issued.
→An individual internal service may use an API key instead of OAuth.
→A public API may require an API key to identify a subscription plan and a bearer token to access user data.

These mechanisms are compatible. They represent different layers of an access model.

What QA engineers should check

When testing JWT, examine:

→The token's lifetime
→Behavior after exp
→Whether aud and iss are correct
→The claims included
→How the system responds to a corrupted, tampered-with, or expired token
→Logout, revocation, and token refresh

When testing OAuth 2.0, examine:

→Whether the selected flow is appropriate
→Scopes and their restrictions
→The refresh flow
→Access revocation
→Redirect URI security
→Behavior when the user denies permission
→What happens when a token has been obtained but its permissions are insufficient

When testing API keys, examine:

→Where and how the key is transmitted
→Whether a revoked key can still be used
→Whether rotation and revocation are supported
→Whether rate limiting is in place
→Whether the key grants excessively broad access
→Whether it has leaked into client code, logs, or documentation

Practical example

Imagine a service that connects to a user's calendar.

If a user grants an application access to their calendar through Google or Microsoft, an OAuth 2.0 flow would be expected. After consent, the application receives an access token. That token may or may not be a JWT, depending on the implementation.

As a QA engineer, check that:

→The application requests only the scopes it needs.
→The user can deny access, and the system handles this correctly.
→The access token expires as expected.
→Token refresh works correctly.
→The application actually loses access after revocation.
→The token cannot be used for another resource or another user.

Building this integration around a single API key would represent a very different, and most likely inappropriate, security approach.

Key takeaways for QA engineers

→JWT, OAuth 2.0, and API keys are different mechanisms.
→JWT is a token format, rather than a complete access model.
→OAuth 2.0 is a framework for delegated access, beyond simply logging in.
→An API key usually identifies a client rather than an end user.
→A core QA skill here is understanding which problem each mechanism solves and where its limits lie.