OAuth 2.0 Flows and Token Types

OAuth 2.0 defines four roles. The Resource Owner is the user who owns data (e.g., their Google Drive files). The Client is the application requesting access. The Authorization Server issues access tokens (e.g., Google's OAuth server). The Resource Server hosts the protected data (e.g., Google Drive API). Understanding these roles clarifies each flow's purpose.

The authorization code flow is the correct flow for server-side web applications. The user authenticates at the authorization server, which redirects to the client with a short-lived authorization code. The client's server exchanges this code for tokens via a back-channel request. Tokens never pass through the browser, protecting them from browser history and referrer leakage.

The implicit flow was designed for browser-only JavaScript applications that could not securely store client secrets. Tokens were returned directly in the URL fragment, bypassing the back-channel. The implicit flow is deprecated in OAuth 2.1 because PKCE (RFC 7636) allows public clients to use the authorization code flow securely without a client secret.

The ROPC flow allows clients to collect the user's username and password directly and exchange them for tokens. This was intended for highly trusted first-party clients but fundamentally defeats OAuth's purpose of preventing apps from seeing user credentials. It is deprecated in OAuth 2.1 and should not be used in any new application.

The client credentials flow is for machine-to-machine (M2M) authentication where no user is involved. The client authenticates directly to the authorization server using its client ID and secret, receiving an access token for its own use. Common use cases: background jobs, microservice-to-microservice communication, API gateways accessing backend services.

The device authorization flow (RFC 8628) enables OAuth on devices with limited input capabilities: smart TVs, game consoles, printers, and IoT devices. The device displays a short code and URL. The user visits the URL on a phone or computer to authorize. The device polls the authorization server until the user completes authorization.

OAuth 2.0 defines two access token types. Opaque tokens are random strings that the resource server validates by calling the authorization server's introspection endpoint. JWT access tokens are self-contained: the resource server can validate them locally by verifying the signature, reducing introspection API calls but requiring key management.

Refresh tokens are long-lived credentials used to obtain new access tokens after the access token expires. Refresh token rotation (required in OAuth 2.1 for public clients) issues a new refresh token with each use and invalidates the old one. If a stolen refresh token is used, the legitimate client detects the invalidation, enabling detection of token theft.

RFC 7662 defines the token introspection endpoint, which allows resource servers to query the authorization server about an opaque access token's current status (active/inactive), scope, subject, and expiry. Introspection enables real-time token revocation: once a token is revoked at the authorization server, introspection calls immediately return active: false.

RFC 7009 defines the token revocation endpoint, allowing clients to notify the authorization server that a token (access or refresh) should be invalidated. This is used during logout or when a client detects suspicious activity. JWT access tokens cannot be fully revoked without a revocation list, because resource servers validate them locally without contacting the authorization server.

OAuth 2.0 scopes define the specific permissions the client is requesting. The authorization server presents the requested scopes to the user for approval. Resource servers enforce scope requirements per endpoint. Principle of least privilege applies: clients should request only the minimum scopes needed, and resource servers should reject requests with insufficient scope.

Which OAuth 2.0 flow is appropriate for a CLI tool or IoT device that needs to authenticate a user but has no browser or keyboard?

Authorization code flow is correct for server-side apps. Implicit flow is deprecated (use PKCE instead). ROPC flow is deprecated (eliminates OAuth's purpose). Client credentials serves M2M. Device authorization handles input-limited devices. Access tokens are opaque or JWT. Refresh tokens should rotate. Introspection (RFC 7662) and revocation (RFC 7009) complete the token management picture.