Authorization endpoint
This is the starting point for OpenID Connect flows.
Last updated
This is the starting point for OpenID Connect flows.
Last updated
The authorization endpoint is typically used to identify a user and obtain an authorization code, which is then later exchanged for an ID token and access token. (When using the Implicit Flow type (see authenticators), the ID token and access token is delivered directly.)
The authorization endpoint is represented by authenticators, either an authorization code flow or an implicit flow authenticator. (See OIDC authenticators for configuration)
No identification is done by these authenticators. They act as a controller for issuing Json Web Tokens (JWT). Typically these authenticators is the first point of contact coming from an OpenID Connect Relying Party, requesting identification.
Actual user identification is done elsewhere.
Note: Mandatory request parameters can be configured on each OIDC authenticator. Parameters marked as mandatory are the default behaviour.
Parameter | Description | Mandatory |
---|---|---|
client_id
Identifies the client and must match the value configured in FortifiedID Integrity.
redirect_uri
Redirect location where the authorization code or JWTs should be sent. It must match the value configured in FortifiedID Integrity.
response_type
'code' for authorization code flows. 'id_token' or 'id_token token' for implicit flows.
response_mode
Determines how the response should be returned. Supported values are 'form_post' and 'query'. Defaults to query.
scope
'openid' is required for authentication requests.
state
A value that is returned untampered in the response. The client application (Relying Party) can use it to remember the state of its interaction with the end user at the time of the authentication call.
max_age
Allowed time, in seconds, since the last time the end user was authenticated by FortifiedID Integrity.
nonce
The value is returned, as is, in the ID token (Part of the JWT). Used to mitigate replay attacks.
code_challenge
A code challenge for PKCE, to prevent CSRF and authorization code injection attacks. Supported hash method for client generation of this challenge is S256.
prompt
If prompt has value 'login' or no prompt parameter is used, the user is prompted to authenticate.
If prompt has value 'none' and a user session exists, the user is silently authenticated. If prompt has value 'none' and the user session does NOT exist, an error is returned.