OAuth 2.0

OAuth 2.0 defines how a client obtains authorization to access a protected resource. Its principal roles are the resource owner, client, authorization server, and resource server. For example, a user authorizes a reporting application to read invoices, an authorization server issues an access token, and an invoice API accepts that token only for permitted operations. The client does not need to collect the user's password for the invoice system.

A common implementation uses bearer access tokens. The client sends a request with an Authorization header whose value is Bearer followed by the access token. A bearer token normally does not require the caller to prove possession of a separate cryptographic key, so a stolen token can be replayed until it expires or is otherwise rejected. Use HTTPS for authorization, token exchange, and API requests. Do not place access tokens in URLs, application logs, analytics events, or source code.

For browser and mobile applications, use the authorization code flow with Proof Key for Code Exchange, or PKCE. The application starts an authorization request, the user authenticates with the authorization server, and the application exchanges the returned code for tokens using its PKCE verifier. PKCE protects against intercepted authorization codes. Public clients cannot safely keep a client secret; embedding one in a mobile application or JavaScript bundle does not make it confidential. Validate redirect URIs strictly and use appropriate request correlation and CSRF protections, commonly including the state parameter. Avoid the legacy implicit and resource owner password credentials flows.

For service-to-service access without a user, a confidential client can use the client credentials grant. For example, a scheduled reporting job can authenticate to a token endpoint and receive an access token restricted to invoice-reading permissions. This represents the application's own authorization, not delegated authority from a signed-in user. Store client credentials in a managed secret store and rotate them rather than hard-coding them.

The resource server must validate the token before accepting a request. OAuth 2.0 does not require access tokens to be JSON Web Tokens, or JWTs. For a JWT access token, verify its signature with trusted issuer keys, restrict accepted algorithms, and validate the issuer, expiration, intended audience or applicable client binding, and required scopes. For an opaque token, an authorization server may provide an introspection endpoint. Merely decoding a JWT is not validation, and a signed JWT is not necessarily encrypted.

Scopes express permissions such as invoices.read, but they do not replace application-level authorization. A valid token with a read scope must not automatically allow access to every customer's invoices. The API must also enforce tenant boundaries, resource ownership, and business rules. Invalid or expired credentials generally produce HTTP 401, while valid credentials lacking sufficient permission generally produce HTTP 403.

Short access-token lifetimes reduce the window for replay but increase token renewal traffic. Refresh tokens can obtain replacement access tokens without repeating interactive authorization; protect them more carefully, and use rotation where supported. Revoking a refresh token does not guarantee that every API immediately rejects an already-issued access token, particularly when JWT validation is performed locally.

OAuth 2.0 is authorization, not an identity protocol. OpenID Connect adds an authentication layer and ID tokens; an ID token is not a substitute for an API access token. On AWS, a common design uses Amazon Cognito user pools to issue tokens and Amazon API Gateway to validate them and enforce scopes before invoking application code. This differs from AWS IAM authorization: an OAuth bearer token does not generally replace the AWS credentials and Signature Version 4 signing required for AWS service API calls.