Note: You do not need to know this topic for the exam

OAuth gives users a way to let one application access data stored on another service without sharing their passwords. It solves a persistent problem. A third-party application may need limited access to an email address, contact list, or profile, but the user should not give it full account credentials. OAuth provides a controlled mechanism for granting narrow, temporary, revocable access to selected resources.

This is a brief overview of OAuth’s goals, the user experience, the basic authorization flow, and a few important extensions that are common in modern deployments.

Why We Need OAuth

Before OAuth, applications often requested a user’s account password for another service. That created obvious risks. It exposed the user’s entire account to the third party and gave the third party the ability to perform any action that the user could perform. It also made it difficult for the service provider to audit or limit access.

OAuth separates responsibilities. The service that owns the data authenticates the user. The requesting application receives only the specific permissions approved by the user.

What OAuth Provides

OAuth is an authorization framework. It is not an authentication protocol. It does not tell the client who the user is. Instead, it issues a token that represents the user’s approval to access selected data.

OAuth is built around two core ideas.

Redirection

A client application that wants access redirects the user to the service that holds the data. The user authenticates there, sees a consent screen, and decides whether to approve the request. The service then redirects the user back to the client with a short-lived authorization code.

Access Tokens

The authorization code can be exchanged for an access token. The token tells the resource server what the client is allowed to access. Tokens generally specify:

• the identity of the resource owner

• the scope of allowed operations

• expiration time and other usage rules

Clients use access tokens when contacting the resource server’s API. The user’s password is never shared with the client.

The Roles in OAuth

OAuth divides responsibilities among four actors:

• Resource Owner: the user controlling the data.

• Client: the application requesting access.

• Authorization Server: authenticates the user and issues tokens.

• Resource Server: provides access to the protected data.

The authorization server and resource server may be part of the same system or separate systems, but the division is conceptual and important.

Client Registration

Before a client can request access tokens, it must register with the authorization server. Registration typically includes:

• application name and type

• homepage URL

• redirect URI

• the list of scopes the client expects to request

The authorization server assigns a Client ID and, for confidential clients, a Client Secret. The client secret is used during the token exchange to prove that the request came from the registered application.

The Authorization Code Flow

The authorization code flow is the most common OAuth pattern for web applications. It keeps tokens out of URLs and ensures that the final token exchange happens through a secure back-channel.

1. User Initiates the Request

The user begins by choosing to connect or log in through another service. For example, a user may click a button labeled “Sign in with Google.”

2. Redirect to the Authorization Server

The client redirects the user’s browser to the authorization endpoint with parameters such as:

• client_id

• redirect_uri

• scope

• response_type=code

The user now interacts with the authorization server.

3. User Grants Permission

The authorization server authenticates the user and displays a clear consent screen. The user sees which permissions the client is requesting and can approve or deny them. If approved, the server redirects back to the client’s redirect URI with an authorization code.

4. Client Exchanges the Code for a Token

The client sends a back-channel request to the authorization server’s token endpoint. This request includes the authorization code, client ID, client secret, and redirect URI. The server validates the request and verifies that it came from the correct registered client.

5. The Authorization Server Issues an Access Token

The server replies with an access token and, in many cases, a refresh token. The access token has a short lifetime. A refresh token allows the client to obtain new access tokens without involving the user again.

6. Client Uses the Token

The client contacts the resource server’s API and presents the access token. If the token is valid and the requested resource is within the allowed scope, the resource server returns the data.

7. Client Establishes Its Own Session

Once the client obtains the necessary data, it creates its own session. After this point, interaction with the authorization server is no longer necessary.

Why OAuth Uses Authorization Codes

OAuth does not send access tokens through redirection. Instead, it uses short-lived authorization codes. That design prevents exposure of tokens in URLs, browser histories, logs, and referrer headers. It also ensures that the final step of obtaining the token requires proof that the requester is the registered client.

PKCE: Preventing Code Interception

Public clients such as mobile apps and single-page browser applications cannot safely store a client secret. To protect the authorization code, OAuth uses PKCE, which stands for Proof Key for Code Exchange.

PKCE adds two values:

• Code Verifier: a random string created by the client.

• Code Challenge: a hash of the code verifier sent during authorization.

When exchanging the authorization code for a token, the client must present the original code verifier. If an attacker intercepts the authorization code during redirection, it is useless without the verifier. PKCE is now considered mandatory for public clients and is widely used even in confidential clients for consistency.

Scopes and Least Privilege

Scopes define the specific actions that the client is allowed to perform. For example, an application may request access to a user’s profile but not their contacts. Scopes give users visibility into what a client will do and give service providers a way to implement least privilege. Good scope design is narrow and descriptive. An application should request only the scopes it actually needs.

Access Token Formats

An access token may be:

• an opaque string that only the authorization server can interpret, or

• a structured token such as a JSON Web Token (JWT).

OAuth does not mandate either format. Providers choose the format based on their architecture. Students should avoid assuming that all OAuth tokens are JWTs.

Refresh Tokens

Refresh tokens last much longer than access tokens. They allow the client to obtain new access tokens without requiring user interaction. Because refresh tokens provide long-term access, they must be stored securely and protected carefully. Public clients may not receive refresh tokens at all.

Token Storage and Security Considerations

Access tokens and refresh tokens are sensitive credentials. Clients must store them safely. Confidential server-side applications store tokens on the server. Browser applications should avoid insecure storage such as localStorage. The simplest rule is that tokens should never be accessible to untrusted script environments.

Deprecated Flows

Some tutorials often describe the implicit flow, which delivers tokens directly through the browser. That flow is now discouraged because tokens would appear in URLs and could be intercepted. The authorization code flow combined with PKCE is the modern replacement.

Token Revocation

OAuth provides a mechanism for revoking tokens. Either the user or the service provider can invalidate an access token or refresh token at any time. Revocation endpoints allow services to disable compromised or unwanted credentials quickly.

User Experience

To the user, OAuth is straightforward. They choose a service to authorize, see a consent screen that lists the requested access, and either approve or deny the request. Approval can be revoked at any time. The application never receives the user’s password.

Using OAuth to Support Authentication

OAuth is strictly an authorization framework. It does not define how to represent identity. However, some services expose a scope that returns basic profile information, such as email and name. If a client requests that scope, then the returned data can be used to identify the user.

This approach is common, but it is not a complete authentication protocol. Real authentication requires an identity layer that ensures:

• the user is who they claim to be

• the information has not been tampered with

• the client can validate the issuer of the identity data

This is what OpenID Connect provides. It sits on top of OAuth and adds standardized identity tokens, a user-info endpoint, and metadata describing the issuer. OAuth can support authentication-like behavior, but only with such an identity layer. Without it, the client receives information but cannot treat it as verified identity.

Conclusion

OAuth provides a practical method for delegating controlled access to user data across services. It relies on redirection, short-lived authorization codes, secure token exchanges, scopes, and clear separation of roles. PKCE strengthens the flow for public clients. OAuth can be combined with additional layers to support full authentication, but its core purpose is authorization.