id of the authorization server

You can include an optional parameter in the authentication request. This parameter increases the level of user assurance.

Note: You can also provide multiple space-delimited values. The authorization server chooses one and reflects the chosen value in any resulting tokens.

Obtained during either manual client registration or through the Dynamic Client Registration API. It identifies the client and must match the value preregistered in Okta.

A challenge for PKCE. The challenge is verified in the access token request.

Method used to derive the code challenge for PKCE

The display parameter to be passed to the external identity provider when performing social login

A space-delimited list of values indicating which authenticators to enroll in.

• If the enroll_amr_values parameter is specified, then the value for prompt must be enroll_authenticator.
• The parameter value is space-delimited, for example, pwd sms okta_verify is a valid request parameter value. You are prompted in the order of the amr values provided.

An Okta extension to the OpenID specification. A space-delimited list of scopes to be provided to the external identity provider when performing social login. These scopes are used in addition to the scopes already configured for the identity provider.

An Okta extension to the OpenID specification. The ID of the identity provider to use if there's no Okta session.

A token used to SSO into the client app

A username to pre-populate if prompting for authentication

Allowable elapsed time, in seconds, since the last time the end user was actively authenticated by Okta

A value that's returned in the ID token. It's used to mitigate replay attacks. The value is required for implicit and hybrid flows, but optional for auth code flows. See OIDC Specs.

If you don't specify the prompt parameter, the standard behavior occurs:

• If an Okta session already exists and meets the assurance requirements of the app, the user is silently authenticated. Otherwise, the user is prompted to authenticate.
• If scopes are requested that require consent and consent isn't yet given by the authenticated user, the user is prompted to give consent.

Callback location where the authorization code or tokens should be sent. It must match the value preregistered in Okta during client registration.

Any combination of code, token, and id_token. The combination determines the flow.

How the authorization response should be returned. If id_token or token is specified in the response_type, then query isn't allowed as a response mode. Defaults to fragment in implicit and hybrid flows.

The Referrer-Policy header is automatically included in the response when either the fragment or query parameter values are used. The header is set to Referrer-Policy: no-referrer.

Location where the authorization request payload data is referenced in an authorization request to the /authorize endpoint. This is returned from a Pushed Authorization Request at the /par endpoint.

A JWT created by the client that enables requests to be passed as a single, self-contained parameter.

• You must sign the JWT using either the app's client secret or a private key whose public key is registered on the app's JWKSet.
• You can't encrypt the JWT.

Note: See Build a JWT for client authentication for information on how to build a JWT.

• Okta supports the HMAC, RSA and ECDSA signature algorithms. HMAC signatures require that the client have a token_endpoint_auth_method that uses a client_secret. RSA and ECDSA signatures require that the client registers a public key.
• Okta recommends that you don't duplicate any request parameters in the JWT and the query URI. However, you can do so with state, nonce, code_challenge, and code_challenge_method. In those cases, the values in the JWT overrides the query URI values.
• Okta validates the request parameter in the following ways:
  1. iss is required and must be the client_id.
  2. aud is required and must be the same value as the authorization server issuer that mints the ID or access token. This value is published in the metadata for your authorization server.
  3. JWT lifetime is evaluated using the iat and exp claims, if present. If the JWT is expired or not yet valid, Okta returns an invalid_request_object error. Okta rejects JWTs that expire more than one hour in the future.
  4. Okta rejects the JWT if the jti claim is present and it has already been processed.

A space-delimited string of scopes requested

Okta one-time session token. This is an Okta extension to the OpenID specification. The sessionToken allows an API-based user sign-in flow.

A value that is returned with the token. The client app can use it to remember the state of its interaction with the end user at the time of the authentication call. It can contain alphanumeric, comma, period, underscore, and hyphen characters.

Okta requires the OAuth 2.0 state parameter on all requests to the /authorize endpoint to prevent cross-site request forgery (CSRF). The OAuth 2.0 specification requires that clients protect their redirect URIs against CSRF by sending a value in the authorize request that binds the request to the user-agent's authenticated state. Using the state parameter is also a countermeasure to several other known attacks as outlined in OAuth 2.0 Threat Model and Security Considerations.

An absolute URI that identifies the target resource server that requests the access token.

The issued access token's aud claim is set to this value. Repeat the parameter to request a token that's valid for multiple resource servers (?resource=https://api.example.com&resource=https://other.example.com, for example).

See Resource Parameter.

Note: Multiple audiences for custom authorization servers is a self-service Early Access (EA) feature. See Manage Early Access and Beta features to enable the feature.