Submit an authorization request
POST/oauth2/auth
Alternative to the GET form that accepts authorization request parameters as a
URL-encoded form body instead of query parameters. Support for POST is optional
per RFC 6749 Section 3.1; servers are required to support GET.
Note: Pushed Authorization Requests (PAR) use a separate dedicated PAR endpoint
for the initial POST — the subsequent call to this authorization endpoint then
carries only client_id and request_uri via GET.
Response codes and redirect behaviour are the same as for the GET endpoint.
Refer to the introduction section for details on how to configure this use case.
Request
- application/x-www-form-urlencoded
Body
Space-delimited response type. Use code for Authorization Code flow, token for Implicit, id_token for OIDC Implicit, or combinations for Hybrid flow.
The client identifier registered at the authorization server.
URI to redirect the user-agent to after the authorization decision.
Space-delimited list of requested scopes. Include openid for OpenID Connect flows.
Opaque value returned unchanged in the redirect; protects against CSRF attacks.
(OIDC) Associates the client session with the ID token and prevents replay attacks.
(PKCE) Code challenge derived from the code verifier.
Possible values: [S256, plain]
(PKCE) Method used to derive the code challenge. S256 (BASE64URL(SHA256(ASCII(code_verifier)))) is mandatory-to-implement on the server per RFC 7636 and MUST be used by clients unless they cannot support it. plain exists only for constrained environments.
(PAR) Reference URI to a previously pushed authorization request. When present, all other parameters except client_id are ignored.
Responses
- 302
- 400
Authorization result delivered via redirect to redirect_uri
Invalid request — returned when redirect_uri is missing or does not match any registered URI and the error cannot be communicated via redirect