OAuth: How Secure Third-Party Login Works

OAuth

OAuth is the industry-standard authorization framework that powers "Login with Google", "Login with Facebook", and thousands of API integrations, all without ever sharing your password with third-party apps. It is the protocol behind the connected app ecosystem that most of us use every day without thinking about it.

What Is OAuth

OAuth, which stands for Open Authorization, is a protocol that allows one application to access resources in another service on behalf of a user, using access tokens instead of credentials. The user grants permission through a consent screen, and the third-party app never sees or stores the password. The authorization happens entirely through the identity provider, such as Google or GitHub, and the app receives only a token representing the specific permissions the user agreed to.

OAuth was first published in 2010 and updated to OAuth 2.0 in 2012. OAuth 2.0 is the version in widespread use today and is the foundation for most social login and API authorization systems. It is not backward compatible with OAuth 1.0, and when people refer to OAuth today they almost always mean OAuth 2.0.

A common point of confusion is the difference between authorization and authentication. OAuth handles authorization, which answers the question of what an application is allowed to do. It does not, on its own, answer the question of who the user is. For identity and login purposes, OAuth is often combined with OpenID Connect (OIDC), which adds an identity layer on top of the OAuth framework and provides a standardised way to retrieve user profile information after authorization.

OAuth Roles

OAuth defines four distinct roles that participate in the authorization flow. Understanding these roles makes it much easier to follow what is happening at each step of the process.

In many real-world implementations, the authorization server and the resource server are operated by the same organization and may even run on the same infrastructure. Google's authorization server issues tokens, and Google's Calendar API validates those same tokens. However, the OAuth specification treats them as separate roles because they serve distinct functions, and keeping them conceptually separate helps when reasoning about security boundaries.

How OAuth Works: The Authorization Code Flow

OAuth 2.0 defines several different flows for different scenarios. The Authorization Code Flow is the most secure and widely used for web applications where a backend server is involved. Here is how the full sequence unfolds when a user clicks "Login with Google" on a third-party app.

1. The user clicks "Login with Google" on the third-party application
2. The application redirects the user's browser to Google's authorization server, including the requested scopes and a redirect URI
3. The user logs in to their Google account if they are not already logged in
4. Google displays a consent screen showing exactly what permissions the app is requesting
5. The user reviews and grants permission, for example allowing the app to read their calendar events
6. Google redirects the browser back to the app's redirect URI with a short-lived authorization code in the URL
7. The app's backend server sends the authorization code to Google's token endpoint along with its client credentials
8. Google verifies everything and responds with an access token and optionally a refresh token
9. The app uses the access token to make authenticated requests to the Google Calendar API

The reason for the two-step exchange, first getting an authorization code and then exchanging it for a token, is security. The authorization code travels through the browser and could be exposed in browser history or server logs. By exchanging it server-side for the actual token, and requiring the app's client secret in that exchange, OAuth ensures the token is only ever seen by the backend and never exposed in the browser.

OAuth vs Traditional Login

To understand why OAuth matters, it helps to compare it with what came before. In earlier approaches to third-party integrations, apps would simply ask users for their username and password directly and use those credentials to log in on the user's behalf. This practice, sometimes called password anti-pattern, created serious security problems because it required users to hand over their credentials to apps they had no reason to fully trust.

OAuth Scopes

Scopes are one of the most important features of OAuth. They define exactly what permissions the client application is requesting, and the user sees these permissions listed on the consent screen before they agree to anything. This granularity is what makes OAuth both more secure and more trustworthy than handing over full account credentials.

Each service defines its own set of scopes. Google, GitHub, Spotify, and other providers all have their own scope naming conventions, but the principle is the same across all of them. Requesting only the scopes an app genuinely needs is considered best practice and helps build user trust by avoiding requests for permissions that seem unnecessary for the app's purpose.

• profile - Read basic profile information such as name and profile picture
• email - Access the user's email address
• calendar.readonly - Read calendar events without the ability to modify them
• drive.file - Access only the specific Google Drive files created by the app
• repo - Full access to GitHub repositories including private ones
• read:user - Read-only access to GitHub profile data

Access Tokens and Refresh Tokens

When an app completes the OAuth flow, it receives an access token. This token is included in the Authorization header of API requests to prove the app has been granted permission to access the resource. Access tokens are intentionally short-lived, typically expiring within an hour or less, to limit the damage if a token is ever leaked or stolen.

Alongside the access token, the authorization server may also issue a refresh token. A refresh token is a longer-lived credential that the app can use to request a new access token when the current one expires, without requiring the user to go through the consent flow again. Refresh tokens are sensitive and should be stored securely on the server side, never exposed to a browser or client-side code.

Real-World OAuth Examples

OAuth is used across a wide range of products and integrations. Some of the most common examples include the following.

• Login with Google, Facebook, or GitHub: Social login on third-party websites and apps, letting users sign in without creating a new account
• Spotify integrations: Allowing third-party apps to control playback, read listening history, or manage playlists on behalf of the user
• GitHub Actions and CI/CD tools: Authorizing pipelines to access repositories, run deployments, and post status checks
• Slack bots and integrations: Granting bots permission to read messages, post to channels, or manage workspace settings
• Calendar and productivity apps: Letting scheduling tools read availability from Google Calendar or Outlook without ever seeing the account password

Frequently Asked Questions

1. Does OAuth replace passwords?
   No. OAuth is a framework for delegating authorization between services and applications. The authorization server, such as Google or GitHub, still uses a password or other authentication method to verify the user's identity before issuing tokens. OAuth moves password handling to a single trusted provider rather than eliminating passwords entirely.
2. What is the difference between OAuth and OpenID Connect?
   OAuth 2.0 handles authorization, answering the question of what an application is permitted to do on a user's behalf. OpenID Connect is a thin identity layer built on top of OAuth 2.0 that handles authentication, answering the question of who the user actually is. OIDC adds an ID token to the OAuth flow that contains verified claims about the user's identity, such as their name and email address.
3. How do I revoke OAuth access?
   You can revoke access by visiting the security settings of the authorization server that issued the token. For Google, this is under Google Account settings in the Security section under third-party apps and services. Revoking access immediately invalidates the app's tokens, and the app will no longer be able to access your data even if it still holds a valid-looking token.
4. What is the difference between an access token and a refresh token?
   An access token is a short-lived credential the app includes in API requests to prove it has permission to access a resource. It typically expires within minutes or hours. A refresh token is a longer-lived credential stored securely on the server that the app uses to obtain a new access token when the old one expires, without requiring the user to log in and consent again. Refresh tokens should never be exposed to client-side code.
5. Is OAuth safe to use?
   OAuth 2.0 is a well-designed and widely trusted standard when implemented correctly. Security problems typically arise from incorrect implementations rather than flaws in the protocol itself. Common mistakes include using insecure redirect URIs, storing tokens in browser localStorage where scripts can access them, or not validating the state parameter that protects against cross-site request forgery during the authorization flow. Following the official OAuth security best practices avoids the most common pitfalls.

Conclusion

OAuth is a powerful and secure standard for authorization that has become fundamental to how modern web applications connect and share data. By eliminating password sharing, introducing granular permission scopes, and making access revocable at any time, OAuth dramatically improves both security and user experience compared to earlier approaches. Understanding how the authorization flow works, what roles are involved, and how tokens are issued and used is essential knowledge for anyone building web APIs or integrating with external services. To continue learning, explore JWT, token vs session authentication, and authentication vs authorization.