Skip to main content

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

Body

    response_type stringrequired

    Space-delimited response type. Use code for Authorization Code flow, token for Implicit, id_token for OIDC Implicit, or combinations for Hybrid flow.

    client_id stringrequired

    The client identifier registered at the authorization server.

    redirect_uri uri

    URI to redirect the user-agent to after the authorization decision.

    scope string

    Space-delimited list of requested scopes. Include openid for OpenID Connect flows.

    state string

    Opaque value returned unchanged in the redirect; protects against CSRF attacks.

    nonce string

    (OIDC) Associates the client session with the ID token and prevents replay attacks.

    code_challenge string

    (PKCE) Code challenge derived from the code verifier.

    code_challenge_method string

    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.

    request_uri string

    (PAR) Reference URI to a previously pushed authorization request. When present, all other parameters except client_id are ignored.

Responses

Authorization result delivered via redirect to redirect_uri

Loading...