authorization_
Registry Context
The authorization_endpoint metadata value is the URL where clients direct resource owners to begin authorization. It is required unless the server supports no grant types that use an authorization endpoint.
Technical Summary
Identifies the OAuth 2.0 authorization endpoint defined by RFC 6749. Its URI may contain a form-encoded query component that must be retained when adding parameters, but it must not contain a fragment.
When Used
Used by clients discovering an OAuth authorization server's configuration to locate its authorization endpoint.
Normative Requirements
Clients
RFC 6749 - Section 3.1
retain the authorization endpoint URI's existing query component when adding query parameters.
Condition: when the endpoint URI contains a query component
The query component MUST be retained when adding additional query parameters.
Authorization servers
RFC 6749 - Section 3.1
include a fragment component in the authorization endpoint URI.
The endpoint URI MUST NOT include a fragment component.
RFC 6749 - Section 3.1
require TLS for requests sent to the authorization endpoint.
The authorization server MUST require the use of TLS when sending requests to the authorization endpoint.
RFC 6749 - Section 3.1
support HTTP GET at the authorization endpoint.
The authorization server MUST support the use of the HTTP "GET" method.
RFC 6749 - Section 3.1
verify the identity of the resource owner before obtaining an authorization grant.
Condition: when operating the authorization endpoint
The authorization server MUST first verify the identity of the resource owner.
RFC 6749 - Section 3.1
treat parameters sent without a value as omitted.
Condition: when processing authorization endpoint parameters
Parameters sent without a value MUST be treated as if they were omitted from the request.
RFC 6749 - Section 3.1
ignore unrecognized authorization request parameters.
The authorization server MUST ignore unrecognized request parameters.
RFC 8414 - Section 2.1
digitally sign or MAC the signed metadata using JWS.
Condition: when providing signed metadata
The signed metadata MUST be digitally signed or MACed using JSON Web Signature (JWS).
RFC 8414 - Section 2.1
include an iss claim identifying the attesting party in signed metadata.
Condition: when providing signed metadata
The signed metadata MUST contain an "iss" (issuer) claim denoting the party attesting to the claims.
RFC 8414 - Section 2
include the authorization_endpoint metadata value.
Condition: unless no supported grant types use the authorization endpoint
This is REQUIRED unless no grant types are supported that use the authorization endpoint.
RFC 6749 - Section 3.1
publish an authorization endpoint URI containing an application/x-www-form-urlencoded query component.
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted query component.
RFC 6749 - Section 3.1
support HTTP POST at the authorization endpoint.
The authorization server MAY support the use of the "POST" method as well.
RFC 8414 - Section 2.1
provide authorization server metadata values in signed_metadata.
Metadata values MAY also be provided as a "signed_metadata" value.
metadata consumer
RFC 8414 - Section 2.1
give signed metadata values precedence over corresponding plain JSON metadata values.
Condition: if the consumer supports signed metadata
Metadata values conveyed in the signed metadata MUST take precedence over corresponding values conveyed using plain JSON elements.
protocol participants
RFC 6749 - Section 3.1
include request or response parameters more than once.
Condition: at the authorization endpoint
Request and response parameters MUST NOT be included more than once.
Validation Guidance
Require authorization_endpoint when the server supports any grant type that uses the authorization endpoint.
Validate authorization_endpoint as a URL and reject a fragment component.
Preserve any existing query component when constructing an authorization request.
Verify that requests to the authorization endpoint are required to use TLS; RFC 6749 Section 3.1 does not independently state that the metadata URL must use the https scheme.
Verify that the authorization endpoint supports HTTP GET. POST support is optional.
When signed metadata is supported, validate its JWS protection and iss claim, and prefer its authorization_endpoint value over the plain JSON value.
Verify that the authorization server authenticates the resource owner before issuing an authorization grant.
Treat valueless parameters as omitted, ignore unrecognized request parameters, and reject duplicate request or response parameters.
Security Notes
RFC 9700 - Section 2.1.2
RFC 9700 advises clients not to use the implicit grant or other response types that return access tokens from the authorization endpoint unless injection and leakage risks are mitigated; authorization code flows are preferred.
Reference
Details
- Entry Id
authorization_endpoint - Metadata Name
authorization_endpoint - Metadata Description
URL of the authorization server's authorization endpoint- Change Controller
IESG- Reference
RFC8414 - Section 2