You have seen the button: "Sign in with Google" or "Continue with GitHub." One click, no new password, and the app can read your profile or your repos. That button is OAuth 2.0 at work, and its core idea is simple: an app gets limited permission to act on your behalf, without ever touching your password.
Key Takeaways
OAuth 2.0 is an authorization protocol, not a login system by itself. It grants scoped, revocable access to resources.
The authorization code flow is the standard flow for web apps: the user approves access, the app receives a short-lived code, then exchanges it for tokens.
Access tokens are short-lived credentials for API calls. Refresh tokens fetch new access tokens without asking the user to log in again.
Scopes limit what a token can do. PKCE protects public clients, such as mobile apps, from authorization code interception.
OAuth 2.0 replaces sharing passwords and long-lived static API tokens with tokens that can be scoped, rotated, and revoked.
What OAuth 2.0 Actually Is
oauth.net describes OAuth 2.0 as the industry standard protocol for authorization, with specific flows for web, desktop, mobile, and living room devices. The key word is authorization: OAuth answers "what is this app allowed to do," not "who is this user." OpenID Connect, a layer built on top of OAuth 2.0, adds the identity part, which is why "Sign in with Google" also tells the app who you are.
Before OAuth, the old model was ugly. As RFC 6749, the core OAuth 2.0 specification published by the IETF in October 2012, explains, third-party apps had to store user passwords, often in clear text, and they got overly broad access that could only be revoked by changing the password. OAuth fixes both problems: the app never sees the password, and access is limited and revocable.
Four roles take part in every OAuth flow:
Resource owner: you, the user who owns the data.
Client: the app requesting access.
Authorization server: the service that checks your identity and issues tokens, for example Google or GitHub.
Resource server: the API that holds your data and accepts valid tokens.
How the Authorization Code Flow Works
The authorization code flow, defined in RFC 6749 section 4.1, is the flow for confidential applications such as regular web apps, according to Auth0 Docs. It works in steps:
You click "Sign in" in the app, which redirects you to the authorization server.
You log in there, on the provider's own site, not inside the app.
You approve (or decline) the requested permissions, shown as scopes.
The authorization server redirects you back to the app with a single-use authorization code.
The app exchanges that code, plus its own client credentials, at the token endpoint.
The authorization server verifies everything and returns an access token, and optionally a refresh token.
Notice what never happens: your password never passes through the app. The app only ever holds tokens, and those tokens can be revoked without changing your password.
Access Tokens vs Refresh Tokens
The OAuth 2.0 specification defines access tokens in section 1.4 and refresh tokens in section 1.5. They play different roles, and confusing them is the most common OAuth mistake.
Aspect | Access Token | Refresh Token |
|---|---|---|
Purpose | Call APIs on your behalf | Get a new access token when the old one expires |
Lifetime | Short, often minutes to an hour | Long, days to months, or until revoked |
Where it travels | Sent with every API request | Sent only to the authorization server |
If stolen | Damage is limited by its short life and narrow scope | Serious, which is why it must be stored securely and rotated |
A common pattern, shown in Okta Developer docs, uses an access token lifetime of 1 hour. When it expires, the app silently uses the refresh token to get a new one, so you stay signed in without re-entering your password. If you revoke access, the refresh token stops working, and the app is locked out.
Scopes: The Least Privilege Principle
Scopes are the permission labels attached to a token. Each scoped token lets its bearer perform specific actions on specific endpoints, and the scopes in the token control that ability, as Okta Developer docs explain. A token scoped to `read:user` can read your public profile, but it cannot delete your repos or send email as you.
This is the practical payoff of OAuth. When you approve an app, read the scope list. If a simple photo filter asks for full access to your email and contacts, that scope list is your warning sign, and declining costs nothing.
PKCE: Protecting Public Clients
Mobile apps and single-page apps cannot keep a client secret, so they are called public clients. RFC 7636, published by the IETF in September 2015, was written because public clients using the authorization code grant are susceptible to authorization code interception: a malicious app on the same device could steal the code from the redirect.
PKCE (pronounced "pixy") fixes this with a per-request secret. The client creates a random code verifier, a high entropy string of 43 to 128 characters, and sends its transformed code challenge when requesting the code. When exchanging the code for tokens, it must present the original verifier as proof of possession, as explained by MojoAuth. An attacker who intercepts the code still lacks the verifier, so the code is useless to them. Today, PKCE is recommended for all authorization code flows, not just public clients.
OAuth vs Passwords and Static API Tokens
Why not just share a password or a static API key? Okta makes the contrast clear: unlike short-lived OAuth tokens, static tokens typically have a long life, and a stolen static token remains active until manually inactivated or it finally expires. Static tokens also usually grant all or nothing access, while OAuth supports scoped access, token rotation, and service to service use through the client credentials flow.
Approach | Password sharing | Static API token | OAuth 2.0 |
|---|---|---|---|
App sees your password | Yes | No | No |
Access scope | Everything your account can do | Usually all or nothing | Scoped, per token |
Revocation | Change your password | Manually inactivate the token | Revoke the token, password untouched |
Expiry | Never, until changed | Long-lived, often indefinite | Short-lived access token, rotatable refresh token |
That table is also why OAuth pairs naturally with the API model explained in our REST API guide: APIs need a safe way to decide who may call them, and scoped tokens are that mechanism.
When to Use OAuth 2.0
Use OAuth 2.0 when a third-party app needs access to user data on another service, when you want users to sign in without a new password, or when an API needs scoped, revocable access. Use the authorization code flow with PKCE for web and mobile apps, and the client credentials flow for service to service calls where no user is involved.
Do not use OAuth as a substitute for session management inside your own app, and do not store tokens in places attackers can read, such as browser local storage for sensitive apps. OAuth secures delegation between services; your own app's session security is still your job.
Baca versi Bahasa Indonesia dari artikel ini di OAuth Dijelaskan: Cara Login Aman Tanpa Membagikan Password.
FAQ
Is OAuth 2.0 the same as logging in?
No. OAuth 2.0 is authorization: it grants scoped access to resources. OpenID Connect, built on OAuth 2.0, adds authentication, which is how "Sign in with Google" confirms your identity.
Does the app ever see my password?
No, in a correct OAuth flow. You log in on the provider's own site, and the app only receives tokens. If an app asks you to type your Google or GitHub password directly into it, that is not OAuth, and you should stop.
What happens when I revoke an app's access?
The authorization server invalidates the app's tokens, including its refresh token. The app can no longer call the API on your behalf, and your password stays unchanged.
Why do some apps ask me to log in again so often?
Their access tokens are short-lived and they have no valid refresh token, or the refresh token was revoked or expired. Short lifetimes are a security feature, not a bug.