{"componentChunkName":"component---src-templates-tag-js","path":"/tags/authorization-code-flow/","result":{"data":{"site":{"siteMetadata":{"title":"LoginRadius Blog"}},"allMarkdownRemark":{"totalCount":3,"edges":[{"node":{"fields":{"slug":"/engineering/guide-to-jwt/"},"html":"

Introduction

\n

Have you ever logged into a website by clicking “Login with Google” or “Sign in with Facebook,” without entering your password? Or used a web app that keeps you logged in even after closing your browser?

\n

These seamless experiences often rely on JSON Web Tokens (JWTs) — a way to authorize users after they have been authenticated.

\n

In today’s digital landscape, securing user identity and managing access is critical. JWT is a compact and secure method for transmitting claims between parties, typically used after authentication to handle authorization, session management, and secure API access.

\n

But what exactly is a JWT, how does it work, and why is it important? This blog offers a comprehensive explanation.

\n

What are Tokens and Why Are They Needed?

\n

Tokens are digital artifacts used in authentication systems to represent user identity. Instead of maintaining session state on the server, modern applications issue tokens to clients. These tokens are sent along with each request to authorize access to protected resources.

\n

When a user makes an authenticated request, the token is included in the request header. The server verifies the token’s validity—typically by checking its signature and expiration time. If the token is valid, access is granted. This approach supports stateless and scalable systems, compared to traditional session-based models.

\n

\"Illustration

\n

What is JWT (JSON Web Token)?

\n

A JWT (JSON Web Token) is a compact, self-contained token used to securely transmit claims between parties. JWTs are digitally signed using a secret (with HMAC) or a public/private key pair (with RSA or ECDSA).

\n

One of the main advantages of JWT authentication is that it doesn't require storing session data on the server—making it ideal for distributed applications.

\n

Types of JWT

\n

There are two main types of JWT based on how the payload is protected- JWS and JWE. Let’s learn more about them.

\n

JWS (JSON Web Signature)

\n

JWS is a type of JWT where the payload (data) is digitally signed, ensuring integrity and authenticity of the token.

\n\n

Use Case: Verifying that the data has not been tampered with.

\n

JWE (JSON Web Encryption)?

\n

JWE is a type of JWT where the payload is encrypted, ensuring confidentiality in addition to integrity.

\n\n

Use Case: Protecting personal or confidential information during transit.

\n

JWT vs JWS vs JWE – Comparison Table

\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Feature\n JWT (General)\n JWS (Signed JWT)\n JWE (Encrypted JWT)\n
Security Focus\n Token Format\n Integrity, authenticity\n Confidentiality + integrity\n
Payload\n Not specified\n Base64URL encoded (readable)\n Encrypted (not readable)\n
Signature\n Optional\n Required\n Encrypted along with payload\n
Encryption\n Optional\n Not encrypted\n Fully encrypted\n
Use Case\n ID and Access Tokens\n OAuth 2.0, OpenID Connect\n Highly sensitive information\n
\n

Note: JWT is the umbrella format. JWS and JWE are implementation types. The most commonly used JWTs in web apps are of the JWS type.

\n

Structure of JWT

\n

A JWT is composed of three parts:

\n
    \n
  1. Header
    2. \n
  2. Payload
    3. \n
  3. Signature
    4. \n
\n

Each part is Base64URL encoded and separated by a period (.).

\n

Example:

\n

<Header>.<Payload>.<Signature>

\n

1. Header

\n

The header typically includes the token type and the signing algorithm being used.

\n

{

\n

\"alg\": \"HS256\",

\n

\"typ\": \"JWT\"

\n

}

\n

2. Payload

\n

The payload contains the claims—statements about an entity (usually the user) and additional metadata.

\n

{

\n

\"iss\": \"https://lrSiteName.hub.loginradius.com/\",

\n

\"sub\": \"{uid}\",

\n

\"jti\": \"unique string\",

\n

\"iat\": 1573849217,

\n

\"nbf\": 1573849217,

\n

\"exp\": 1573849817,

\n

\"Key1\": \"value1\",

\n

\"Key2\": \"value2\"

\n

}

\n

Standard JWT Claims

\n\n

Note: The payload is not encrypted by default, and can be decoded by anyone. Do not include sensitive information unless using an encrypted JWT (JWE).

\n

3. Signature

\n

The signature ensures the token has not been altered. It is created by signing the encoded header and payload using a secret or private key.

\n

HMACSHA256(

\n

base64UrlEncode(header) + \".\" +

\n

base64UrlEncode(payload),

\n

secret)

\n

This helps validate the token’s integrity and authenticity.

\n

How Does JWT Work?

\n

JWT-based authentication typically follows this flow:

\n
    \n
  1. User Logs In
    2. \n
\n

The user provides login credentials (e.g., username and password).

\n
    \n
  1. Server Verifies Credentials
    2. \n
\n

The server validates the credentials against its data store.

\n
    \n
  1. JWT is Issued
    2. \n
\n

Upon successful login, the server issues a JWT signed with a secret/private key (post authentication).

\n
    \n
  1. Client Stores JWT
    2. \n
\n

The client stores the token (e.g., in localStorage, sessionStorage, or a secure cookie).

\n
    \n
  1. Token Sent on Requests
    2. \n
\n

The client attaches the token to the Authorization header (Bearer <token>) in future authorization/authentication API requests.

\n
    \n
  1. Server Validates JWT
    2. \n
\n

The server checks the token's signature, expiry, and validity.

\n
    \n
  1. Access is Granted
    2. \n
\n

If valid, the user is granted access to protected resources.

\n

This stateless model makes JWT ideal for scalable web and mobile apps.

\n

How to Use OAuth 2.0 with JWT

\n

OAuth 2.0 is an industry-standard protocol for authorization. It enables users to grant third-party apps access to their resources without sharing their credentials.

\n

When integrated with JWT, OAuth 2.0 uses JWTs as access tokens to represent the user's authorization.

\n

JWTs are commonly used as OAuth 2.0 access tokens—but not required by the specification. Some providers use opaque tokens instead.

\n

\"Illustration

\n

Why JWTs in OAuth 2.0?

\n\n

Implementation of JWT using LoginRadius APIs

\n

To implement JWT with LoginRadius:

\n

Step 1: Configure a JWT App

\n

Set up a JWT app in your LoginRadius Admin Console. Follow the JWT Admin Console Configuration guide.

\n

\"Illustration

\n

Step 2: Use APIs to Retrieve JWT

\n

If you are directly implementing your Login forms or already have an access token or want to generate a JWT based on email/username/Phone number or a password, you can leverage the following APIs:

\n\n

API Response Example:

\n

{

\n

\"signature\": \"<JWTresponse>\"

\n

}

\n

These tokens can then be used in your client app for authenticated requests.

\n

Best Practices for Secure JWT Authentication

\n

To implement JWT securely, follow these key practices:

\n
    \n
  1. Keep Signing Keys Secure
    2. \n
\n

Private keys or secrets used to sign JWTs must be stored securely.

\n
    \n
  1. Avoid Sensitive Data in Payload
    2. \n
\n

Payload is only base64 encoded—not encrypted. Do not include passwords, PII, or credentials unless using encrypted JWT (JWE).

\n
    \n
  1. Limit Token Claims
    2. \n
\n

Include only essential claims in the token to reduce size and exposure.

\n
    \n
  1. Use HTTPS
    2. \n
\n

Always transmit JWTs over HTTPS to prevent man-in-the-middle attacks.

\n
    \n
  1. Set Short Expiry Times
    2. \n
\n

Use short exp durations and implement refresh tokens to reduce impact if a token is compromised.

\n
    \n
  1. Implement Token Revocation
    2. \n
\n

Use jti with a blacklist or maintain a revocation strategy for enhanced control.

\n

Why Are JWTs Important for Authentication and Security?

\n

JWTs offer numerous benefits in authentication systems:

\n\n

JWTs are widely adopted in OAuth 2.0, OpenID Connect, and API security implementations.

\n

Conclusion

\n

JWT authentication is a robust, efficient, and secure method for protecting web and mobile applications. By understanding its structure, use cases, and best practices, you can confidently implement JWTs in modern authentication systems.

\n

Looking to implement JWT in your application? Check out the developer documentation to get started with seamless JWT integration using LoginRadius.

\n

FAQ’s

\n

1. What is the expiration time of JWT, and what is the measurement of time in JWT?

\n

A: By default, the expiry time of a JWT is 600 seconds (10 Minutes). It is shown in the form of seconds in the JWT configuration. The expiry time can be set from 1 second to 2592000 seconds (30 days) as per your use case.

\n

2. What is the difference between OAuth and JWT?

\n

A: OAuth is an authorization framework, that allows third-party apps to access user data without exposing their credentials.JWT is used at the end of authentication to securely transmit user info (identity and authorization). Use OAuth for delegated access; use JWT for stateless authentication and API authorization (verifying within your own system).

\n

3. How many types of JWT are there?

\n

A: JWTs mainly come in two types, with one being JSON Web Signature (JWS) and JSON Web Encryption (JWE). In JWS, the token’s content is digitally signed to protect it from tampering during transmission between sender and receiver. While the data is secure from modification, its contents (claims) can still be visible to others.

\n","frontmatter":{"date":"April 07, 2025","updated_date":null,"title":"Complete Guide to JSON Web Token (JWT) and How It Works","tags":["Oauth","Authorization Code Flow","Authorization","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.6528925619834711,"src":"/static/91ea5ae9cba0662d9830e037814a0409/58556/guide-to-jwt.webp","srcSet":"/static/91ea5ae9cba0662d9830e037814a0409/61e93/guide-to-jwt.webp 200w,\n/static/91ea5ae9cba0662d9830e037814a0409/1f5c5/guide-to-jwt.webp 400w,\n/static/91ea5ae9cba0662d9830e037814a0409/58556/guide-to-jwt.webp 800w,\n/static/91ea5ae9cba0662d9830e037814a0409/99238/guide-to-jwt.webp 1200w,\n/static/91ea5ae9cba0662d9830e037814a0409/7c22d/guide-to-jwt.webp 1600w,\n/static/91ea5ae9cba0662d9830e037814a0409/a5bb9/guide-to-jwt.webp 5115w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/what-is-oauth2-0/"},"html":"

Introduction

\n

Have you ever used \"Login with Google\" or granted an app permission to access your private files from the cloud? That’s OAuth 2.0 in action.

\n

OAuth 2.0 is a secure authorization framework that allows applications to access your data without having to share passwords. While often mistaken as an Authentication framework, OAuth 2.0 strictly deals with authorization, using access tokens to grant permissions to resources for a specified period.

\n

However, if you’re also unclear about how authentication differs from authorization? Check out our detailed blog: Authentication vs. Authorization.

\n

OAuth 2.0 is an important part of modern authorization. It helps platforms keep access controls secure and organized. It also makes it easy to manage user interactions.

\n

In this blog, we will break down how OAuth 2.0 works, why it is important and how it improves upon its predecessor, OAuth 1.0.

\n

What is OAuth 2.0?

\n

OAuth 2.0 is a token-based authorization framework that provides access to resources without sharing user credentials. Suppose you have some pictures in a cloud drive that you wish to print from a local photo printing shop. You can enable the print shop to access your photos in this drive without sharing your password by using OAuth 2.0 authentication.

\n

This keeps your account safe. It lets the shop access the information it needs. It also makes sure they cannot see anything else in your personal account. In essence, OAuth 2.0 serves the purpose of managing privacy and safety of your information as well as granting the permissions needed.

\n

Need for OAuth 2.0

\n

Before OAuth, users had to share actual credentials (username and password) with applications that needed to access their data. We all understand why this approach was risky.

\n

OAuth 1.0: The First Step Toward Secure Authorization

\n

OAuth 1.0 introduced a token-based system to eliminate this need for credential sharing. Users could now grant limited access to their data via tokens. However, OAuth 1.0 had these limitations:

\n\n

OAuth 2.0: A More Flexible and Scalable Solution

\n

OAuth 2.0 was not just an upgrade—it was a complete rewrite designed to be more developer-friendly, scalable, and secure.

\n

Key improvements included:

\n\n

With these improvements, OAuth 2.0 became the industry standard for authorization, used by platforms like Google, Facebook, and Microsoft.

\n

Key Differences Between OAuth and OAuth2.0

\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Feature\n OAuth 1.0\n OAuth 2.0\n
Architecture\n More complex, requires cryptographic signatures for every request.\n Simpler, uses access tokens for authorization.\n
Security\n Relies on request signing and shared secrets for security.\n

\nMedium\n

Focuses on token-based security with various grant types.\n

\nHigh (if implemented correctly)\n

Mobile Support\n Less suitable for mobile apps due to complexity.\n Designed with mobile apps in mind, offering simpler flows.\n
Token Handling\n Uses request tokens and access tokens, requiring more steps.\n Uses access tokens, refresh tokens, and authorization codes, depending on the grant type.\n
Scalability\n More challenging to scale due to complex signature requirements.\n Highly scalable and flexible, supporting various use cases.\n
User Experience\n Can be more cumbersome for users due to multiple steps.\n Offers smoother user experience with simpler authorization flows.\n
\n

\"Image

\n

How OAuth 2.0 Works

\n

The following parties are important to understand the process:

\n

1. User (Resource owner): Usually the end-user who has the data and grants permission.

\n

2. Client: The service or application seeking access to the user’s data.

\n

3. Authorization Server: The system that verifies the users and issues access tokens.

\n

4. Resource Server: The service or application that holds the user’s data and grants access only when a valid token is available.

\n

Basic OAuth 2.0 Flow:

\n
    \n
  1. The client seeks permission from the user to authorize access.
    2. \n
  2. The user is taken to the Authorization Server to grant or deny access.
    3. \n
  3. If approved, the Authorization Server provides an authorization code to the client.
    4. \n
  4. The client utilizes the authorization code to acquire an access token from the authorization server.
    5. \n
  5. The client uses the access token to request protected data from the Resource Server.
    6. \n
\n

This approach guarantees that the applications receive the exact permissions required from the resource owner without ever accessing the password.

\n

\"OAuth

\n

OAuth 2.0 Access Tokens and Authorization Code

\n

The access token is a temporary key that allows an application to access resources. It gets issued after a successful authorization code exchange and has an expiration time for security purposes. It is often paired with a refresh token, which allows for extended access without re-authentication.

\n

Getting Started with OAuth 2.0 Using LoginRadius

\n

Ready to implement OAuth 2.0? LoginRadius makes it easy to get started in just a few steps.

\n

1. Set Up Your Application

\n

Log into the LoginRadius Admin Console and go to Applications > Apps. Click Add Apps, name your app, choose OAuth 2.0 as the protocol, and select the appropriate app type (e.g., Native, SPA, Web, or M2M). Hit CREATE to generate the config.

\n

\"LoginRadius

\n

2. Configure OAuth Settings

\n

Fill in key fields like:

\n\n

Click Save when done.

\n

3. Enable Identity Providers

\n

Toggle on the login options (social or custom) your app will support. This gives users flexibility to sign in with their preferred IDP.

\n

4. Refresh Tokens When Needed

\n

Use the refresh token API to renew access tokens without making users log in again. Just pass the clientid, granttype, and refresh_token in a POST request.

\n

LoginRadius supports all major OAuth 2.0 flows, making it easy to build secure, scalable login across apps, APIs, and devices.

\n

Do check our technical documentation covers everything in detail—from authorization flows to token handling.

\n

What is an Authorization Grant, and What Are the Key Types?

\n

OAuth 2.0 offers different ways (grant types) for applications to obtain an access token, depending on their needs:

\n\n

Why Your Business Needs OAuth 2.0

\n

Safeguarding sensitive information should be a top priority in today’s digital world, and OAuth 2.0 makes it easier to minimize risks associated with security breaches by limiting applications to only the information they have access to.

\n

Businesses that manage large quantities of data or function in highly regulated markets need compliant OAuth 2.0 implementations to maintain trust and compliance. Implementing an OAuth 2.0 system brings the following advantages:

\n\n

Conclusion

\n

OAuth 2.0 has become the go-to authorization option due to its versatile support of multi-services, APIs, and websites and its capacity to ease secure access.

\n

Leveraging platforms like LoginRadius makes the design and maintenance of an OAuth 2.0 workflow much easier. It simplifies the authorization process for your users and your business's security, regardless if your company is using web apps, mobile apps, or APIs.

\n

Contact us today and book a live participation demo to see how you can improve your security infrastructure. Start here: to book a live demo.

\n

FAQs

\n

1. What is Open Authorization?

\n

A: Open Authorization (OAuth) is an open-standard authorization framework that allows applications to access a user's data without exposing their credentials. Instead of sharing passwords, OAuth uses access tokens to grant limited and secure access to resources.

\n

2. What are the key components of OAuth2?

\n

A: The key components of OAuth 2.0 include User aka Resource Owner, Client (Application), Authorization Server, Resource Server, and Access Token

\n

3. What is the auth token?

\n

A: An auth token (authentication token) is a digital credential used to verify a user's identity and grant access to a system without requiring repeated logins. It is typically a temporary, encrypted string issued by an authentication server after a successful login. Common types include OAuth 2.0 access tokens and JWT (JSON Web Tokens).

\n","frontmatter":{"date":"March 27, 2025","updated_date":null,"title":"A comprehensive guide to OAuth 2.0 ","tags":["Oauth","Authorization Code Flow","Authorization","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/10110df34137352f90a286528d35df2e/58556/what-is-oauth2-0.webp","srcSet":"/static/10110df34137352f90a286528d35df2e/61e93/what-is-oauth2-0.webp 200w,\n/static/10110df34137352f90a286528d35df2e/1f5c5/what-is-oauth2-0.webp 400w,\n/static/10110df34137352f90a286528d35df2e/58556/what-is-oauth2-0.webp 800w,\n/static/10110df34137352f90a286528d35df2e/99238/what-is-oauth2-0.webp 1200w,\n/static/10110df34137352f90a286528d35df2e/7c22d/what-is-oauth2-0.webp 1600w,\n/static/10110df34137352f90a286528d35df2e/a6559/what-is-oauth2-0.webp 4167w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},{"node":{"fields":{"slug":"/engineering/authorization-code-flow-oauth/"},"html":"

The Authorization Code Flow for OAuth 2.0 is targeted at web applications that have a server-side component, which allows the client secret for the authorization server to be kept secret (confidential client). Typically, authorization servers will require a secret to be used when making authentication requests if more sensitive data is wanted, such as personal data or refresh tokens. Without it, you would be restricted to following the Implicit flow for OAuth 2.0, which only returns an access token from the authorization server.

\n

In the Authorization Code flow, the server-side component of the web application can freely manage the user's session upon authenticating with the authorization server without revealing anything about the authorization server's response (such as personal data or refresh token) to the end-user.

\n

Overview

\n

\"Authorization

\n

The flow illustrated above aims to provide a rough overview of a typical Authorization Code workflow:

\n
    \n
  1. The Client-Server attempts to access a resource that requires authorization that it does not have. It redirects the user to the authorization server for authentication.
    2. \n
  2. The Authorization Server authenticates the user by asking for their login credentials. The server determines if the user should be granted or denied their request.
    3. \n
  3. If the User is determined to be authentic, an Authorization Code is issued and returned to the User Client. This code is used to retrieve an access token from the Authorization Server.
    4. \n
  4. The retrieved Authorization Code is sent to the Client-Server.
    5. \n
  5. The Client-Server makes a POST request to the Authorization Server, containing its client key, secret, and Authorization Code.
    6. \n
  6. The Authorization Server verifies the key, secret and code, and issues an ID Token and access token. The ID Token is a JWT that is typically used to store user data from the Authorization Server.
    7. \n
  7. The Client-Server receives and processes the ID token and access token. The access token is then kept in the Client-Server, which can request resources on behalf of the User Client without exposing the token itself.
    8. \n
\n

So you might ask yourself what the whole point of the Authorization Code is. At first glance, it would seem that the code is issued, only to be returned to exchange for an access token. The code is what allows us to keep the token hidden away from the User Client, which could be potentially exposed to malicious agents seeking to steal the token for nefarious means.

\n

In cases where you'd like the Authorization Server to return the access token immediately, you would use the Implicit flow for OAuth 2.0. Most authorization servers will limit the amount of data that can be returned using this flow; the OAuth 2.0 spec recommends limited scopes and short lifespans for tokens returned using this flow.

\n","frontmatter":{"date":"March 24, 2021","updated_date":null,"title":"Guide to Authorization Code Flow for OAuth 2.0","tags":["Oauth","Authorization Code Flow"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.492537313432836,"src":"/static/18d405bfac70941af3b7962d3d79073c/58556/unsplash.webp","srcSet":"/static/18d405bfac70941af3b7962d3d79073c/61e93/unsplash.webp 200w,\n/static/18d405bfac70941af3b7962d3d79073c/1f5c5/unsplash.webp 400w,\n/static/18d405bfac70941af3b7962d3d79073c/58556/unsplash.webp 800w,\n/static/18d405bfac70941af3b7962d3d79073c/99238/unsplash.webp 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}}]}},"pageContext":{"tag":"Authorization Code Flow"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}