Authentication and authorization are core concepts in identity and access management (IAM), which are often confused with each other. While both relate to identity security, they aren’t interchangeable.

• Authentication verifies who a user is.
• Authorization determines what the user can do.

You log in to GitHub (authentication), then try to delete someone else's repository. GitHub knows who you are, but stops you (authorization).

Authentication must happen first: You prove your identity. Authorization happens next: Your permissions determine what you can access.

Authentication answers: “Who are you?”

Before your application lets anyone in, it needs to verify their identity. When users sign in, you’re validating credentials (or other factors) to confirm they are who they claim to be. Authentication always comes first. You can’t decide what someone can access until you know who they are.

Think of authentication like airport security. You show your ID to prove your identity, and the agent verifies you are who your ID claims you are.

• Password-based authentication: Users provide credentials validated against stored records. Passwords alone are increasingly insufficient for modern security requirements.
• Passkeys: Users authenticate with cryptographic keys locally protected through biometrics or device PINs. Passkeys are phishing-resistant FIDO credentials, offering faster, easier, and more secure sign-in than traditional passwords.
• Social logins and federated identity: Users authenticate through external, trusted providers (like Google or GitHub) using OpenID Connect (OIDC). This delegates identity verification to specialized identity providers (IdPs).
• Single sign-on (SSO): Users authenticate once to access multiple applications without having to reenter their credentials. This improves user experience (UX), particularly in enterprise environments.
• Multi-factor authentication (MFA): Combines multiple verification factors (e.g., knowledge, possession, inherence) to strengthen security.

When a user requests application access:

Authorization determines what authenticated users are allowed to do within a system. Common approaches include:

Authorization in practice

Consider a project management application:

• Authentication confirms that the user is Alex.
• Authorization determines that Alex (in a project manager role) can view all development team projects, but cannot delete projects or access billing settings.

When working with modern protocols, it’s crucial to understand the distinctions between AuthN vs. AuthZ.

OAuth 2.0 is an authorization framework. It is not an authentication protocol.

OAuth 2.0 provides a standardized way for a client application to obtain an access token from an authorization server (with a user’s consent) to access protected resources. It was designed for delegated authorization, allowing users to grant third-party applications limited access to their resources without sharing their passwords.

Enter OpenID Connect (OIDC)

OIDC is an interoperable authentication protocol built on top of the OAuth 2.0 framework. It simplifies the process of verifying user identity based on authentication performed by the authorization server.

It addresses what OAuth 2.0 doesn’t provide:

• It defines the ID token: A standardized security token (encoded as a JWT) that serves as proof that the user has been authenticated
• It standardizes user identity claims (like name and email)

In modern architectures:

• OAuth 2.0 handles authorization (delegating access to resources)
• OpenID Connect handles authentication (confirming user identity)

Both protocols typically work together in the same flow.

Modern applications are distributed systems built around APIs and have become a primary means of accessing resources.

The fundamental shift: APIs don’t authenticate users directly. They validate tokens and enforce API authorization.

How token-based authentication works

1. The user authenticates with an authorization server (identity provider).
2. Server issues tokens after validating identity:
   • ID token (authentication): User identity information. The client uses this to determine who signed in.
   • Access token (authorization): Authorization information (scopes, permissions). The API uses this to determine what the user can access.
3. Client makes API calls with the access token in the [Authorization: Bearer] header.
4. The API validates the token and enforces authorization rules based on the claims contained within.

Understanding JWT authentication

JSON Web Tokens (JWTs) are the most common token format. They are self-contained, carrying all necessary information embedded within the token itself.

A JWT is comprised of a header, payload (claims), and signature.

JWT validation: What the API must verify

When an API receives a JWT, validation is non-negotiable. Skipping any of these validations creates application security vulnerabilities.

Five essential validation checks:

1. Token structure: First, verify that the token matches the structure of a JSON Web Token
2. Token integrity: Verify the token hasn’t been tampered with by checking the signature
3. Token expiration: Check to see if the token has expired, as defined by the exp claim
4. Expected authority: Confirm the token was issued and signed by the expected sender
   1. Compare it to the iss claim (issuer)
   2. Verify the key used to sign the JWT belongs to the expected authority
5. Expected audience: Confirm the token is intended for your application, and the aud claim is a match with the value identifying your application

JWT vs. opaque: The trade-offs

OAuth 2.0 doesn't mandate a specific access token format. While JWTs are popular, an alternative is the opaque token, a random string that contains no embedded information about the user or the token itself.

Both are valid OAuth 2.0 implementations. Many systems use JWTs with short expiration times and refresh token rotation to balance performance and security.

The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the most secure OAuth 2.0 flow for web and mobile applications, demonstrating how AuthN and AuthZ work together. Using PKCE protects the flow from interception attacks.

1. User initiates login: The application redirects the user to the authorization server with request details (client ID, scopes, PKCE code challenge).
2. User authenticates: The user signs in via the hosted login page. Authentication is complete.
3. Authorization code issued: The user is redirected back to the app with a short-lived authorization code.
4. Token exchange: The app’s backend exchanges the authorization code for tokens, sending the PKCE code verifier. The server issues the ID token (AuthN) and the access token (AuthZ).
5. API access: The app includes the access token in request headers when calling protected APIs.
6. Token validation and enforcement: API validates the access token and enforces permissions based on its claims, ensuring proper authorization.

Security considerations for developers

Building secure applications requires understanding the distinction between authentication and authorization:

Implementation checklist

• Use OpenID Connect for user authentication
• Use OAuth 2.0 for delegated authorization
• Validate JWTs server-side on every API request
• Return 401 for authentication failures, 403 for authorization denials
• Use the Authorization Code Flow with PKCE
• Store tokens securely (HttpOnly cookies)
• Use short-lived access tokens with refresh token rotation

For a deeper dive into token types, learn the difference between the ID token and the access token.

Using a service like Auth0 can simplify the implementation of both authentication and authorization, enabling developers to concentrate on their core application logic. Explore our Intro to IAM series for additional topics related to identity and access management.

Learn more

These materials are intended for general informational purposes only. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors and should not rely solely on the information provided herein.