OAuth 2.0: Secure Third-Party Authorization

OAuth 2.0: Secure Third-Party Authorization

OAuth 2.0 is an authorization framework that allows applications to obtain limited access to user accounts on another service without sharing passwords. When you click "Login with Google" or "Login with Facebook," OAuth 2.0 is working behind the scenes. It enables users to grant third-party applications access to their data without exposing their credentials, solving a critical security problem in modern web development.

Before OAuth, applications would ask users for their passwords to other services, which was insecure and dangerous. OAuth replaces password sharing with tokens that have limited scope and expiration. To understand OAuth properly, it is helpful to be familiar with authentication mechanisms, JWT tokens, and HTTP protocol.

✓ What OAuth 2.0 is and why it matters
✓ Key OAuth roles: Resource Owner, Client, Authorization Server, Resource Server
✓ The four grant types (flows) for different scenarios
✓ Authorization Code Flow (most common)
✓ Access tokens and refresh tokens
✓ OAuth 2.0 vs OAuth 1.0 vs OpenID Connect
✓ Common OAuth mistakes and best practices

What Is OAuth 2.0

OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to a user's resources stored on another service. It allows users to grant access without sharing their passwords. The access is limited in scope (what actions can be performed) and duration (how long the access lasts).

OAuth 2.0 is not an authentication protocol. It is an authorization protocol. While it is often used for authentication (Login with Google), its primary purpose is delegated authorization. OpenID Connect builds on OAuth 2.0 to provide authentication.

You (Resource Owner) want to let a third-party app access your Google Drive files
Without OAuth: You give the app your Google password (dangerous!)
With OAuth: Google asks you "Allow this app to access your files?" You click Yes
Google gives the app a limited token, not your password

Why OAuth 2.0 Matters

• No Password Sharing: Users never give their passwords to third-party applications.
• Granular Permissions: Users can grant limited access (read-only, specific files, etc.).
• Revocable Access: Users can revoke access at any time without changing passwords.
• Time-Limited Tokens: Access tokens expire, reducing risk of long-term exposure.
• Industry Standard: Supported by Google, Facebook, GitHub, Microsoft, and thousands of other services.
• Improved User Experience: No need to create yet another account and password.

Key OAuth 2.0 Roles

OAuth 2.0 defines four distinct roles that interact in the authorization process. Understanding these roles is essential for implementing OAuth correctly.

You (Resource Owner) want to print photos from Google Photos
│
▼
Photo Printer App (Client) requests access to your photos
│
▼
Google Authorization Server asks: "Allow Photo Printer to access your photos?"
│
▼
You click "Allow" (grant authorization)
│
▼
Google Authorization Server issues an access token to Photo Printer
│
▼
Photo Printer uses the token to access your photos from Google Photos (Resource Server)

OAuth 2.0 Grant Types (Flows)

OAuth 2.0 defines several grant types (flows) for different application scenarios. Each grant type is designed for a specific use case.

1. Authorization Code Flow (Most Common)

The Authorization Code Flow is the most secure and most commonly used OAuth flow. It is designed for server-side web applications where the client secret can be kept confidential. The flow exchanges an authorization code for an access token, preventing the token from being exposed to the browser.

This flow is used by traditional web applications, server-side APIs, and most production OAuth implementations. It is the recommended flow whenever possible.

2. PKCE Flow (Proof Key for Code Exchange)

PKCE (pronounced "pixie") is an extension of the Authorization Code Flow designed for mobile apps and single-page applications. These applications cannot securely store a client secret, so PKCE uses a dynamically generated secret for each request. PKCE is now required for all OAuth 2.0 clients in many platforms.

3. Implicit Flow (Deprecated)

The Implicit Flow was designed for browser-based applications that could not store client secrets. It returns the access token directly in the redirect URL, which is less secure. This flow is now deprecated and should not be used. Use Authorization Code Flow with PKCE instead.

4. Client Credentials Flow

The Client Credentials Flow is used for machine-to-machine communication where no user is involved. The client application uses its own credentials to obtain an access token. This is commonly used for service accounts and backend APIs.

5. Resource Owner Password Credentials Flow (Deprecated)

This flow allows the client to collect the user's username and password and exchange them for an access token. This defeats the purpose of OAuth and is highly discouraged. It should only be used for legacy migration or trusted first-party applications.

Access Tokens and Refresh Tokens

OAuth 2.0 uses two types of tokens: access tokens and refresh tokens. Each serves a different purpose.

The separation of access and refresh tokens provides security. Short-lived access tokens limit the window of misuse if a token is stolen. Refresh tokens allow the client to get new access tokens without re-prompting the user, but they can be revoked centrally.

OAuth 2.0 vs OpenID Connect

When you see "Login with Google," you are using OpenID Connect (which uses OAuth 2.0 under the hood). When you see "Allow this app to access your Google Drive," you are using pure OAuth 2.0.

OAuth 2.0 Scopes

Scopes define the specific permissions the client is requesting. The user sees these scopes when approving access, and the client is limited to these scopes.

Google APIs:
- https://www.googleapis.com/auth/userinfo.email (read user's email)
- https://www.googleapis.com/auth/userinfo.profile (read user's profile)
- https://www.googleapis.com/auth/drive.readonly (read-only access to Drive)
- https://www.googleapis.com/auth/drive.file (per-file access to Drive)

GitHub:
- repo (full control of public and private repositories)
- read:user (read user profile data)
- user:email (read user email addresses)

Facebook:
- public_profile (read public profile)
- email (read email address)
- user_photos (read user photos)

Common OAuth 2.0 Mistakes to Avoid

• Using the Wrong Grant Type: Do not use Implicit Flow for mobile apps. Do not use Client Credentials for user-specific access. Choose the right flow for your application type.
• Not Validating Redirect URIs: Always validate and whitelist redirect URIs. Open redirects allow attackers to steal authorization codes.
• Storing Tokens Insecurely: Access and refresh tokens must be stored securely. Do not store them in local storage or client-side cookies without proper security.
• Not Using PKCE for Public Clients: Mobile and SPA applications must use PKCE. It is no longer optional on many platforms.
• Ignoring Token Expiration: Access tokens expire. Always handle token expiration and use refresh tokens to obtain new ones.
• Using OAuth for Authentication Without OIDC: OAuth alone does not provide authentication. Use OpenID Connect if you need to verify user identity.

OAuth 2.0 Best Practices

• Use Authorization Code Flow with PKCE: This is the recommended flow for all public clients (web, mobile, SPA).
• Keep Client Secrets Confidential: Never expose client secrets in client-side code. Use environment variables or secrets management.
• Validate Redirect URIs Strictly: Use exact matching, not prefix matching. Do not allow localhost in production unless necessary.
• Use Short-Lived Access Tokens: Access tokens should expire within minutes to hours, not days or weeks.
• Implement Token Revocation: Allow users to revoke access tokens and refresh tokens.
• Use State Parameter: The state parameter prevents CSRF attacks. Generate a random state value and validate it on callback.
• Log OAuth Events: Track authorization successes, failures, and token usage for security monitoring.

OAuth 2.0 vs OAuth 1.0

Frequently Asked Questions

1. What is the difference between OAuth and OpenID Connect?
   OAuth is for authorization (granting access to resources). OpenID Connect is for authentication (verifying user identity). OpenID Connect builds on OAuth 2.0 and adds an ID token containing user information.
2. What is the difference between OAuth and JWT?
   OAuth is an authorization framework. JWT is a token format. OAuth can use JWTs as access tokens, but JWTs can also be used independently. OAuth defines how to obtain tokens; JWT defines what the token looks like.
3. What is PKCE and when do I need it?
   PKCE (Proof Key for Code Exchange) is an extension to the Authorization Code Flow that protects against authorization code interception attacks. It is required for mobile apps, single-page applications, and any public client that cannot store a client secret securely.
4. What is a Bearer Token?
   A Bearer Token is any token that gives the bearer access to protected resources. The client simply presents the token in the Authorization header. Most OAuth 2.0 access tokens are Bearer Tokens.
5. Is OAuth 2.0 secure?
   OAuth 2.0 is secure when implemented correctly. Common vulnerabilities include open redirectors, CSRF (mitigated by state parameter), and token leakage (mitigated by using HTTPS and PKCE). Always follow best practices and use well-established libraries.
6. What should I learn next after OAuth 2.0?
   After mastering OAuth 2.0, explore OpenID Connect for authentication, JWT tokens, OAuth security best practices, and Single Sign-On (SSO) for enterprise authentication.

Conclusion

OAuth 2.0 is the industry standard for delegated authorization, enabling secure third-party access to user data without password sharing. Its flexible grant types support various application scenarios from server-side web apps to mobile apps to machine-to-machine communication. When combined with OpenID Connect, it also provides secure authentication.

Implementing OAuth 2.0 correctly requires understanding the roles, choosing the right grant type, and following security best practices. Use Authorization Code Flow with PKCE for public clients. Keep secrets confidential. Validate redirect URIs. Use short-lived access tokens. Always use the state parameter to prevent CSRF. With proper implementation, OAuth 2.0 provides a secure and user-friendly authorization experience.

To deepen your understanding, explore related topics like OpenID Connect, JWT tokens, OAuth security best practices, and Single Sign-On (SSO) for comprehensive authorization and authentication solutions.