OAuth 2.0 Eliminates Password Sharing for Third-Party App Access

The Password Anti-Pattern

Before OAuth 2.0, users granted third-party applications access to services like Twitter or email by directly providing their username and password. This practice, known as the password anti-pattern, meant apps could log in as the user and potentially store credentials insecurely. A breach of a third-party app could compromise all user accounts connected to it, and users could not revoke access for a single app without changing their password across all services.

How OAuth 2.0 Works

OAuth 2.0 addresses these security flaws by ensuring users authenticate only with the trusted service (e.g., Google, GitHub). The third-party application never receives the user's password. Instead, the service issues a token to the app. This token has three key properties: it is scoped to grant only approved permissions, it is time-limited (typically expiring within an hour), and it is revocable by the user at any time from their account settings.

The Authorization Code with PKCE Flow

The modern standard for OAuth 2.0 implementation is the Authorization Code flow with Proof Key for Code Exchange (PKCE). This process involves five steps. First, the app redirects the user to the authorization server. Second, the user authenticates directly on the authorization server's domain, keeping their password private from the third-party app. Third, the authorization server redirects the user back to the app with a short-lived code.

Fourth, the app exchanges this code for an access token in a secure server-to-server communication. Finally, the authorization server returns the access token, along with its type, expiration time, and scope, to the application. This token allows the app to perform actions on behalf of the user within the granted permissions without ever handling the user's actual credentials.