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	false
client_id	Unique identifier for the client (Relying Party).	N/A	true
client_secret	Secret shared with the OP, used for token endpoint authentication.	N/A	false
redirect_uri	List of allowed redirect URIs to which the OP may send authorization responses. Must match exactly what the client requests.	N/A	true
post_logout_redirect_uris	List of URIs the user may be redirected to after logout (front-channel logout).	N/A	false
pipe_id	Pipe reference. Pipe is run directly after user authentication. Use to transform or enrich token content.	N/A	false
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	false
request_object_keystore	Keystore used to verify signed OIDC request objects received through the request parameter. If type is omitted, PKCS12 is used. If alias is omitted, the first alias in the keystore is used. If key_password is omitted, password is used.	N/A	false
id_token_headers	Optional JOSE header parameters to include in issued ID Tokens.	N/A	false
id_token_claims	JSON map of custom claims to include in the ID Token payload.	N/A	false
access_token_headers	Optional JOSE headers for JWT access tokens (if enabled).	N/A	false
access_token_claims	Custom claims added to the JWT access token payload.	N/A	false
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	false
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	false
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	false
userinfo_pipe_id	Used to generate userinfo data when incoming access tokens is of JWT type.	N/A	false
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	false
redirect_on_error	When authentication fails, send a redirect back to RP.	false	false

Example

"rps" : [{
    "client_id" : "provided",
    "client_secret" : "provided",
    "redirect_uri" : ["https://auth.organisation.com/authenticate/oidcrp"],
    "redirect_on_error" : false,
    "post_logout_redirect_uris" : ["https://auth.organisation.com/authenticate/oidcrp/loggedout"],
    "pipe_id" : "optional_pipe_id",
    "app_tag":["app1","app2"],
    "request_object_keystore" : {
        "path" : "/fortified_test/request-object-client.p12",
        "password" : "secret",
        "type" : "PKCS12",
        "alias" : "request-object-signer",
        "key_password" : "secret"
    },
    "id_token_headers" : {
    },
    "id_token_claims" : {
        "sub": "${exports.subject}",
        "email": "${exports.mail}",
        "string_array_example": [ "value1","value2" ],
        "boolean_array_example": [ true,false ],
        "number_array_example": [ 1,2,3 ],
        "complex_json_example": {
            "roles": [
                "report_submitter",
                "O-35482176",
                "56685"
            ]
        }
    },
    "access_token_headers" : {
        "typ": "at+jwt"
    },
    "access_token_claims" : {
        "custom_claim": "static_claim",
        "sub": "${exports.subject}"
    },
    "userinfo_claims": {
         "sub": "${exports.subject}",
         "name": "${exports.name}",
         "given_name": "${exports.givenName}",
         "family_name": "${exports.familyName}",
         "email": "${exports.email}",
         "email_verified": "${exports.email_verified}"
    }
}]

Signed Request Objects

If a client sends the OIDC request parameter, FortifiedID Integrity expects the request object to be signed and verified against the relying party's request_object_keystore.

If no request_object_keystore is configured for the relying party, request objects are rejected.

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.	true
fail_location	Fallback redirect target used when authorization fails and no failed_redirect entry matches the failure message.	false
failed_redirect	Array of pattern-based redirects. Each entry contains pattern and target. The first matching pattern is used.	false

Example

"authorization" : {
    "pipe_id" : "check_app_authorization",
    "fail_location" : "https://app.organisation.com/no-access",
    "failed_redirect" : [
        {
            "pattern" : ".*missing_role.*",
            "target" : "https://app.organisation.com/missing-role"
        },
        {
            "pattern" : ".*expired_contract.*",
            "target" : "https://app.organisation.com/contact-admin"
        }
    ]
}

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

Note

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.