OAuth 2.0

The primary, most secure flow for server-side web applications. It involves a two-step process where the client first receives an authorization code via the user's browser, then exchanges this code for an access token and a refresh token via a secure back-channel request from the server.

• Use Case: Traditional web applications with a backend server.
• Security Benefit: The access token is never exposed to the user's browser or public client.
• Key Components: Redirect URI, authorization code, client secret.

An extension of the Authorization Code flow designed for public clients that cannot securely store a client secret, such as mobile apps and single-page applications (SPAs). It uses a Proof Key for Code Exchange to prevent authorization code interception attacks.

• PKCE Mechanism: The client creates a cryptographically random code_verifier and sends a derived code_challenge with the initial request. It must later present the original code_verifier to exchange the code for a token.
• Use Case: Native mobile apps, JavaScript-based SPAs.
• RFC Standard: Defined in RFC 7636.

A machine-to-machine (M2M) flow where a client application uses its own credentials to authenticate directly with the authorization server and obtain an access token. This flow does not involve a user context.

• Use Case: Service accounts, daemons, backend microservices communicating with other APIs.
• Token Scope: The access token is scoped to the client's own permissions, not a user's.
• Authentication: Typically uses a client ID and client secret (or a signed JWT).

A flow designed for input-constrained devices that lack a browser or easy text input, such as smart TVs, gaming consoles, or IoT devices. The device initiates the flow and provides a user code and verification URI for the user to complete authorization on a secondary device.

• Process:
  1. Device requests a user code from the authorization server.
  2. Device displays the code and URI (e.g., https://example.com/activate).
  3. User visits the URI on a phone/computer, enters the code, and consents.
  4. Device polls the authorization server until the user completes the step, then receives tokens.
• Use Case: Devices with limited input capabilities.

A flow where the user provides their username and password directly to the client application, which then exchanges them for an access token. This flow is highly discouraged due to significant security risks.

• Risks: The client application gains direct knowledge of the user's long-term credentials, violating core OAuth principles. It should only be used when other flows are impossible.
• Limited Use Case: Migrating legacy systems to OAuth 2.0, or for highly-trusted first-party clients (e.g., a company's own mobile app).
• Deprecation: Modern security best practices strongly favor the Authorization Code flow with PKCE instead.

A legacy flow where the access token was returned directly in the URL fragment of the redirect URI after user consent, without an intermediate authorization code. This flow is now obsolete and deprecated in the OAuth 2.1 specification due to inherent security vulnerabilities.

• Security Flaws: The access token is exposed in the browser history and to any JavaScript on the page, making it susceptible to theft.
• Modern Replacement: The Authorization Code Flow with PKCE provides the same client profile support (SPAs) with vastly improved security and is the required standard for public clients.
• Historical Context: Was once recommended for single-page applications before PKCE was standardized.

OpenID Connect is an identity layer built on top of OAuth 2.0. While OAuth provides authorization (permission to act), OIDC provides authentication (verification of identity). It standardizes how clients receive identity information about the end-user.

• Core Component: The ID Token, a JSON Web Token (JWT) containing verified user claims (e.g., name, email).
• Flow: Uses the OAuth 2.0 Authorization Code flow, adding an openid scope and the id_token response.
• Use Case: Enabling Single Sign-On (SSO) across multiple applications by providing a standardized way to verify user identity.

A JSON Web Token is a compact, URL-safe token format defined in RFC 7519. It is the de facto standard for representing OAuth 2.0 access tokens and OpenID Connect ID tokens.

• Structure: A string with three Base64Url-encoded parts separated by dots: Header.Payload.Signature.
• Payload: Contains claims—statements about an entity (e.g., user, client) and additional metadata like issuer (iss), subject (sub), and expiration (exp).
• Self-Contained: The signature allows a resource server to validate the token's integrity and authenticity without a call to the authorization server, provided it has the correct public key.

PKCE (pronounced "pixy") is a critical security extension (RFC 7636) to the OAuth 2.0 Authorization Code flow, designed to protect public clients like mobile apps and single-page applications (SPAs).

• Mechanism: The client creates a cryptographically random code verifier and derives a code challenge from it. The challenge is sent with the initial authorization request; the verifier is sent when exchanging the authorization code for a token.
• Threat Mitigation: Prevents authorization code interception attacks where a malicious actor steals the code from a public client.
• Requirement: Now considered mandatory for all authorization code flows involving public clients.

The Client Credentials flow is an OAuth 2.0 grant type designed for machine-to-machine (M2M) communication where no end-user is involved. A client application authenticates with its own identity to access its own protected resources.

• Process: The client sends its client_id and client_secret directly to the authorization server's token endpoint to receive an access token.
• Token Scope: The access token is scoped to the permissions assigned to the client application itself, not delegated from a user.
• Typical Use: Backend service calling another internal or partner API, automated daemons, and cron jobs.

A Bearer Token is the most common type of OAuth 2.0 access token. The term "bearer" means anyone in possession of the token (the "bearer") can use it to access associated resources.

• Transmission: Sent in the HTTP Authorization header: Authorization: Bearer <token>.
• Security Implication: This model requires strong transport-layer security (TLS/HTTPS) to prevent token interception. If a token is leaked, it can be used by an attacker until it expires or is revoked.
• Validation: The resource server must validate the token's signature, expiration, issuer, audience, and scopes before granting access.

In OAuth 2.0, a scope is a mechanism to limit an application's access to a user's account or a client's permissions. Scopes represent a specific subset of access rights.

• Definition: A space-separated list of case-sensitive strings defined by the authorization server (e.g., read:contacts, write:files).
• Consent Screen: Presented to the user during authorization, allowing them to see and approve the specific permissions requested.
• Token Binding: The granted scopes are embedded within the access token. The resource server must check that the token contains a scope permitting the requested action before fulfilling the API call.