Category: OAuth & OIDC

Token Endpoint

Also known as: /token endpoint, /oauth/token

Simply put

The token endpoint is a URL on an authorization server that an application contacts to obtain tokens after a user or client has been authorized. In most deployments the application sends proof of an authorization grant to this endpoint and receives tokens it can use to access protected resources. It is a back-channel endpoint, meaning the application calls it directly rather than routing the request through the user's browser.

Formal definition

The token endpoint is defined by the OAuth 2.0 Authorization Framework as the server endpoint the client uses to exchange an authorization grant (for example, an authorization code) or a refresh token for an access token, and optionally a refresh token. It is used by all OAuth 2.0 grant types except the Implicit Flow, where the authorization endpoint issues the access token directly. In OpenID Connect Core 1.0, the token endpoint additionally returns an ID Token when OIDC flows request it; for the Authorization Code Flow the ID Token returned from the token endpoint is specified in Section 3.1.3.6, and for the Hybrid Flow in Sections 3.3.3.6 and 3.3.3.7. Depending on the grant and profile, requests to this endpoint carry client authentication and grant-specific parameters, and it should be distinguished from the authorization endpoint (which handles the front-channel, user-facing authorization step) and from token introspection or activation endpoints that report on an existing token's state.

Why it matters

The token endpoint is the point at which an authorization grant becomes usable credentials. Because it converts an authorization code or refresh token into an access token, and, in OpenID Connect flows, an ID Token, it is one of the most security-sensitive surfaces of an authorization server. As a back-channel endpoint, it is called directly by the application rather than through the user's browser, which allows it to carry client authentication and to keep issued tokens out of the front-channel where they would be more exposed to interception or leakage through browser history and referrer headers.

Getting the token endpoint's role right also matters for correctly reasoning about what each OAuth 2.0 and OpenID Connect flow does. All OAuth 2.0 grant types except the Implicit Flow rely on the token endpoint to issue tokens; the Implicit Flow instead has the authorization endpoint issue the access token directly. Confusing these two endpoints, or conflating the token endpoint with introspection or activation endpoints that merely report on an existing token's state, leads to design and audit errors, such as assuming client authentication happens where it does not, or expecting an ID Token from a flow or endpoint that does not produce one.

Who it's relevant to

IAM engineers and integration developers

Engineers wiring applications to an authorization server call the token endpoint to exchange an authorization grant or refresh token for tokens. Knowing that it is a back-channel endpoint used by all OAuth 2.0 grant types except the Implicit Flow, and that it also returns an ID Token in the OIDC Authorization Code and Hybrid Flows, helps them select the right flow and handle each token type correctly.

Security architects

Architects evaluating an authorization design need to distinguish the token endpoint from the authorization endpoint and from introspection or activation endpoints. Because the token endpoint typically carries client authentication and keeps issued tokens off the front-channel, it is central to reasoning about where credentials are exposed and how flows differ in their security properties.

System administrators operating an authorization server

Administrators configuring products such as PingFederate or Okta manage the token endpoint's supported grant types and client authentication methods. Understanding that its exact behavior depends on the deployment and profile helps them configure and troubleshoot token issuance without conflating it with endpoints that only report on an existing token's state.

Inside Token Endpoint

Token request

An HTTP POST request from the client to the token endpoint, typically carrying a grant_type parameter that identifies the OAuth 2.0 grant being exercised (for example authorization_code, refresh_token, or client_credentials). Additional parameters vary by grant and profile.

Client authentication

The mechanism by which a confidential client proves its identity to the token endpoint. Depending on configuration this may use client_secret_basic, client_secret_post, private_key_jwt, or mutual TLS. Public clients typically cannot authenticate and instead rely on measures such as PKCE.

Access token

The primary credential the token endpoint issues for delegated authorization under OAuth 2.0. It may be opaque or self-contained (for example a JWT), depending on deployment. Note that being signed is not the same as being encrypted.

Refresh token

An optional long-lived credential returned by the token endpoint in many configurations, used by the client to obtain new access tokens without re-involving the resource owner. Its issuance and rotation behavior depend on the authorization server configuration.

ID token (OIDC)

When OpenID Connect is layered on top of OAuth 2.0, the token endpoint returns an ID token as part of the authentication result. In OIDC Core, this is defined for the Authorization Code Flow in Section 3.1.3.6 and for the Hybrid Flow in Sections 3.3.3.6 and 3.3.3.7. The ID token is an authentication assertion about the end user and is distinct from the access token.

PKCE parameters

For the authorization code grant, the code_verifier is sent to the token endpoint and validated against the previously supplied code_challenge. This is commonly required for public clients and increasingly recommended for confidential clients depending on profile.

Token response

A JSON response typically including access_token, token_type, and often expires_in, scope, and refresh_token; when OIDC is in use it also includes id_token. Exact fields depend on the grant and configuration.

Common questions

Answers to the questions practitioners most commonly ask about Token Endpoint.

Does calling the token endpoint authenticate the user?

No. The token endpoint is part of OAuth 2.0's delegated authorization framework and, on its own, issues tokens rather than performing user authentication. User authentication happens earlier at the authorization server's authentication step, typically during the authorization request. When OpenID Connect is layered on top, the token endpoint may return an ID token that carries authenticated user claims, but the act of exchanging a grant at the token endpoint is not itself an authentication event. Distinguishing the authorization server's authentication step from the token exchange is important when reasoning about where identity is actually verified.

Are the tokens returned by the token endpoint encrypted because they are signed?

Not necessarily. Signing and encryption are separate protections. A JWT-based access token or an OIDC ID token is commonly signed (a JWS) to provide integrity and origin authenticity, but signing alone leaves the contents readable to anyone who can decode the token. Confidentiality requires encryption (a JWE), which is a separate, optional step depending on configuration. Assuming a signed token hides its claims is a common error; treat any unencrypted signed token as effectively readable in transit and at rest unless additional transport or payload encryption is applied.

How does a client authenticate itself to the token endpoint?

It depends on the client type and the methods the authorization server supports. Confidential clients typically authenticate using a client secret (for example via client_secret_basic or client_secret_post) or with stronger methods such as private_key_jwt or mutual TLS, depending on the deployment and supported profiles. Public clients, such as many single-page and native apps, generally cannot hold a secret securely and instead rely on mechanisms like PKCE to protect the authorization code exchange rather than on client authentication at the token endpoint. The specific methods available vary by authorization server and configuration.

Which grant types are typically exchanged at the token endpoint?

In most OAuth 2.0 deployments the token endpoint handles grants such as the authorization code grant (including its PKCE variant), the refresh token grant, and the client credentials grant. Some deployments may still support other grants, though certain legacy grants such as the resource owner password credentials grant are discouraged in current guidance. The exact set of supported grant types is a configuration and policy decision on the authorization server, so the endpoint's accepted grant_type values vary by vendor and profile.

When does the token endpoint return an ID token in addition to access and refresh tokens?

An ID token is returned by the token endpoint when OpenID Connect is in use and the flow calls for it. In the OIDC Authorization Code Flow, the ID token is returned from the token endpoint (see OIDC Core Section 3.1.3.6). In the Hybrid Flow, ID token handling at the token endpoint is described in OIDC Core Sections 3.3.3.6 and 3.3.3.7. A plain OAuth 2.0 exchange without the openid scope typically returns an access token and possibly a refresh token, but no ID token, since ID tokens are an OpenID Connect construct.

How should refresh token exchanges at the token endpoint be secured?

Refresh token exchanges warrant particular care because a refresh token can typically be used to obtain new access tokens over an extended period. Depending on configuration and profile, common measures include requiring client authentication for confidential clients, applying refresh token rotation so a used refresh token is invalidated and replaced, detecting reuse of a rotated token as a possible compromise signal, and binding tokens to the client or to transport-layer mechanisms. All refresh token traffic should occur over protected transport. The specific protections available depend on the authorization server and the profile in effect.

Common misconceptions

The token endpoint authenticates the end user.

The token endpoint operates within OAuth 2.0, a delegated authorization framework, and issues tokens; it does not by itself authenticate the end user. End-user authentication is handled at the authorization endpoint or identity provider. Authentication information about the user is only conveyed when OpenID Connect is layered on top, via the ID token.

The access token and the ID token are interchangeable.

They serve different purposes. The access token is used by the client to access protected resources under delegated authorization, while the OIDC ID token is an authentication assertion about the end user intended for the client. They should not be substituted for one another, and an access token is not intended to be inspected by the client as proof of authentication.

A signed token returned by the token endpoint is confidential.

Signing provides integrity and authenticity, not confidentiality. A signed JWT can still be read by anyone who obtains it unless it is also encrypted. Sensitive data should not be placed in a signed-only token, depending on deployment requirements.

Best practices

Serve the token endpoint only over TLS and require client authentication appropriate to the client type (for example private_key_jwt or mutual TLS for confidential clients, PKCE for public clients).

Enforce PKCE for the authorization code grant, validating the code_verifier against the previously registered code_challenge before issuing tokens.

Treat access tokens and OIDC ID tokens as distinct: use access tokens for resource authorization and ID tokens for end-user authentication, and validate each according to its purpose.

Validate ID tokens against the applicable OIDC Core sections for the flow in use (Section 3.1.3.6 for the Authorization Code Flow, Sections 3.3.3.6 and 3.3.3.7 for the Hybrid Flow), including signature, issuer, audience, and expiration checks.

Where refresh tokens are issued, consider rotation and revocation strategies suited to your risk profile, since default behavior varies by authorization server configuration.

Do not rely on signing alone to protect sensitive claims; apply token encryption where confidentiality is required, and keep secrets out of self-contained tokens that are only signed.