Relying Party

Note: There are two sections related to the OIDC Relying Party. This section describes when Fortified ID Access acts as an OIDC OpenID Provider (OP). If you are looking for information about when Access acts as an OIDC Relying Party (RP) against an external OIDC Provider, click the following link.

Relying party Configuration

client_secret and PKCE

client_secret is optional for a relying party that uses PKCE.

At the token endpoint, FortifiedID Integrity accepts either:

• client authentication with client_secret_basic or client_secret_post

• PKCE with code_verifier

If code_verifier is present, client_secret is not required. If neither client authentication nor PKCE is used, the token request is rejected.

Properties

Name	Description	Default value	Mandatory
app_tag	JsonArray containing strings used for filtering and similar operations.	N/A
client_id	Unique identifier for the client (Relying Party).	N/A
client_secret	Secret shared with the OP, used for token endpoint authentication.	N/A
redirect_uri	List of allowed redirect URIs to which the OP may send authorization responses. Must match exactly what the client requests.	N/A
post_logout_redirect_uris	List of URIs the user may be redirected to after logout (front-channel logout).	N/A
pipe_id	Pipe reference. Pipe is run directly after user authentication. Use to transform or enrich token content.	N/A
authorization	Optional per-application authorization configuration. Use this to run an authorization pipe before the final OIDC response is returned. See the App-specific authorization section below for details.	N/A
id_token_headers	Optional JOSE header parameters to include in issued ID Tokens.	N/A
id_token_claims	JSON map of custom claims to include in the ID Token payload.	N/A
access_token_headers	Optional JOSE headers for JWT access tokens (if enabled).	N/A
access_token_claims	Custom claims added to the JWT access token payload.	N/A
userinfo_claims	Claims to be fetched from the userinfo endpoint when access token is of opaque type. If NOT configured, access_token_claims will be used.	N/A
refresh_token_persist_pipe_id	Pipe to send the refresh token to. It is up to the administrator to decide what the pipe will do.	N/A
refresh_token_resolve_pipe_id	Pipe to load/resolve a refresh token. The pipe should also create and persist a new refresh token.	N/A
userinfo_pipe_id	Used to generate userinfo data when incoming access tokens is of JWT type.	N/A
client_credentials_pipe_id	Pipe to issue an access token when using the client_credentials grant. The client_credentials grant lets a client authenticate itself and obtain an access token to call APIs on its own behalf, without any end-user involved. Machine to machine.	N/A
redirect_on_error	When authentication fails, send a redirect back to RP.	false

Example

App-specific authorization

You can configure application-specific authorization for each relying party. This lets Fortified ID Access run an authorization pipe after the user has authenticated, but before the final OIDC response is returned to the client application.

If the authorization pipe succeeds, Access continues the flow as normal. Any properties returned from the pipe are added to global state and can be used in token or userinfo claim mappings.

If the authorization pipe fails, Access can:

• redirect the user to a configured failure location

• redirect the user to a specific target based on the pipe failure message

• fall back to the standard OIDC access_denied response to the RP

Properties

Name	Description	Mandatory
pipe_id	Pipe used to evaluate whether the authenticated user is authorized for this RP. If the authorization object is present, this property is required.
fail_location	Fallback redirect target used when authorization fails and no failed_redirect entry matches the failure message.
failed_redirect	Array of pattern-based redirects. Each entry contains pattern and target. The first matching pattern is used.

Example

Data sent to the authorization pipe

The authorization pipe receives a flattened input object containing:

• request data such as client_id, redirect_uri, response_type, scope, state, nonce and prompt

• the authenticated subject

• request headers

• values already available in global state

• remoteAddress

Use this when authentication alone is not enough and access must also be approved per application. A common pattern is to let the authorization pipe check roles, entitlements, group membership or similar business rules.