Category: OAuth & OIDC

Authorization Endpoint

Also known as: /authorize endpoint, /oauth2/authorize endpoint

Simply put

The authorization endpoint is the location at an authorization server where an application sends the user so they can grant or deny the application permission to access their data. The user typically interacts with this endpoint directly through their browser, and if access is granted, the server returns a result (such as an authorization code) that the application can later exchange for a token. It is where the user's consent is obtained, not where the final access credential is issued.

Formal definition

In the OAuth 2.0/2.1 authorization framework, the authorization endpoint is the authorization server endpoint used to interact with the resource owner and obtain an authorization grant. It is a redirection-based endpoint: the client directs the user agent to the endpoint (for example, the /authorize path in many implementations), and the endpoint is used to authenticate the resource owner and secure their authorization for the requested scope. In the authorization code flow, a successful interaction results in a redirect back to the client's registered redirect endpoint carrying an authorization code, which the client subsequently exchanges at the separate token endpoint for tokens. Note that the authorization endpoint governs delegated authorization; user authentication semantics (for example, ID token issuance) are defined by the OpenID Connect layer built on OAuth, not by OAuth's authorization endpoint alone. Exact query parameters, supported response types, and redirect behavior vary by profile and vendor deployment.

Why it matters

The authorization endpoint is where user consent is captured in delegated authorization flows, making it the point at which a user decides whether an application should be allowed to act on their behalf and within what scope. Because it is redirection-based and operates through the user's browser, it sits at the intersection of user experience and security: the parameters passed to it (such as requested scopes, response type, and the redirect target) determine what an application can ultimately obtain. Misconfiguration here, for example, permissive redirect handling, has historically been a common source of OAuth-related security weaknesses, which is why registered redirect endpoints and profile-specific validation matter.

It is also important to keep the authorization endpoint conceptually separate from the token endpoint. The authorization endpoint obtains an authorization grant (in the authorization code flow, an authorization code delivered via redirect); it is not where the final access credential is issued. That separation is deliberate: the code returned from the authorization endpoint is exchanged at the distinct token endpoint, typically over a direct back-channel call, so the tokens themselves are not exposed in the browser redirect. Conflating these two endpoints leads to design errors around where credentials live and how they are protected.

Equally critical is understanding what the authorization endpoint does and does not assert. Under OAuth 2.0/2.1, it governs delegated authorization, permission to access a resource, and does not by itself constitute user authentication. Authentication semantics, such as ID token issuance, are defined by the OpenID Connect layer built on top of OAuth. Treating a successful authorization endpoint interaction as proof of who the user is, rather than as consent to access, is a frequent and consequential category error in IAM designs.

Who it's relevant to

IAM Engineers and Application Developers

Engineers integrating applications with an authorization server work directly with the authorization endpoint when implementing the authorization code flow. They must construct correct requests (scopes, response type, redirect target), register redirect endpoints accurately, and ensure the authorization code is exchanged at the token endpoint rather than treating the endpoint's response as a final credential.

Security Architects

Architects rely on the separation between the authorization endpoint and the token endpoint to reason about where credentials are exposed and how consent is enforced. They also need to ensure that a successful authorization endpoint interaction is not mistaken for user authentication, and that authentication requirements are addressed through the OpenID Connect layer where applicable.

System Administrators Operating Authorization Servers

Administrators configuring platforms such as those from AWS Cognito, Microsoft Entra, or Auth0 manage how the authorization endpoint behaves, including redirect destinations and hosted or managed login experiences. They should validate that endpoint behavior aligns with the applicable profile and vendor documentation, since supported response types and redirect handling vary by deployment.

Compliance and Governance Reviewers

Reviewers assessing delegated access should understand that the authorization endpoint is where user consent is captured for a given scope. This matters when evaluating whether applications obtain only the access users have explicitly granted, though runtime enforcement of that access occurs at the resource server rather than at the authorization endpoint itself.

Inside Authorization Endpoint

Endpoint role in OAuth 2.0

The authorization endpoint is defined by OAuth 2.0 (RFC 6749) as the endpoint on the authorization server where the resource owner interacts to grant or deny delegated access. It is used in flows that involve user interaction, most notably the authorization code grant.

Authorization request parameters

Requests to the endpoint typically carry parameters such as response_type, client_id, redirect_uri, scope, and state. When OpenID Connect is layered on top, additional parameters such as nonce and, depending on configuration, prompt or acr_values may also be present.

User authentication and consent

Although the endpoint belongs to a delegated authorization framework, the authorization server generally performs user authentication and obtains consent here as prerequisite steps before issuing an authorization grant. The authentication mechanism itself is outside the scope of the OAuth 2.0 authorization endpoint definition.

Response and redirect

On success the endpoint returns a response to the registered redirect_uri. For the authorization code grant this is an authorization code (not a token); for other response types the returned artifacts differ depending on the flow and profile in use.

state parameter

An opaque value supplied by the client and returned unchanged, typically used to maintain state between the request and callback and to mitigate cross-site request forgery on the redirect.

Relationship to the token endpoint

The authorization endpoint is distinct from the token endpoint. In the authorization code grant, the authorization endpoint issues a code that the client subsequently exchanges at the token endpoint for tokens; the two serve different steps of the flow.

Common questions

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

Does the authorization endpoint authenticate the user?

Not directly as its defining function. The authorization endpoint is an OAuth 2.0 construct whose purpose is to obtain the resource owner's authorization (delegated authorization), typically by interacting with the user-agent. Authentication of the end user generally happens at this stage as a prerequisite, but the authentication mechanism itself is out of scope for the OAuth 2.0 authorization endpoint definition. When OpenID Connect is layered on top, the authorization endpoint is also used to initiate the authentication request, but the authentication itself is defined by OIDC Core rather than by the base OAuth 2.0 authorization endpoint. Treat identification, authentication, and the authorization grant as separate steps that happen to converge at this endpoint.

Is the authorization endpoint the same thing as the token endpoint?

No. They are distinct endpoints in OAuth 2.0 with different roles. The authorization endpoint interacts with the resource owner through the user-agent and, depending on the grant type, returns an authorization response such as an authorization code. The token endpoint is a back-channel endpoint the client calls to exchange that code (or other grant) for tokens such as access tokens, and depending on configuration, refresh tokens and ID tokens. Conflating the two obscures the front-channel versus back-channel distinction that underlies much of OAuth 2.0's security model.

Which OAuth 2.0 flows actually use the authorization endpoint?

In most deployments the authorization endpoint is used by grant types that require resource owner interaction, notably the authorization code grant (typically with PKCE for public and increasingly confidential clients). The implicit grant historically used it as well, though that flow is now generally discouraged in current security guidance. Flows without a user-agent interaction, such as the client credentials grant, do not use the authorization endpoint and go directly to the token endpoint. Consult the specific standard profile you are targeting, since recommended and permitted flows vary by profile and evolve over time.

How should redirect URIs be validated at the authorization endpoint?

In most secure deployments the authorization server performs exact string matching of the registered redirect URI rather than pattern or prefix matching, because loose matching is a well-known source of open redirect and token/code leakage risks. The specific matching rules and any allowances depend on the authorization server implementation and the security profile in use. Because the authorization response is returned via the front channel to this URI, treat redirect URI registration and validation as security-critical configuration rather than a convenience setting.

What is the role of the state and PKCE parameters at the authorization endpoint?

The state parameter is typically used by the client to maintain request-to-response correlation and to mitigate cross-site request forgery on the redirect, and the client should verify it on the authorization response. PKCE introduces a code_verifier and code_challenge to bind the authorization request to the later token exchange, mitigating authorization code interception. Both operate around the authorization endpoint request and response, but their exact requirements depend on client type and the profile you follow. Where current guidance applies, PKCE is commonly recommended for both public and confidential clients.

Should responses from the authorization endpoint be delivered over the query string, fragment, or form post?

This depends on the response mode, which typically varies by grant type and configuration. Authorization code responses are commonly returned in the query component, while some flows have historically used the fragment. Response modes such as form_post can return parameters in an auto-submitted HTML form to keep them out of the URL. Because the authorization response travels through the front channel and may be exposed in browser history, logs, or referrer headers depending on the mode, choose the response mode according to the sensitivity of the returned values and the security profile in scope.

Common misconceptions

The authorization endpoint issues access tokens.

In the authorization code grant, the authorization endpoint returns an authorization code, which is then exchanged for tokens at the separate token endpoint. Direct token issuance at the authorization endpoint depends on the response type and profile in use and is not the behavior of the code grant.

Because it handles user login, the authorization endpoint is an authentication mechanism.

OAuth 2.0 is a delegated authorization framework, not an authentication protocol. While the authorization server may authenticate the user as a prerequisite before granting access, defining how the user is authenticated to the relying party requires an authentication layer such as OpenID Connect on top of OAuth 2.0.

The authorization endpoint and the token endpoint are interchangeable or the same endpoint.

They are distinct endpoints serving different steps. The authorization endpoint involves resource owner interaction and produces a grant, while the token endpoint is a back-channel endpoint where the client obtains tokens. Their security requirements and usage differ.

Best practices

Always send and validate the state parameter to maintain request-callback binding and mitigate cross-site request forgery on the redirect.

Register and strictly match redirect_uri values so that responses from the authorization endpoint are only returned to expected client callbacks.

Prefer the authorization code grant so that the endpoint returns a code exchanged at the token endpoint, rather than exposing tokens through user-agent redirects.

If you need to authenticate the user rather than only delegate authorization, layer OpenID Connect on top and include the appropriate parameters such as nonce, rather than treating the authorization endpoint alone as an authentication mechanism.

Request the narrowest scope needed for the client's function to limit the access granted through the endpoint.

Treat the authorization endpoint and token endpoint as distinct components with separate security controls, and document which flow and profile (for example OAuth 2.0 authorization code, OIDC Core) each client uses.