What is OAuth: Authorization Without Sharing Passwords

Have you ever logged into a web application using your Google, Facebook, or GitHub account? If yes, you have already used OAuth. OAuth is an open standard for authorization that enables applications to access user data on another service — without the user revealing their password.

What is OAuth?

OAuth is an authorization framework that allows a third-party application to obtain limited access to a user's account on another service. Instead of the user entering their password into a third-party application, OAuth uses tokens that determine which data the application can access and for how long.

Everyday example: Imagine checking into a hotel. Instead of giving the receptionist the key to your house, you receive a card that grants access only to your hotel room. The card stops working at check-out. OAuth works similarly — the application gets a token for access to specific data, not your password.

Why Was OAuth Created?

Before OAuth, it was common practice for third-party applications to require usernames and passwords to access services like Gmail or Twitter. This posed several serious security issues:

1. Password exposure: Third-party applications could see and store user passwords in plain text
2. Overly broad permissions: Applications gained full access to the account, not just the data they needed
3. Difficult revocation: The only way to revoke access was to change the password
4. Compromise risk: If the third-party application was breached, user passwords were compromised

OAuth solves all these problems by introducing tokens and limited permissions (scopes).

Key Concepts

To understand OAuth, you need to know four main roles:

In addition to roles, the following concepts are important:

1. Access Token: A token that grants the application access to specific data. It has limited validity
2. Refresh Token: A token used to renew the access token when it expires, without requiring the user to log in again
3. Scope: Defines what data the application can access (e.g., read profile only, not send emails)
4. Authorization Code: A temporary code that the client receives and exchanges for an access token
5. Redirect URI: The URL where the user is redirected after successful authentication

OAuth Flow (Authorization Code Flow)

The most common type of OAuth flow is the Authorization Code Flow, used in web applications. Here is the step-by-step process:

Flow Types (Grant Types)

OAuth supports several different flows depending on the type of application:

Application Registration Example

For an application to use OAuth, it must first register with the service provider (e.g., Google, GitHub, Facebook). Upon registration, it receives:

# Example data the application receives upon registration

Client ID: 123456789012-abcdefghijklmnopqrstuvwxyz.apps.googleusercontent.com
Client Secret: GOCSPX-abCdEfGhIjKlMnOpQrStUvWxYz

# Redirect URI (where the user returns after login)
Redirect URI: https://example.org/auth/callback

# Scopes (permissions the application requests)
Scopes:
  - openid # For authentication (OpenID Connect)
  - profile # Read basic profile data
  - email # Read email address

Client Secret is the application's secret key and must be stored securely — it must never be exposed in client-side code (JavaScript in the browser).

OAuth vs. OpenID Connect

This is a common confusion that needs to be clarified:

Simply put: OAuth answers the question of authorization (can the application read your contacts), while OpenID Connect answers the question of authentication (are you really who you claim to be). Most modern "Login with Google" buttons use both together.

Common Security Mistakes

1. Improper redirect URI validation: If the server does not validate the redirect URI precisely, an attacker can redirect the authorization code to their own server
2. Exposed Client Secret: If the Client Secret is in client-side JavaScript code, an attacker can exploit it
3. Overly broad scopes: Requesting more permissions than the application needs violates the principle of least privilege
4. Not using PKCE: For mobile and SPA applications, PKCE is mandatory — without it, the flow is vulnerable to code interception
5. Improper token storage: Access tokens must be stored securely and never in the browser's local storage (localStorage)

Future of OAuth

The latest version of OAuth consolidates best practices and removes deprecated methods. Key changes include:

1. PKCE is mandatory for all authorization code flows
2. Implicit flow is completely removed
3. Password Credentials flow is removed
4. Bearer tokens have strict usage rules

The goal is to simplify implementation and remove variants that have proven to be insecure or overly complex.

Why Use OAuth?

OAuth has become the standard for secure authorization in modern web and mobile applications. Its main advantages are:

1. No password sharing: The user never enters their password into a third-party application
2. Limited access: The application only gets access to the data it needs
3. Easy revocation: The user can revoke permission at any time in their account settings
4. Better user experience: One-click login without creating a new account
5. Standardization: The same protocol is supported by Google, Microsoft, GitHub, Facebook, and many others

In a world where data breaches are a daily occurrence, OAuth offers a secure way to exchange data between applications — without risking password exposure. Every developer building applications with user authentication should understand the basics of OAuth.