OAUTH 2.0

OAuth 2.0 is an authorization framework that allows applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that account such as google, github, apple, etc.

Key roles

• Resource Owner: The user who owns the data (you)
• Client: The application requesting access (photo printing service)
• Resource Server: The API server hosting the protected resources (Google Photos API)
• Authorization Server: The server that authenticates the user and issues access tokens (Google’s OAuth server)

Grant Types(Flows)

OAuth 2.0 defines several “grant types” for different scenarios:

Authorization Code Grant

The most common and secure flow for web applications. Its flow is:

• User clicks “Login with Google” on the client app
• Client redirects user to authorization server with: client ID, requested scopes, redirect URI, and state parameter
• User authenticates and approves the permissions
• Authorization server redirects back to client with an authorization code
• Client exchanges the code for an access token (and optionally refresh token) by making a server-to-server request with client secret
• Client uses access token to call the resource server APIs

Implicit Grant

Originally designed for JavaScript-based apps (now deprecated in favor of Authorization Code + PKCE). The access token is returned directly in the redirect URI fragment, without an intermediate authorization code. Less secure because tokens are exposed to the browser.

Client Credentials Grant

For server-to-server authentication where there’s no user involved.The client authenticates with its own credentials (client ID and secret) to get an access token. Used for accessing its own resources or resources it’s been pre-authorized to access

Key Components

Access Token

A credential used to access protected resources. Typically short-lived (minutes to hours). The client includes it in API requests:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Refresh Token

A credential used to obtain new access tokens. Long-lived (days to months) and must be kept secure. Not all grant types provide refresh tokens.

Scopes

Scopes Define the specific permissions being requested. For example:

read:photos - read photo metadata write:photos - upload photos delete:photos - delete photos

State Parameter

A random value sent by the client and returned by the authorization server to prevent CSRF attacks.

PKCE (Proof Key for Code Exchange)

An extension that adds security for public clients (mobile/SPA apps) that can’t securely store a client secret. Uses a dynamically generated code verifier and challenge.

OAuth vs OpenID Connect

OAuth 2.0 is specifically for authorization (what can you access), not authentication (who you are). OpenID Connect (OIDC) is built on top of OAuth 2.0 to add authentication, providing:

• ID tokens that contain user identity information
• Standard user info endpoint
• Standardized claims about the user When you “Sign in with Google,” you’re typically using OpenID Connect, not pure OAuth 2.0.

Flow

• User → Client App: “I want to use this app”
• Client App → Authorization Server: “Redirect to login”
• Authorization Server → User: “Login & approve scopes”
• User → Authorization Server: Approves
• Authorization Server → Client App: Returns authorization code
• Client App → Authorization Server: Exchange code + secret for token
• Authorization Server → Client App: Returns access token
• Client App → Resource Server: API call with access token
• Resource Server → Client App: Returns protected data