Before understanding the Authorization Code Grant, it helps to understand the problem OAuth 2.0 was built to solve.

OAuth 2.0 is an authorization framework. That word “authorization” is important, and it is different from “authentication.” Authentication answers the question “who are you?” Authorization answers the question “what are you allowed to do?” OAuth 2.0 is entirely about the second question. It defines a standard way for one application to be granted limited access to a user’s data or account on another application, without the user having to hand over their username and password to that first application.

Before OAuth existed, if a photo-printing website wanted to fetch your photos from another photo-storage service, the only option was for you to type your photo-storage username and password directly into the printing website. That website could now do absolutely anything your account could do — delete photos, change your password, read your private messages — because it was holding your full master key. This pattern was called the “password anti-pattern,” and it was both dangerous and hard to undo. If you wanted to revoke access later, your only option was to change your master password everywhere.

OAuth 2.0 solves this by introducing a middleman step. Instead of a password, the third-party app receives a special, limited token. This token can be scoped down to very specific permissions (for example, “read my photos” but not “delete my photos”), it can expire on its own, and it can be revoked individually without touching your actual password. The Authorization Code Grant is simply the specific, most secure recipe within OAuth 2.0 for producing that token when a real human is present to approve the request through a web browser.

Every OAuth 2.0 conversation involves exactly four roles. Learning their names now makes every later chapter much easier to follow.

OAuth 2.0 specifications always describe the same four participants, no matter which company is running the system. Once you can name each one and their job, the entire flow becomes a simple story about these four characters passing messages to each other.

In many real systems, the Authorization Server and the Resource Server are operated by the same company and even share infrastructure, but they are still treated as two logically separate jobs. The Authorization Server’s entire responsibility ends the moment it hands out a token. From then on, the Resource Server is the one deciding whether that token is still valid and what it is allowed to unlock.

Now that the actors are known, this chapter names the specific pattern this tutorial is about.

OAuth 2.0 actually defines several different “grant types,” which are simply different recipes for obtaining a token, each suited to a different kind of situation. The Authorization Code Grant is the recipe used whenever a real user is sitting in front of a web browser and can be asked, face to face, “do you approve this?” It is considered the flagship, most secure, and most widely recommended grant type in the entire OAuth 2.0 family.

The defining feature of this grant is the two-step exchange. First, the Client redirects the user’s browser to the Authorization Server, the user logs in and approves the request, and the Authorization Server sends back a short, one-time-use string called the authorization code. Second, and critically, the Client then takes that code and, from its own backend server (not through the user’s browser), exchanges it for the real access token. This second step happens over a private, server-to-server channel that the user’s browser never sees.

This two-step design is the single most important idea in this entire tutorial. Nearly every security benefit of the Authorization Code Grant traces back to this simple decision to separate “getting approved” from “getting the real key.”

A handful of technical terms appear again and again in every OAuth conversation. Defining them once here will save confusion later.

Two web addresses matter enormously in this whole process, and it is worth naming them clearly. The Authorization Endpoint is the page a browser is sent to first, where the login and consent screen live. The Token Endpoint is a completely separate, backend-only address where the authorization code gets exchanged for tokens. Confusing these two endpoints is one of the most common beginner mistakes, so remember: the Authorization Endpoint talks to browsers, and the Token Endpoint talks only to servers.

This is the heart of the tutorial: the exact sequence of events, told as a story with numbered steps.

Reading nine numbered steps in a row can feel like a lot. This diagram shows the same story as a picture.

sequenceDiagram
    participant U as User (Browser)
    participant C as Client App
    participant A as Authorization Server
    participant R as Resource Server

    U->>C: 1. Click "Log in with..."
    C->>U: 2. Redirect to Authorization Server
    U->>A: 3. Load login + consent page
    A->>U: 4. Show login form and consent screen
    U->>A: 5. Approve access
    A->>U: 6. Redirect back with authorization code
    U->>C: 7. Deliver code to Client's Redirect URI
    C->>A: 8. Exchange code + client secret (server-to-server)
    A->>C: 9. Return access token and refresh token
    C->>R: 10. Call API with access token
    R->>C: 11. Return protected data
        

Notice how the arrows change color of “ownership” partway through the diagram. Everything up through the redirect carrying the authorization code happens in full view of the user’s browser. Everything from the code exchange onward happens directly between the Client’s own backend server and the Authorization Server, with the browser stepping out of the conversation entirely. This is not an accident of implementation — it is the entire security model of the grant.

A natural question at this point is: why bother with an intermediate code at all? Why not send the access token straight back in step six?

This exact question has a historical answer. An earlier, now-discouraged OAuth pattern called the Implicit Grant did exactly that — it returned the access token directly in the browser’s address bar, with no code and no back-room exchange step. It turned out to be significantly less safe, and understanding why makes the Authorization Code Grant’s design much clearer.

Because of these weaknesses, the Implicit Grant has since been formally deprecated in current OAuth 2.0 security guidance, and the Authorization Code Grant — especially when combined with the extra protection covered in the next chapter — is now the recommended approach for essentially every situation involving a browser.

Client Secrets work well for backend web servers, but what about a mobile app or a single-page JavaScript app, which cannot truly hide a secret from a determined user?

A traditional web application, such as one built with a server-rendered backend, can store its Client Secret safely inside server code that the public never sees. But a mobile app installed on someone’s phone, or a JavaScript application running entirely inside a browser, cannot hide a secret the same way — a sufficiently determined person can decompile the app or inspect the browser’s network traffic and extract any secret hardcoded inside it. These are called “public clients,” as opposed to “confidential clients” that can keep a secret safely.

To protect public clients, the OAuth community introduced an extension called PKCE, pronounced “pixy,” short for Proof Key for Code Exchange. Instead of relying on a fixed, hardcoded secret, the Client generates a brand-new random secret value for every single login attempt, called a “code verifier.” It then creates a scrambled, one-way version of that value, called the “code challenge,” and sends only the scrambled version along with the very first redirect in step two. Later, during the code exchange in step seven, the Client reveals the original, unscrambled code verifier. The Authorization Server scrambles it the same way and checks that the two match before releasing any tokens.

flowchart LR
    A["Client generates random\ncode verifier"] --> B["Client scrambles it into\na code challenge"]
    B --> C["Code challenge sent with\nthe authorization request"]
    C --> D["Authorization Server\nstores the challenge"]
    D --> E["Client later sends the\noriginal code verifier"]
    E --> F["Server re-scrambles it and\ncompares to stored challenge"]
    F --> G{Match?}
    G -->|Yes| H["Tokens released"]
    G -->|No| I["Request rejected"]
        

Current security guidance now recommends using PKCE not only for mobile and single-page apps, but for every Authorization Code Grant implementation, including traditional backend web servers, simply as an extra layer of defense at essentially no cost.

Understanding the flow is only half the picture. Understanding what can go wrong is equally important.

Access tokens are deliberately designed to be short-lived, often expiring within an hour or less. This is intentional: if a token does leak, the window during which it remains useful to an attacker is kept as small as possible. Refresh tokens, which live much longer, are correspondingly treated with much greater care — they are usually kept only on trusted backend servers and never exposed to browser-side JavaScript, precisely because their longer lifespan makes them a far more valuable target if stolen.

No design is free of trade-offs. Here is an honest look at what the Authorization Code Grant gets right, and what it costs.

In practice, these trade-offs are considered well worth it. The small amount of extra implementation complexity buys a large amount of real-world security, which is exactly why nearly every major platform — from social networks to banks to developer tools — has standardized on this grant as their default choice whenever a human is present with a browser.

Many real-world OAuth security incidents trace back to a small number of repeated mistakes. Knowing them in advance helps you avoid them.

The Authorization Code Grant is not an abstract academic idea — it quietly runs behind buttons you click every day.

In every one of these examples, the same underlying shape repeats: a redirect to a trusted party’s own login page, a clear consent screen naming exactly what is being requested, a short-lived code, and a private backend exchange for the real token. Once you recognize this shape once, you will start noticing it everywhere.

The Authorization Code Grant is not the only recipe in OAuth 2.0. Seeing it alongside its siblings helps clarify when it is the right choice.

The pattern in this table is worth noticing: OAuth 2.0’s guidance has steadily moved away from any grant type that either exposes a token directly in a browser or requires typing a real password into a third-party application, and steadily toward the Authorization Code Grant with PKCE as the safe, general-purpose default whenever a human user is involved.

No. The password, or any other login method such as a fingerprint or passkey, is entered directly on the Authorization Server’s own login page, which the Client never has access to. The Client only ever receives a code and, later, tokens.

A well-implemented Authorization Server rejects the second attempt outright, and many implementations go further by immediately revoking any tokens that were already issued from that code, treating reuse as a strong signal of an attack in progress.

Short lifetimes limit how much damage a leaked token can do. Instead of forcing the user to log in again every time it expires, the Client can quietly use a refresh token to obtain a new access token in the background.

PKCE was originally designed for public clients like mobile and single-page apps that cannot keep a secret safely, but current security guidance recommends using it for every Authorization Code Grant implementation, including traditional backend web servers, as a low-cost extra layer of defense.

Yes. Most major Authorization Servers provide an account settings page listing every application that has been granted access, along with the exact scopes approved, and a button to revoke access for any individual app at any time.

An access token proves permission to call an API on the user’s behalf. An ID token, which comes from a related standard built on top of OAuth 2.0 called OpenID Connect, instead proves who the user actually is, and is used specifically for login and identity rather than data access.

Pre-registration lets the Authorization Server refuse to send an authorization code anywhere except an address the Client owner has already proven control over, which closes off a whole category of redirection-based attacks.

The Authorization Code Grant is, at its core, a carefully engineered two-step handshake. A user approves a request in full view of their own browser, receives a short-lived, one-time voucher, and that voucher is then quietly exchanged for the real access credential over a private, backend-only channel the browser never sees. Every design choice in the flow — the short code lifetime, the “state” check, the pre-registered Redirect URI, and the optional but increasingly essential PKCE extension — exists to close a specific, real-world attack that earlier, simpler approaches suffered from. Once you can see the flow as this “front lobby, then back room” story, the entire specification stops feeling like an arbitrary list of steps and starts feeling like a logical, defensible system.