OAuth 2.0

OAuth 2.0 is an open-standard authorization framework that allows a third-party application to obtain limited access to a user's resources on another service, such as an HTTP API. It does this by enabling the issuance of access tokens to clients, which act as temporary, scoped credentials, eliminating the need for users to share their long-term credentials like passwords. This fundamental separation of authentication (proving identity) and authorization (granting permission) is the core security principle of OAuth 2.0, making it the backbone of modern API security and single sign-on (SSO) systems.

The framework operates through a series of defined roles and flows (or grants). The key roles are the resource owner (the user), the client (the application requesting access), the resource server (the API hosting the protected data), and the authorization server (the service that issues tokens). Common flows include the Authorization Code Grant for web and mobile apps, the Client Credentials Grant for machine-to-machine communication, and the Implicit Grant (now largely deprecated). Each flow is designed for a specific client type and security context, dictating how the client requests and receives an access token.

A critical component of OAuth 2.0 is the scope mechanism. When a user authorizes an application, they grant permission for specific, limited actions defined by scopes, such as read:contacts or write:files. This ensures the principle of least privilege. The resulting access token is a bearer token, typically a JSON Web Token (JWT), which the client includes in API requests to the resource server. The resource server validates the token's signature and scopes before serving the request, ensuring the client only accesses what it was explicitly permitted to.

While OAuth 2.0 handles authorization, it is often paired with OpenID Connect (OIDC), an identity layer built on top of OAuth 2.0. OIDC adds an id_token to the flow, which is a JWT containing standardized claims about the user's authentication event and identity (like name and email). This combination allows an application to both verify a user's identity (authentication via OIDC) and gain permission to call APIs on their behalf (authorization via OAuth 2.0), forming a complete federated identity solution.

OAuth 2.0 is ubiquitous, powering the "Sign in with Google/Facebook/GitHub" buttons across the web and enabling secure API access for mobile apps, desktop applications, and server-side services. Its design addresses key security threats like credential leakage and token replay attacks through short-lived tokens, the optional use of refresh tokens for obtaining new access tokens, and the requirement for confidential clients (like web server apps) to authenticate themselves to the authorization server using a client secret.

The OAuth 2.0 authorization flow is a standardized sequence of interactions between four primary actors: the Resource Owner (user), the Client (third-party application), the Authorization Server (manages access), and the Resource Server (hosts protected data). The core objective is for the Client to obtain an Access Token, a credential representing the user's delegated permissions, which it can then present to the Resource Server. This process is defined by several grant types, with the Authorization Code Grant being the most common and secure for web and mobile applications.

In the Authorization Code flow, the user initiates the process by clicking "Login with [Service]" in the Client app. The Client redirects the user's browser to the Authorization Server, presenting its identity (client_id) and the requested permissions (scopes). The user authenticates directly with the Authorization Server and consents to the requested access. Upon approval, the Authorization Server redirects the user back to the Client with a single-use Authorization Code in the URL query parameters.

The Client then exchanges this Authorization Code for an Access Token by making a direct, server-to-server POST request to the Authorization Server's token endpoint. This request includes the code and the Client's client_secret, authenticating the Client itself. In response, the Authorization Server issues an Access Token (and often a Refresh Token). The Access Token, typically a JWT (JSON Web Token), is a short-lived credential that the Client includes in the Authorization header of subsequent API calls to the Resource Server to access the user's protected resources.

The OAuth 2.0 Authorization Code Flow is a server-side, multi-step process where a client application obtains an access token by first exchanging an intermediate authorization code. This flow begins when the user (resource owner) is redirected from the client app to the authorization server (e.g., Google, GitHub) to authenticate and grant consent. Upon approval, the server redirects the user back to the client with a short-lived, single-use authorization code in the URL query parameters. This design prevents sensitive tokens from being exposed to the user's browser or potential malicious actors.

The core security mechanism of this flow occurs in the back-channel exchange. The client application, using its own secure server, sends this authorization code along with its client secret back to the authorization server's token endpoint. In return, it receives the desired access token (and often a refresh token). Because the code is exchanged server-to-server over a confidential channel, the access token is never exposed to the public client-side environment. This makes the Authorization Code Flow the recommended choice for web applications with a backend server, where client credentials can be kept confidential.

Visualizing this flow typically involves a sequence diagram with four key actors: the User's Browser, the Client Application (split into frontend and backend), the Authorization Server, and the Resource Server. The diagram illustrates the critical redirects, the separation of the front-channel (browser redirects) from the back-channel (server-to-server POST requests), and the points where user consent and authentication occur. Key security features like the state parameter—used to prevent cross-site request forgery (CSRF) attacks—are highlighted as essential components of the initial authorization request.

For enhanced security, the PKCE (Proof Key for Code Exchange) extension is now mandatory for public clients (like mobile or single-page apps) and recommended for all. PKCE adds a step where the client creates a code verifier and a derived code challenge at the start of the flow. The verifier is later presented when exchanging the authorization code, binding the initial request to the token exchange and preventing authorization code interception attacks. This evolution shows how the flow's visualization must now include these additional cryptographic steps for modern implementations.

Understanding this visualization is crucial for developers implementing secure login features. It clarifies why the authorization code is a disposable intermediary, why the client secret must be protected, and how the separation of the frontend and backend responsibilities enhances overall system security. Mastery of this flow is foundational for working with OpenID Connect, which layers an identity layer on top of OAuth 2.0 to also return an ID token containing user profile information.

OAuth 2.0 is an open-standard authorization framework that enables a third-party application to obtain limited access to a user's resources hosted by a service provider, without exposing the user's long-term credentials. It operates on a centralized trust model where a single Authorization Server (e.g., Google, Facebook, GitHub) acts as the ultimate authority for issuing access tokens. This model delegates authentication and authorization to these centralized identity providers, creating a convenient but custodial relationship where the user's digital identity and access permissions are managed by the provider.

In contrast, Decentralized Identity (DID) is a paradigm where identity is controlled directly by the individual through cryptographic keys and verifiable credentials stored in a personal wallet, such as a mobile app. Core to this system are Decentralized Identifiers (DIDs), which are globally unique, persistent identifiers that do not require a centralized registry. Verification is achieved through Verifiable Credentials, which are tamper-evident digital claims issued by trusted entities and cryptographically signed, allowing for peer-to-peer proof without contacting the original issuer.

The primary distinction lies in the locus of control and trust. OAuth 2.0 centralizes trust in specific service providers, who become gatekeepers and potential points of failure or surveillance. Decentralized Identity distributes trust, enabling self-sovereign identity where users present proofs directly, minimizing data exposure and correlation. While OAuth excels at streamlining access to API resources within web2 ecosystems, DIDs are designed for portability, user-centric data sharing, and interoperability across different domains and blockchains without intermediary dependency.

Practically, OAuth 2.0 uses access tokens and refresh tokens to grant session-based access to specific scopes (e.g., read:email). A DID ecosystem uses DID Documents (describing the public keys and service endpoints for a DID) and Verifiable Presentations, where a user selectively discloses credentials from their wallet. For example, proving you are over 21 might involve an OAuth flow logging into a government portal versus presenting a cryptographically signed, privacy-preserving age credential from your digital wallet.

The evolution of digital identity may see hybrid approaches, such as OAuth 2.0-compatible DID layers or Self-Issued OpenID Connect Providers, which attempt to bridge the gap. However, the foundational philosophies remain opposed: one optimizes for developer convenience and integration within a centralized web, while the other architects for user sovereignty, data minimization, and censorship resistance in an open, decentralized digital landscape.