Before comparing the two endpoints in detail, it helps to see where they sit inside OAuth 2.0 as a whole.

A quick refresher on OAuth 2.0

OAuth 2.0 is a protocol — an agreed set of rules — that lets one application access a limited slice of another system’s data on a user’s behalf, without ever seeing that user’s actual password. Achieving this safely requires more than one conversation to take place. First, the user needs to be identified and asked to approve the request. Second, once approved, the requesting application needs to actually receive something usable — a token — that proves the approval happened. OAuth 2.0 assigns each of these two conversations to its own dedicated endpoint.

Naming the two endpoints precisely

Every later chapter in this guide builds on that simple split: one endpoint is meant to be seen by a human, in a browser, and the other is meant to be reached only by trusted backend code, never by a browser at all.

Why this split rewards a few extra minutes of study

It is entirely possible to copy a working OAuth 2.0 integration from documentation without ever fully understanding why it is shaped the way it is. Many developers do exactly that, and their code works fine — right up until something unusual happens: a redirect URI needs to change, a login starts failing in a confusing way, or a security review asks pointed questions about where a Client Secret lives. In every one of those moments, understanding the reasoning behind the two-endpoint split turns a confusing troubleshooting session into a quick, confident fix. This guide is written for exactly that purpose — not just showing what each endpoint does, but why the boundary between them was drawn where it was.

A close look at the first, public-facing half of the exchange.

Definition

The Authorization Endpoint is a specific URL, hosted by the authorization server, that a user’s browser is sent to when an application wants to request access to something on their behalf. It is designed to be opened directly in a browser, the same way any ordinary website is opened, because a real human needs to see it, read it, and interact with it.

What actually happens there

When a user’s browser lands on the Authorization Endpoint, the authorization server first checks whether that user is already logged in. If not, it shows a login form. Once logged in, it displays a consent screen describing which application is asking, and exactly what it wants to access — for example, “PhotoPrinter wants to view your Google Photos.” The user then clicks either “Allow” or “Deny.”

What gets sent, and what comes back

The application constructs a specially formatted web address pointing at the Authorization Endpoint, including its own Client ID, the redirect URI it wants the user sent back to, and the specific scopes it is requesting. None of this is secret — it is all visible in the browser’s address bar. Once the user approves, the authorization server redirects the browser back to the application’s redirect URI, carrying a short-lived authorization code.

Because every piece of this initial request is visible, a curious user could technically read and even modify parts of the address bar before the request is sent. This is perfectly fine by design, since nothing in this first request is meant to be trusted purely on its own — the authorization server still independently verifies the Client ID against its own registry, and still enforces its own redirect URI rules regardless of what the browser’s address bar happens to display.

The consent screen deserves a closer look

The consent screen shown at the Authorization Endpoint is often the only moment in the entire OAuth 2.0 exchange where a user actually sees and reads something meaningful. It typically displays the requesting application’s registered name, its logo if one was provided at registration, and a plain-language description of each scope being requested, such as “view your basic profile information” or “read your calendar events.” Because this screen is generated using data the application supplied during registration, keeping that registration information accurate and up to date directly affects how trustworthy the request looks to real users.

Handling denial gracefully

Not every visit to the Authorization Endpoint ends in approval. A user might click “Deny,” close the browser tab, or simply change their mind partway through. In these cases, the authorization server still redirects the browser back to the application’s registered redirect URI, but instead of an authorization code, it includes an error parameter explaining that access was denied. A well-built application checks for this outcome explicitly and shows the user a clear, friendly message, rather than assuming a code will always be present and crashing unexpectedly when one is not.

Beyond a simple denial, users can also close the browser tab mid-flow, lose their network connection, or navigate away entirely before reaching a decision. A resilient application treats all of these as the same broad category of “the flow did not complete successfully,” offering the user a clear way to simply start over, rather than leaving them stuck on a broken page with no obvious next step.

The second half of the exchange, and the one that actually produces something usable.

Definition

The Token Endpoint is a separate URL, also hosted by the authorization server, but designed to be called directly by an application’s backend code, never opened in a browser and never shown to a user. Its entire job is to accept proof — an authorization code, or a Client ID and Secret, depending on the flow — and exchange that proof for an actual, usable access token.

What actually happens there

After the browser is redirected back to the application carrying an authorization code, the application’s own backend server quietly sends that code, along with its Client ID and Client Secret, directly to the Token Endpoint. The authorization server verifies that everything matches — the code is genuine, unused, and not expired, and the Client ID and Secret belong together — and, if everything checks out, responds with an access token, and often a refresh token.

What gets sent, and what comes back

Unlike the Authorization Endpoint, nothing about this exchange ever touches the user’s browser. The request travels directly from server to server, over an encrypted connection, carrying values that must never be exposed publicly — most importantly, the Client Secret. The response is a structured piece of data containing the access token itself, how long it remains valid, and sometimes a refresh token for later use.

The shape of a typical token response

A successful response from the Token Endpoint is a structured piece of data, not a redirect or a web page. It commonly includes the access token itself, a value describing how long that token remains valid, the type of token issued, and — for flows that support ongoing renewal — a refresh token. Some providers also include the specific scopes that were actually granted, which may occasionally be narrower than what was originally requested if the authorization server chose to limit them. A well-built client reads this response carefully rather than assuming every field will always be present in every situation, and stores the resulting values securely rather than logging them in plain text anywhere.

What happens when verification fails

If the code, Client ID, or Client Secret do not line up correctly, the Token Endpoint responds with a clear error rather than any token at all. Common reasons include an expired or already-used authorization code, a mismatched redirect URI between the original request and the token exchange, or an incorrect Client Secret. These errors are deliberately generic in their public wording, avoiding hints that might help an attacker guess which specific piece of the exchange went wrong.

This split was not an arbitrary design choice — it solves a real problem.

The problem of mixing visible and secret information

Imagine if OAuth 2.0 tried to handle everything — login, consent, and token issuance — through one single endpoint that a browser called directly. That single endpoint would need to somehow receive a Client Secret from the browser to prove the request was legitimate, which means the Secret would need to be embedded somewhere in browser-visible code. As covered in the broader OAuth 2.0 security model, anything reachable from a browser can eventually be extracted by a sufficiently motivated user. Splitting the flow into two endpoints keeps the secret-handling step entirely separate from anything the browser ever sees.

Three concrete reasons for the split

A second, related reason: separation of concerns

Beyond pure security, splitting these responsibilities also makes each endpoint simpler to build, test, and reason about individually. The Authorization Endpoint deals entirely with human-facing concerns — rendering forms, checking passwords, remembering login sessions, and displaying consent choices clearly. The Token Endpoint deals entirely with machine-facing concerns — validating cryptographic proofs, checking expiration timestamps, and issuing structured data responses. Engineering teams that build and maintain authorization servers benefit from this separation just as much as the security model does, since each endpoint can evolve, scale, and be tested independently of the other.

Placing both endpoints inside the wider OAuth 2.0 architecture.

flowchart TB
    U["User Browser"] -->|1. Opens with Client ID + redirect URI| AE["Authorization Endpoint"]
    AE -->|2. Login + consent screen| U
    AE -->|3. Redirect with Authorization Code| U
    U -->|4. Forwards code| CB["Client Backend"]
    CB -->|5. Code + Client ID + Client Secret| TE["Token Endpoint"]
    TE -->|6. Access Token| CB
    CB -->|7. Uses token| RS["Resource Server"]
        

Core architectural components

Both endpoints, one authorization server

It is worth noting that both endpoints are typically part of the very same authorization server, simply exposed at two different, clearly separated URLs — for example, something like /oauth/authorize for the Authorization Endpoint and /oauth/token for the Token Endpoint. They are not separate systems maintained by different teams; they are two clearly defined responsibilities within one coherent service, discoverable together through the provider’s OAuth metadata, which lists both URLs explicitly for any client that needs to find them.

How a client discovers both URLs

Rather than assuming or guessing at endpoint addresses, well-built OAuth 2.0 clients fetch a metadata document — often located at a well-known, standardized address — published by the authorization server itself. This document lists the exact Authorization Endpoint and Token Endpoint URLs, along with other useful details such as which scopes are supported and which security algorithms are in use. Reading this metadata once at application startup, rather than hardcoding both URLs directly into source code, keeps an integration resilient if the provider ever restructures its infrastructure later.

Walking through the complete journey, endpoint by endpoint, in order.

sequenceDiagram
    participant Browser
    participant AuthEndpoint as Authorization Endpoint
    participant ClientBackend as Client Backend
    participant TokenEndpoint as Token Endpoint
    Browser->>AuthEndpoint: Client ID + redirect URI + scopes
    AuthEndpoint-->>Browser: Login form, then consent screen
    Browser->>AuthEndpoint: Approve
    AuthEndpoint-->>Browser: Redirect with Authorization Code
    Browser->>ClientBackend: Forwards Authorization Code
    ClientBackend->>TokenEndpoint: Code + Client ID + Client Secret
    TokenEndpoint-->>ClientBackend: Access Token (+ Refresh Token)
        

Why the code exists as a middle step at all

A reasonable question is why the flow does not simply hand back an access token directly from the Authorization Endpoint, skipping the code entirely. The answer is that the Authorization Endpoint’s response travels through the browser’s address bar during the redirect, which can end up recorded in browser history, server logs, or visible to browser extensions. An authorization code is short-lived and single-use, so even if it were somehow observed there, it becomes worthless almost immediately — whereas a full access token exposed the same way would remain dangerous for as long as it stayed valid.

What the client backend does immediately after receiving the code

The moment the application’s server receives the forwarded authorization code, it typically validates a handful of basic expectations before even calling the Token Endpoint — confirming the request came from the expected redirect path, and that no error parameter was present instead of a code. Only once these basic checks pass does the backend proceed to build and send the actual token request, attaching the code alongside its own Client ID and Client Secret, exactly as described in step five above.

Looking at how information moves and expires across both endpoints over time.

The authorization code’s short life

An authorization code produced by the Authorization Endpoint is intentionally short-lived, often valid for well under a minute, and strictly single-use — the moment it is redeemed once at the Token Endpoint, it becomes permanently invalid, even if somehow reused again immediately afterward. This narrow window dramatically limits how useful an intercepted code could ever be to anyone other than the legitimate application.

The access token’s longer, still-limited life

Once issued by the Token Endpoint, an access token usually remains valid for a somewhat longer window — commonly anywhere from a few minutes to a few hours, depending on the provider’s policy — after which it simply stops working. If the application needs continued access beyond that window, and a refresh token was issued alongside it, the application can quietly call the Token Endpoint again, this time presenting the refresh token instead of an authorization code, to obtain a fresh access token without bothering the user again.

Refresh tokens themselves typically live far longer than access tokens — sometimes for weeks or months, sometimes until explicitly revoked — but they are also treated with extra caution precisely because of that long lifespan. Many providers limit how many times a refresh token can be used, rotate it automatically each time it is exchanged, or allow it to be revoked instantly from a user’s account settings, giving both the provider and the user a way to cut off long-lived access without waiting for natural expiration.

sequenceDiagram
    participant ClientBackend as Client Backend
    participant TokenEndpoint as Token Endpoint
    ClientBackend->>TokenEndpoint: Refresh Token + Client ID + Client Secret
    TokenEndpoint->>TokenEndpoint: Verify refresh token still valid
    TokenEndpoint-->>ClientBackend: New Access Token
        

The Authorization Endpoint’s role ends early

It is worth emphasizing that once an authorization code has been issued, the Authorization Endpoint has no further part to play in that particular login session. All subsequent activity — the actual token exchange, and any later refresh — happens exclusively through the Token Endpoint. The Authorization Endpoint’s job is a single, one-time, front-facing interaction; everything that follows belongs entirely to its quieter, backend counterpart.

Because the two endpoints serve different audiences, they need very different protections.

Why redirect URI checking matters so much here

Because the Authorization Endpoint’s response travels back through the browser, strict, exact-match redirect URI validation is essential — without it, an attacker could register a look-alike Client ID pointing at their own server and trick the authorization server into sending an unsuspecting user’s authorization code somewhere unintended. The Token Endpoint has no equivalent concern, since it never redirects anyone anywhere; it simply responds directly to whichever backend called it.

This is also why many providers refuse to allow certain kinds of loosely specified redirect URIs at all — for instance, addresses using plain, unencrypted HTTP rather than HTTPS, or addresses pointing at generic, shared hosting platforms where the exact final destination cannot be fully guaranteed. Enforcing these restrictions at registration time, before any login attempt ever happens, closes off entire categories of redirect-based attacks before a developer even has the chance to make the mistake.

PKCE as an additional layer on the Authorization Endpoint side

For public clients, such as mobile or single-page apps, an extra mechanism called PKCE adds a one-time, randomly generated value to the request sent to the Authorization Endpoint, and a matching value presented later at the Token Endpoint. This links the two endpoints together for that specific login attempt, ensuring that even if an authorization code were somehow intercepted along the way, it could not be redeemed at the Token Endpoint without the matching PKCE value that only the original requester ever had.

State parameters and protecting the Authorization Endpoint from forged requests

Beyond redirect URI checks and PKCE, applications are also expected to generate a random, unpredictable “state” value before sending a user to the Authorization Endpoint, and to verify that the exact same value comes back with the redirect afterward. This protects against a different kind of attack, where someone tries to trick a logged-in user into completing an authorization flow that was actually initiated by an attacker elsewhere. Because the state value is generated fresh for each attempt and checked strictly on return, a forged flow started by anyone other than the legitimate user’s own browser session gets rejected before it can do any harm.

A practical breakdown of exactly which part of a system is expected to call each endpoint.

Why this separation of callers is enforced

The Authorization Endpoint must be reachable by a browser, because only a human, interacting through a browser, can actually type a password or click “Allow.” The Token Endpoint, on the other hand, deliberately avoids ever needing a browser, because doing so would force sensitive values like the Client Secret into browser-visible territory. Respecting this caller separation is one of the simplest, most effective habits a developer can build when working with OAuth 2.0.

This separation also shapes how errors should be surfaced to a user. A failure at the Authorization Endpoint — a wrong password, a denied consent — is something the user directly caused and can directly fix by trying again. A failure at the Token Endpoint, by contrast, almost always points to a problem in the application’s own backend configuration, such as a mismatched Client Secret, and showing that kind of raw, technical error to an end user rarely helps them; it is far more useful logged for the development team than displayed on screen.

Public clients are the one exception worth understanding

Mobile and single-page applications, which never hold a true Client Secret, are permitted to call the Token Endpoint directly from the application itself, but only when paired with PKCE instead of a secret. This still respects the underlying principle — nothing genuinely secret ever needs to be embedded in the app — while allowing a simpler architecture without a dedicated backend proxy for every integration.

What a backend proxy pattern looks like when one is needed

For confidential-client applications that still want a lightweight front end, a common pattern introduces a thin backend component whose only job is to sit between the browser and both OAuth 2.0 endpoints. The browser talks to this thin backend using its own, ordinary session mechanism, and the thin backend, in turn, is the only party that ever talks to the Token Endpoint directly, holding the Client Secret safely on the server side the entire time. This keeps the browser-facing experience simple and responsive, while preserving the strict separation of callers described throughout this chapter.

Patterns experienced teams follow when integrating with both endpoints correctly.

Mistakes worth recognizing before they show up in a real system.

Seeing this exact two-endpoint pattern across familiar platforms makes it concrete.

Google Identity Services

Google’s OAuth 2.0 implementation exposes a clearly separate authorization page and token-issuing address, discoverable together through its published OpenID Connect discovery document, which any properly built client can fetch to find both URLs automatically rather than hardcoding them.

GitHub’s login flow

When a user clicks “Sign in with GitHub,” their browser is sent to GitHub’s authorization page to log in and approve access — a clearly public, browser-facing step. The requesting application’s backend then separately calls GitHub’s token endpoint directly, presenting its Client ID and Secret, entirely outside the user’s browser session.

Microsoft Identity Platform

Microsoft’s identity platform documentation explicitly names and separates its “authorize” endpoint from its “token” endpoint, and strongly recommends that confidential-client applications never call the token endpoint from any browser-executed code, mirroring the exact separation described throughout this guide.

Auth0 and similar identity platforms

Third-party identity platforms built specifically to sit in front of a company’s own systems consistently expose this same two-endpoint structure to developers, since it reflects the underlying OAuth 2.0 specification itself rather than any one company’s particular choice — reinforcing that this is a standard, widely adopted pattern rather than an unusual design decision.

Enterprise single sign-on gateways

Large organizations that operate an internal single sign-on gateway in front of dozens of internal applications almost always structure that gateway around the same two-endpoint pattern, precisely because it lets one central Authorization Endpoint handle every employee login consistently, while each individual internal application’s backend independently calls the shared Token Endpoint whenever it needs to complete its own login flow. This lets a single company-wide login experience serve many different applications without any of them needing to duplicate the sensitive parts of the exchange themselves.

Because the two endpoints face very different audiences, they deserve very different monitoring strategies.

What to watch at the Authorization Endpoint

What to watch at the Token Endpoint

Correlating activity across both endpoints

While the two endpoints are monitored separately for most day-to-day metrics, incident investigations often benefit from correlating activity across both. If a spike in redirect URI rejections at the Authorization Endpoint coincides with a spike in failed Secret verifications at the Token Endpoint for the same Client ID, that pattern is far more concerning than either signal alone, and typically points toward a coordinated attempt to probe or abuse a specific integration rather than an isolated glitch in one part of the system.

Direct answers to the questions beginners most often ask when first meeting both endpoints.

No. In the standard, most secure flow, it only ever produces a short-lived authorization code, which must then be exchanged separately at the Token Endpoint.

No. It is called directly by backend code (or a public client using PKCE), never navigated to as a web page the way the Authorization Endpoint is.

Because the Authorization Endpoint’s traffic passes through the user’s browser, anything sent there risks exposure. Keeping the Secret exchange at a separate, backend-only endpoint avoids that risk entirely.

The second attempt is rejected. Authorization codes are strictly single-use, and most authorization servers also revoke any tokens already issued from that code as an added precaution.

Typically yes — both are part of the same authorization server, exposed as two distinct, clearly separated URLs rather than two entirely separate systems.

Refresh tokens are only ever used at the Token Endpoint, to obtain a new access token later without involving the Authorization Endpoint or the user again.

Yes, when paired with PKCE instead of a Client Secret, since PKCE provides an equivalent proof of legitimacy without needing anything to stay hidden inside the app.

Most providers publish an OAuth or OpenID Connect metadata document listing both endpoint URLs explicitly, which is the recommended source rather than hardcoding them.

The Authorization Endpoint and Token Endpoint together form the backbone of nearly every OAuth 2.0 login a person encounters, yet each plays a completely different role. The Authorization Endpoint is the public-facing half — a browser destination where a human logs in and decides whether to approve a request. The Token Endpoint is the quiet, backend half — a server-to-server exchange where proof of that approval is traded for an actual, usable access token, with sensitive values like the Client Secret never touching the browser at all. Understanding why this split exists, and respecting the boundary between who is allowed to call each endpoint, is one of the most important habits for building secure OAuth 2.0 integrations.