Parameters

The Accept-Language request HTTP header indicates the natural language and locale that the client prefers.

Space-separated Authentication Context Class Reference values the authentication is requested to satisfy,
in order of preference.

• urn:hedia:acr:regular — satisfied by any authenticated user.
• urn:hedia:acr:elevated — requires the End-User to verify their password.

This parameter requests the acr Claim as a Voluntary Claim, so the Authorization Server attempts to
satisfy the requested class but does not treat an unmet one as a failed authentication. The class the
authentication actually satisfied is returned as the acr Claim of the ID token, and unrecognised values
are ignored, so clients must check that claim.

Requesting acr as an Essential Claim through the claims request parameter, which would require an
unmet class to fail the request, is not supported.

The client ID is a unique identifier for a client.

The code challenge is a string that is derived from the code verifier. It is used in situations where the client secret cannot be stored securely.

The code challenge method is used to indicate the hashing algorithm used to derive the code challenge.

Reserved for the Authorization Server. Clients must not set it.

Maximum Authentication Age: the allowable elapsed time in seconds since the End-User was last actively
authenticated. If the elapsed time is greater than this value, the End-User is actively re-authenticated
before the request continues, and 0 requires it on every request.

A completed re-authentication satisfies the requirement, however long the End-User took over it. The
auth_time Claim of the ID token reports when the authentication took place.

Space-delimited, case-sensitive list of values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent.

• none — no UI is shown. Returns login_required without an active session, or consent_required when the scopes are not yet approved.
• create — the End-User must authenticate starting from the signup page, even with an active session, and can still switch to signing in with an existing account. Defined by Prompt Create.
• login — the End-User must reauthenticate, even with an active session.
• consent — the End-User must approve the requested scopes again, even if approved previously; declining returns access_denied.

login consent is the only supported combination; any other combination of known values is rejected with invalid_request.

Unrecognised values are ignored, so clients must not rely on a prompt being honoured.

If omitted, or without a recognised value, the End-User is prompted only when needed.

The redirect URI is where the End-User will be redirected after authorization.

The response type is a string that indicates the type of authorization request. The only supported response type is "code".

Space-delimited, case-sensitive list of <action>:<scope> permissions, such as read:name.

A client either follows the permissions the End-User has approved, or fixes a subset of them:

• omitted or empty — the authorization follows the End-User's approved permissions, so each token carries whatever they allow at the time it is issued. Consent is requested again when the app gains a permission they have not approved.
• a subset — the authorization is fixed to exactly those permissions. Requesting a permission the app is not allowed to ask for is rejected with invalid_scope, and requesting a different set later replaces the previous authorization.

Changing the requested scope replaces the authorization: any authorization code not yet redeemed, and
every refresh token previously issued to this client for this user, stop working and the End-User authorizes
again. A client that needs different scopes for different surfaces should use a client per surface.

On a refresh request, the value may only narrow what was already granted.

In a token response, this is the scope actually granted — for an authorization that follows the End-User's permissions, the set approved at that moment.

The state is a random string generated by the client that can be used to protect against cross-site request forgery attacks.