How Does OAuth Work? – The Authorization Code Flow Explained

Learn how OAuth delegates access without sharing passwords, how the authorization code flow proceeds step by step, and what PKCE protects against.

OAuth lets an application act on a user's behalf at another service without ever seeing that user's password. It is a delegation protocol, and it is frequently confused with a login protocol.

1. The Four Parties

2. The Authorization Code Flow

1. The client redirects the user to the authorization server with its identifier, the scopes it wants, a redirect URI, and a state value.
2. The user authenticates at that server — the client never sees the credentials.
3. The user is shown what is being requested and consents.
4. The server redirects back to the client's URI with a short-lived authorization code.
5. The client exchanges that code, plus its own secret, for an access token.
6. The client calls the resource server with the token.

The code exists so the token never travels through the browser's address bar, where it would land in history and referrer headers.

3. Why the State Parameter Matters

The client generates a random state value, sends it in step one, and verifies it matches on return. Without that check, an attacker can initiate a flow and trick a victim into completing it, binding the victim's session to the attacker's account.

4. PKCE

Public clients — mobile applications and browser-based apps — cannot keep a secret, so the code alone would be enough for an interceptor to redeem.

PKCE closes that gap: the client generates a random verifier, sends its hash when starting the flow, and presents the original verifier when redeeming the code. An intercepted code is useless without it.

It is now recommended for confidential clients too, since it costs little and removes an entire attack class.

5. Scopes Limit What the Token Can Do

Scopes are the permissions the client requests, shown to the user at consent. A token issued for reading contacts should not be able to send messages.

Requesting the minimum needed is both good practice and a conversion consideration: an alarming consent screen is a reason users abandon a connection.

6. Tokens and Refresh

Access tokens are short-lived. A refresh token, where issued, is exchanged for a new access token without involving the user again.

Refresh tokens are far more sensitive — they represent standing access — and must be stored with correspondingly more care.

7. OAuth Is Not Authentication

OAuth answers "may this application access that data", not "who is this user". Using an access token as proof of identity is a well-known mistake, because a token says nothing verifiable about who obtained it.

OpenID Connect layers identity on top of OAuth, adding an ID token specifically for that purpose. If you need login, that is the protocol.

8. Summary

OAuth delegates scoped access through an authorization code exchanged for a token, with the user authenticating only at the authorization server.

Verify state, use PKCE, request minimal scopes, protect refresh tokens most carefully — and use OpenID Connect rather than OAuth alone when the actual requirement is knowing who the user is.

Potential Related Glossary

• Parsing
• Axios
• Data Structure
• Web Crawling