ID of the client initiating the authorization request.

The response type that the client is requesting. This will affect the response that is returned from the authorization request.

Supported Values:

• code: The authorization code will be returned as the code query parameter when redirecting to the registered callback endpoint.

An opaque value used by the client to maintain state between the request and callback. When Wristband redirects to the callback endpoint it will include the original state value in the state query parameter.

An opaque value used to associate the authorization request with an ID Token. The value is passed through unmodified from the authentication request to the ID Token. If present in the ID Token, clients MUST verify that the nonce claim value is equal to the value of the nonce parameter sent in the authorization request before trusting claims included in the ID token.

The authorization and token endpoints allow the client to specify the scope of the authorization request using the scope request parameter. In turn, the authorization server uses the scope response parameter to inform the client of the scopes of the access token issued. The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional requested scope.

Supported Scopes:

• openid - Required for OIDC requests.
• profile - Includes the following claims in the User Info response: name, given_name, family_name, middle_name, nickname, preferred_username, picture, gender, birthdate, zoneinfo, locale, updated_at
• email - Includes the following claims in the User Info response: email, email_verified
• phone - Includes the following claims in the User Info response: phone_number, phone_number_verified
• roles - Includes the following claims in the User Info response: roles
• offline_access - If specified the response from the Token Endpoint will return a refresh token along with the access token.

Required Scopes:

• openid

This field is used by clients to implement the Proof Key for Code Exchange (PKCE) extension of the OAuth 2 specification. The client first creates a code challenge which is sent to the server when requesting authorization. The client then uses the code verifier (the string used to create the code challenge) when exchanging the authorization code for an access token. In OAuth 2.1 it is required that clients use PKCE unless the following conditions are met:

1. The client is a confidential client.
2. In the specific deployment and the specific request, there is reasonable assurance by the authorization server that the client implements the OpenID Connect nonce mechanism properly.

Therefore, if the client is a confidential client and the nonce query parameter is specified, then the code_challenge query parameter is not required; otherwise, the code_challenge is required.

The method used for creating the code challenge. If the code_challenge query parameter is present in the authorization request, then the code_challenge_method is required; otherwise, it is not required.

Supported Methods:

• S256: The code challenge is a BASE64-URL-encoded string of a SHA256 hash of the code verifier.

Specifies whether the server should prompt the end user for re-authentication.

Supported Prompts:

• none: The Authorization Server MUST NOT prompt the user to authenticate. If the user does not already have an authenticated session then a login_required error is returned.
• login: The Authorization Server will always prompt the user to authenticate, even if the user already has an authenticated session.

Prompt is not a required field. If it's not specified as part of an authorization request, then the default behavior is as follows:

• If a valid auth session cookie is present, then an authorization code will automatically be created, and the user will be redirected to the callback endpoint without having to re-authenticate.
• If an auth session cookie is not present or invalid, then the user is redirected to the login page to authenticate.

Hint about the login identifier the end-user might use to log in. If provided, this value will be used to pre-populate the login identifier form field. Note, if a login hint value is provided and an existing auth session is detected, one of the login identifiers (email or potentially username if it's configured as a login identifier) for the user associated with the auth session must match the login hint value; otherwise, the existing auth session will be revoked and the user will have to login again.

Hint indicating which Identity Provider (IdP) the user should authenticate with. The value must match the name of an IdP enabled for the user's tenant. If a match is found, the user is automatically taken to that IdP's login page. If no match is found, then the IdP hint is ignored and the regular login page is shown.

HTTP-only cookie representing a user's authenticated session.