Authentication & Password

OAuth 2.0

About 5 min read

What Is OAuth 2.0

OAuth 2.0 is an authorization framework that grants third-party applications limited access to user resources without sharing the user's password. It is standardized in RFC 6749.

A familiar example is social login such as "Sign in with Google" or "Sign in with GitHub." In this case, you can grant a service access to profile information held by Google (name, email address, etc.) without revealing your Google password to that service.

An important distinction is that OAuth 2.0 is an "authorization" framework, not an "authentication" protocol. When authentication functionality is needed, OpenID Connect (OIDC), built on top of OAuth 2.0, is used. Most single sign-on implementations are based on OIDC.

OAuth 2.0 Roles and Flow

OAuth 2.0 involves four roles.

  • Resource Owner: The owner of the data (typically the user)
  • Client: The application that wants to access the user's data
  • Authorization Server: The server that issues access tokens (e.g., Google's authorization endpoint)
  • Resource Server: The server that holds the user's data (e.g., Google's API server)

The most common Authorization Code Flow works as follows.

  1. The user clicks the "Sign in with Google" button on the client app
  2. The client redirects the user to Google's authorization endpoint
  3. The user authenticates on Google's login screen and consents to access permissions
  4. Google returns an authorization code (temporary code) to the client
  5. The client exchanges the authorization code for an access token
  6. The client uses the access token to retrieve user information from the Google API

Through this mechanism, the client app can access data within the permitted scope without ever knowing the user's Google password.

Access Control via Scopes

An important concept in OAuth 2.0 is "scopes." Scopes define the range of permissions granted to an access token.

For example, Google's OAuth 2.0 defines scopes such as:

  • profile: Read name and profile picture
  • email: Read email address
  • https://www.googleapis.com/auth/drive.readonly: Read-only access to Google Drive
  • https://www.googleapis.com/auth/calendar: Read and write access to Google Calendar

What users see on the consent screen is this list of scopes. If an app requests overly broad scopes (e.g., a calendar app requesting access to contacts), it may indicate unnecessary data collection. Following the principle of data minimization, verify that apps request only the minimum necessary scopes.

OAuth 2.0 Security Considerations

Here are key points users should know to use OAuth 2.0 safely.

  • Always Review the Consent Screen: Check the permissions (scopes) the app requests and don't consent to apps requesting unnecessarily broad permissions
  • Regularly Review App Connections: Check connected third-party apps in your Google, GitHub, and other account settings, and revoke access for apps you no longer use
  • Importance of PKCE (Proof Key for Code Exchange): For mobile apps and SPAs (Single Page Applications), the PKCE extension is essential to prevent authorization code interception attacks. OAuth 2.1 plans to make PKCE mandatory for all clients
  • CSRF Protection: Use the state parameter to verify the correspondence between authorization requests and callbacks. This prevents attacks where an attacker tricks a user into using an attacker-prepared authorization code
  • Strict Redirect URI Validation: The authorization server should only allow registered redirect URIs to prevent open redirector vulnerabilities

To learn more about this topic, see Two-Factor Authentication (2FA): The Best Defense for Your Accounts.

Common Misconceptions

OAuth 2.0 is a protocol for login (authentication)
OAuth 2.0 is an authorization framework (granting access to resources), not an authentication protocol (verifying user identity). For authentication, OpenID Connect (OIDC), built on OAuth 2.0, is used. "Sign in with Google" is technically OIDC authentication.
Using social login eliminates the risk of password leaks
Social login eliminates the need for individual service passwords, but if your Google or GitHub account is compromised, all connected services are affected. Always set up two-factor authentication on SSO accounts and regularly review app connections.
Share

Related Terms

Related Articles