JWT vs. OAuth 2.0

INSPYR Global Solutions, Technical Blog

JWT vs. OAuth 2.0

The title might suggest that we’re about to talk about a competition. No, we’re not—just kidding! But when it comes to security, there’s nothing to joke about.

Security is never something we can take for granted. In fact, we can never be too careful. Just ask Darth Vader and his Death Star!

At INSPYR Global Solutions (IGS), security is always a top priority. We continuously work to identify risks, strengthen our systems, and protect applications and data.

We even use AI to help identify potential vulnerabilities. This allows us to detect outdated third-party libraries, security weaknesses, and potential gaps that might otherwise escape the human eye. AI becomes another layer of protection, helping us build and release more secure and reliable systems.

With that in mind, let’s begin with a brief introduction to these two technologies.

1. Introduction to JWT

JSON Web Token (JWT) is a compact, URL-safe format used to represent claims between two parties. It is commonly used in web applications and APIs to transmit information about an authenticated user or client in a digitally signed token.

A JWT is especially useful for stateless authentication. After a user successfully authenticates, an authorization server or application can issue a token. The client then sends that token with subsequent requests, normally in the HTTP Authorization header.

2. JWT structure

A JWT normally consists of three Base64URL-encoded parts separated by dots:

  • Header: Describes the token type and signing algorithm.
  • Payload: Contains claims, such as the subject, issuer, audience, and expiration time.
  • Signature: Allows the recipient to verify that the token has not been modified and that it was signed by a trusted issuer.

Conceptually:

xxxxx.yyyyy.zzzzz

3. Example of JWT claims

A payload might contain claims similar to the following:

{

  “sub”: “12345”,

  “name”: “John Doe”,

  “iss”: “https://identity.example.com”,

  “aud”: “my-api”,

  “exp”: 1790000000

}

4. How JWT authentication works

  1. The user authenticates with an identity provider or application.
  2. The trusted issuer creates and signs an access token.
  3. The client stores the token according to the application’s security architecture.
  4. The client sends the token with an API request, commonly using Authorization: Bearer <token>.
  5. The API validates the token signature and relevant claims, such as issuer, audience, and expiration.
  6. If validation succeeds, the API can use the token claims to establish the caller’s identity and authorization context.

5. JWT security considerations

  • A JWT is encoded, not encrypted, unless additional encryption mechanisms are used. Do not put passwords or sensitive secrets in the payload.
  • Always validate the signature and important claims.
  • Validate expiration (exp), issuer (iss), and audience (aud) when applicable.
  • Use HTTPS to protect tokens while they are transmitted.
  • Keep access tokens short-lived when appropriate and use secure token storage on the client.
  • Do not treat possession of a JWT as proof that the token should be accepted without validation.

6. Introduction to OAuth 2.0

OAuth 2.0 is an authorization framework that allows an application to obtain limited access to resources on behalf of a user or another client, without requiring the client to know the user’s password.

OAuth 2.0 focuses primarily on delegated authorization. It defines how a client can obtain access tokens and use them to access protected resources.

7. Main OAuth 2.0 roles

  • Resource Owner: The entity that owns or controls the protected resource, commonly the user.
  • Client: The application requesting access to a protected resource.
  • Authorization Server: The server that authenticates the resource owner and issues tokens.
  • Resource Server: The API or service that accepts access tokens and protects resources.

8. Authorization code flow

For modern web applications, the Authorization Code flow with PKCE is a common OAuth 2.0 pattern. At a high level:

  1. The client redirects the user to the authorization server.
  2. The user authenticates and grants the requested permissions.
  3. The authorization server returns an authorization code to the client.
  4. The client exchanges the code for tokens, using PKCE where applicable.
  5. The client uses the access token to call the protected API.
  6. The API validates the access token and evaluates the permissions or scopes.

9. JWT vs. OAuth 2.0

Concept

JWT

OAuth 2.0

What is it?

A token format

An authorization framework

Primary purpose

Represent claims in a compact token

Delegate access to protected resources

Defines token format?

Yes

No; access tokens can use different formats

Can be used for APIs?

Yes

Yes

Authentication?

Can carry authentication-related claims

OAuth itself is primarily authorization; OpenID Connect adds an identity layer

10. Using JWT and OAuth 2.0 together

JWT and OAuth 2.0 are not competing technologies. They operate at different conceptual levels. OAuth 2.0 can define how an application obtains an access token, while JWT can be the format used for that token.

For example, a React frontend can authenticate through an identity provider using OAuth 2.0/OpenID Connect. The frontend receives an access token and sends it to an ASP.NET Core API. The API validates the bearer token and uses its claims and scopes/roles to determine whether the request is authorized.

11. Simple architecture

User → React Application → Identity Provider → Access Token → ASP.NET Core API → Protected Resource

In this architecture, OAuth 2.0/OpenID Connect describes the identity and authorization interaction, while JWT may be the representation of the access or identity token.

12. Key takeaways

  • JWT is a token format.
  • OAuth 2.0 is an authorization framework.
  • JWT and OAuth 2.0 can be used together.
  • OAuth 2.0 does not require JWT as its token format.
  • OpenID Connect adds an identity layer on top of OAuth 2.0.
  • APIs must validate tokens instead of merely decoding them.

At IGS, we believe that building reliable technology solutions requires more than adopting new tools. It also means understanding the technologies behind them and applying security practices throughout the development process.

By combining technical expertise, continuous learning, and emerging technologies such as AI, our teams continue to strengthen the way we approach application development and security.

Interested in working with teams that value technical excellence, innovation, and continuous learning? Explore our open positions at IGS and discover your next career opportunity.

Victor Manuel Labastida Flórez

Victor Manuel Labastida Flórez

Victor Manuel Labastida Flórez is a Developer at INSPYR Global Solutions with over 15 years of experience specializing in SQL and .NET technologies. He has worked on projects across industries such as finance, automotive, and consulting, applying his expertise to complex business environments. Outside of work, he enjoys learning about new technologies and spending time with his family.

Contact Us

We’re here for you when you need us. How can we help you today?

Share This Article

Related News & Insights

Learning by building: A new hackathon at INSPYR Global Solutions

Learning by building: A new hackathon at INSPYR Global Solutions

Beyond coordination: What tech teams really need

Beyond coordination: What tech teams really need

Building with AI, designing with judgment

Building with AI, designing with judgment: The responsibility that can’t be delegated

What no one says in the daily: The cost of silence in tech teams

What no one says on the daily: The cost of silence in tech teams

When AI speeds up the SDLC, delivery management has to change too

When AI speeds up the SDLC, delivery management has to change too