OAuth 2.0

An Access Token is a credential used by a client application to access protected resources on behalf of a resource owner (user). It is a string, often a JSON Web Token (JWT), representing specific scopes and duration of access granted by the authorization server.

• Bearer Tokens: The most common type, presented as-is by the client. Possession alone grants access.
• Structure: Tokens can be opaque (random strings) or self-contained (JWTs containing claims).
• Lifespan: Typically short-lived (minutes/hours) to limit risk if compromised. Refresh Tokens are used to obtain new access tokens.

An Authorization Grant is a credential representing the resource owner's authorization. OAuth 2.0 defines several grant types for different client scenarios:

• Authorization Code Grant: For server-side web apps. The most secure flow, involving a client redirect to an authorization server and an exchange of an authorization code for a token.
• Client Credentials Grant: For machine-to-machine (M2M) communication where a client acts on its own behalf, not a user's.
• Refresh Token Grant: Used to obtain a new access token using a refresh token.

Other flows include Implicit Grant (deprecated) and Resource Owner Password Credentials (not recommended).

Scopes are space-separated strings that specify the exact permissions being requested by the client. They limit an access token's capabilities to a subset of the user's total permissions.

• Purpose: Implement the principle of least privilege. A token for read:contacts cannot delete contacts.
• Definition: Scopes are defined by the resource server (e.g., api:read, files:write).
• User Consent: During authorization, the user is presented with the list of requested scopes for approval.
• Token Validation: The resource server must validate that the token's scopes permit the requested action.

The Authorization Server is the central engine of OAuth 2.0. It authenticates the resource owner, obtains their consent, and issues access tokens to clients after successfully validating authorization grants.

Core Functions:

• Token Endpoint: Client-facing API that issues access and refresh tokens (used in Authorization Code and Client Credentials flows).
• Authorization Endpoint: User-facing endpoint where the resource owner authenticates and grants consent.
• Token Introspection Endpoint (RFC 7662): Allows resource servers to query the active state and metadata of a token.
• Client Registration: Manages pre-registration of confidential clients (those capable of securing a secret).

The Resource Server hosts the protected resources (APIs, user data) and accepts and responds to protected resource requests using access tokens. Its primary responsibility is to validate access tokens and enforce scopes.

Key Actions:

• Token Validation: Verify the token's signature (if a JWT), issuer, audience, and expiration.
• Scope Enforcement: Check that the token contains a scope permitting the requested HTTP method and endpoint.
• Policy Enforcement: Acts as the Policy Enforcement Point (PEP), denying requests with invalid or insufficiently scoped tokens.
• It relies on the authorization server for token issuance and introspection.

OAuth 2.0 defines clients based on their ability to maintain confidentiality of credentials, which determines which grant flows they can use.

• Confidential Clients: Capable of securely storing a client secret (e.g., server-side web applications). Can use the Authorization Code grant.
• Public Clients: Unable to store secrets reliably (e.g., single-page apps, native mobile apps). Use flows like Authorization Code with PKCE.

Key Security Profiles:

• Proof Key for Code Exchange (PKCE): Extension (RFC 7636) for public clients to prevent authorization code interception attacks.
• Native App Best Practices: Guidelines (RFC 8252) for implementing OAuth in mobile and desktop apps.

An identity layer built on top of OAuth 2.0 that adds authentication. While OAuth 2.0 provides authorization (access to resources), OIDC provides a standardized way for a client (like an AI agent) to verify the identity of an end-user and obtain basic profile information. It returns an ID Token (a JWT) containing user claims, complementing the OAuth Access Token used for API calls.

• Core Difference: OAuth 2.0 = Access Delegation. OIDC = Identity Verification.
• Key Artifact: The ID Token, which is a signed JWT containing user identity information (subject, name, email).
• Use Case: An AI agent uses OAuth 2.0 for authorization to call a calendar API, but uses OIDC first to authenticate which human user it is acting on behalf of.

A compact, URL-safe token format (RFC 7519) used to represent claims between two parties. In OAuth 2.0, Access Tokens and Refresh Tokens are often implemented as JWTs. A JWT consists of three parts: a Header (algorithm & token type), a Payload (the claims), and a Signature.

• Structure: Header.Payload.Signature, each part Base64Url encoded.
• Self-Contained: The signature allows the recipient to verify the token's integrity and authenticity without querying the authorization server (for stateless validation).
• Common Claims: sub (subject), exp (expiration), scope (authorized permissions), iss (issuer).

An OAuth 2.0 extension (RFC 7662) that allows a protected resource (like an API backend) to query the authorization server to determine the active state and metadata of an opaque access token. This is a critical check in a zero-trust model where the API gateway cannot trust the token alone.

• Process: The gateway sends the token to the authorization server's introspection endpoint. The server responds with a JSON object indicating if the token is active, along with its scope, client_id, and exp.
• Purpose: Enables centralized token revocation and real-time authorization checks.
• Contrast with JWT: Introspection is required for opaque tokens; JWTs can be validated locally if the gateway has the public key.

A space-separated list of strings that defines the specific permissions granted by an OAuth 2.0 access token. Scopes limit an application's access to a user's resources. In a zero-trust API gateway, every incoming request's token is validated to ensure its scopes permit the requested action on the target API endpoint.

• Example Scopes: read:calendar, write:contacts, admin:users.
• Granularity: Fine-grained scopes enable the principle of least privilege. An AI agent might only request read scopes for a task, never write.
• Policy Enforcement: The gateway maps API endpoints (e.g., POST /api/v1/users) to required scopes (e.g., admin:users) and denies requests where the token's scope set is insufficient.

The component in a policy-based architecture that intercepts access requests and enforces authorization decisions. In the context of OAuth 2.0 and zero-trust API gateways, the gateway itself acts as the PEP. It performs the critical functions:

• Intercepts all north-south API traffic from AI agents and other clients.
• Extracts the OAuth 2.0 bearer token from the Authorization header.
• Validates the token (via JWT validation or Token Introspection).
• Queries the Policy Decision Point (PDP) with user/agent identity, token scopes, and request context.
• Enforces the PDP's decision by allowing or denying the request before it reaches the backend service.

An OAuth 2.0 grant type used for machine-to-machine (M2M) authentication, where there is no direct user involvement. This is the most relevant flow for autonomous AI agents or backend services calling APIs on their own behalf (not impersonating a user).

• Process: The client (AI agent) authenticates with the authorization server using its own client_id and client_secret. It receives an access token directly.
• Token Use: The access token represents the application's own permissions, not a user's delegated permissions.
• Zero-Trust Context: API gateways must strictly validate tokens from this flow, as they often grant broad service-level access. Credentials must be managed via a secure credential management system.