OAuth 2.0

OAuth 2.0's core mechanism allows a resource owner (typically a user) to grant a client application limited access to their protected resources hosted by a resource server, without ever revealing their long-term credentials (like a password) to the client. This is achieved through an authorization grant, which the client exchanges for an access token. The token represents the scope and duration of the granted permissions, not the user's identity.

• Example: A user grants a photo printing app (client) permission to read their photos from Google Photos (resource server) but not to delete them or access their email.

Access in OAuth 2.0 is controlled through scopes. During the authorization request, the client asks for one or more scopes, which are space-separated strings defined by the resource server (e.g., read:photos, write:contacts). The user consents to these specific permissions. The resulting access token is only valid for the granted scopes, enforcing the principle of least privilege.

• Implementation: The token is presented to the resource server's API, which validates the token and checks that its scopes permit the requested action (e.g., a GET /photos request requires a token with the read:photos scope).

OAuth 2.0 defines several grant types (or flows) tailored to different client capabilities and security requirements. The choice of flow depends on whether the client can securely store a secret and the context in which it runs.

• Authorization Code: For web server applications. The most secure flow, involving a server-side exchange of an authorization code for a token.
• Authorization Code with PKCE: Essential for mobile apps and single-page applications (SPAs). Adds a proof key to prevent code interception attacks.
• Client Credentials: For machine-to-machine (M2M) communication where a client needs to access its own resources, not a user's.
• Resource Owner Password Credentials: A legacy flow where the user gives their username/password directly to the client. Not recommended for third-party clients.
• Device Code: For input-constrained devices like smart TVs, where the user authorizes on a separate device.

OAuth 2.0 promotes security through short-lived access tokens (often valid for minutes or hours). If an access token is compromised, its usefulness is limited. To maintain a session without requiring the user to re-authenticate constantly, the protocol provides refresh tokens. A refresh token is a long-lived credential issued alongside the access token, which the client can use to obtain a new access token when the old one expires.

• Security Benefit: This allows for periodic re-evaluation of the authorization grant and enables token revocation. Refresh tokens must be stored with the highest security, as they grant continued access.

A critical component of the OAuth 2.0 architecture is the authorization server. This trusted entity is responsible for authenticating the resource owner, obtaining their consent, and issuing tokens to the client. It decouples authentication logic from the resource server.

• Key Functions: Presents the consent screen to the user, validates authorization grants, issues access/refresh tokens, and often provides a token introspection endpoint for resource servers to validate tokens.
• Separation of Concerns: The resource server trusts tokens signed or issued by the authorization server, allowing for scalable, centralized identity and access management.

OAuth 2.0 primarily uses Bearer Tokens (defined in RFC 6750). A bearer token is a cryptic string, such as a JWT or an opaque reference, that grants access to the bearer—whoever presents it. The client includes the token in the HTTP Authorization header when calling a protected API: Authorization: Bearer <token>.

• Security Implication: This model is simple but means anyone in possession of the token can use it. Therefore, securing the token in transit (via HTTPS/TLS) and at rest is paramount. More advanced token types, like Proof-of-Possession (PoP) tokens, are emerging to bind a token to a specific client, mitigating theft risks.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth provides authorization (access to resources), OIDC provides authentication (verification of user identity). It standardizes how clients obtain basic profile information about the authenticated user.

• Core Component: The id_token, a JSON Web Token (JWT) containing verifiable claims about the user's identity (e.g., sub for subject, email).
• Standardized Endpoints: Adds the /userinfo endpoint to the OAuth flow to fetch standardized user attributes.
• Use Case: Enables "Login with Google" or "Sign in with GitHub" functionality, providing both access and verified identity.

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519, widely used as access tokens and id tokens in OAuth 2.0 and OpenID Connect flows.

• Structure: A JWT consists of three Base64Url-encoded parts separated by dots: Header.Payload.Signature.
• Self-Contained: The payload contains claims (statements about an entity), allowing resource servers to validate the token and its claims without a central database lookup.
• Signing: Typically signed using RS256 (RSA Signature with SHA-256) to ensure integrity. The signature is verified using the authorization server's public key.

Proof Key for Code Exchange (PKCE, pronounced 'pixy') is a critical extension to the OAuth 2.0 Authorization Code flow, designed to secure public clients like mobile apps and single-page applications (SPAs).

• Mitigates Attack: Prevents authorization code interception attacks where a malicious app could steal a code.
• Mechanism: The client creates a cryptographically random code_verifier and a derived code_challenge. It sends the challenge to get the code, and later must present the original verifier to exchange the code for a token.
• Mandatory for Public Clients: Modern security best practices and standards like OAuth 2.1 require PKCE for all authorization code grants used by public clients.

Identity and Access Management (IAM) is the overarching framework of policies and technologies that ensures the right entities (users, services, machines) have appropriate access to resources. OAuth 2.0 is a key authorization protocol within an IAM strategy.

• Broader Scope: IAM encompasses user lifecycle management (provisioning, de-provisioning), authentication, authorization, auditing, and federation.
• Models: Implements access control models like Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) to define permissions.
• For Agents: In AI agent contexts, IAM systems must manage machine identities, issue OAuth client credentials, and enforce scopes that limit an agent's access to specific APIs and data.

Single Sign-On (SSO) is an authentication scheme that allows a user to log in once and gain access to multiple, independent software systems without re-entering credentials. OAuth 2.0 and OpenID Connect are modern protocols enabling SSO.

• Federation: SSO is enabled by federated identity, where a trusted Identity Provider (IdP) (like Okta, Azure AD) authenticates the user and provides tokens to various Service Providers (SPs).
• Protocols: Can be implemented using SAML 2.0, OAuth 2.0, or OpenID Connect. Modern web and mobile apps heavily favor OAuth/OpenID Connect.
• User Experience: Eliminates password fatigue and centralizes authentication policy and multi-factor authentication (MFA) enforcement.

The Client Credentials Grant is one of the OAuth 2.0 grant types, designed for machine-to-machine (M2M) authentication where a specific user's context is not required. This is highly relevant for autonomous AI agents acting on their own behalf.

• Flow: The client application authenticates with the authorization server using its own credentials (client_id and client_secret) to request an access token directly.
• No User Involvement: There is no authorization step by an end-user. The token's permissions are defined by the scopes associated with the client registration.
• Use Case: An AI agent backend service calling a proprietary internal API or a third-party service where the agent itself is the authorized entity, not a human user.