Implicit Flow

There are two locations where configuration for an OIDC OpenID Provider (OP) using the Implicit Flow can be managed:

1. Authorization Endpoint – You can modify the authorization endpoint settings here.
2. Back-Channel Endpoints – By clicking the following link, you can manage back-channel endpoints such as UserInfo.

About

No identification is done by this authenticator. It acts as a controller for issuing Json Web Tokens (JWT). Typically this authenticator is the first point of contact coming from an OpenID Connect Relying Party, requesting identification.

This authentication controller can be considered a start and end touch point. The main purpose is to handle OpenID Connect specifics.

Actual user identification is done elsewhere.

When using this authenticator, the ID token is returned in the response.

Configuration

Note

Authenticator Type: OIDCImplicitFlow

Common Authenticator configuration can be found here.

Properties

Name	Description	Default value	Mandatory
chain	List of authenticators performing the actual authentication.	N/A	true
userinfo_endpoint_ttl	User info endpoint time to live in milliseconds.	60000	false
sign_ref	List of OIDC signing keys used for overlapping key rotation. Recommended for new configurations.	N/A	false
keystore	Legacy single-key keystore configuration used for JWT signing when sign_ref is not configured.	N/A	false
rps	List of relying parties. Must include at least one relying party.	N/A	true
required_request_parameters	Required parameters.	["response_type", "client_id", "redirect_uri", "scope", "nonce"]	false
request_object_audience	Expected aud value for signed request objects. If configured, the request object's audience must include this value.	N/A	false

Example

{
    "id": "auth00",
    "type": "OIDCImplicitFlow",
    "config": {
        "base_path": "/test/authn",
        "failure_location": "/authn/failure.html",
        "chain": [{
            "id" : "select",
            "required" : true
        }],
        "userinfo_endpoint_ttl" : 90000,
        "required_request_parameters": ["response_type", "client_id", "redirect_uri", "scope", "nonce"],
        "sign_ref" : [
            {
                "keystore" : {
                    "path" : "/fortified_test/oidc-2026-q1.p12",
                    "password" : "secret",
                    "key_password" : "secret",
                    "alias": "oidc-2026-q1",
                    "type" : "PKCS12"
                }
            }
        ],
        "rps" : [ {
            "client_id" : "provided",
            "client_secret" : "provided",
            "redirect_uri" : ["https://auth.organisation.com/authenticate/oidcrp"],
            "post_logout_redirect_uris" : ["https://auth.organisation.com/authenticate/oidcrp/loggedout"],
            "pipe_id" : "optional_pipe_id",
            "id_token_headers" : {
                "kid" : ""
            },
            "id_token_claims" : {
                "test_claim": "static_claim",
                "email": "${item.mail}",
                "nonce": "${request.nonce}"
            },
            "access_token_claims" : {
                "userinfo_claim_test": "static_claim",
                "email": "${item.mail}",
                "email_verified": true,
                "address": {
                    "street_address": "my address",
                    "postal_code": "my postal code"
                },
                "given_name": "${item.givenName}",
                "subject": "${item.subject}"
            }
        }]
    }
}

Note

For the OIDC signing-key model, overlapping rotation, and legacy compatibility, see OIDC signing keys.

Signed Request Objects

If the authorization request contains the OIDC request parameter, FortifiedID Integrity expects a signed request object.

To enable this, configure a request_object_keystore on the corresponding relying party. Unsigned request objects are not accepted.

Optionally configure request_object_audience on the authenticator to require a specific aud value in the signed request object.

Logging

On a successful authentication, an event is logged containing the following:

• WEB_100101
• IDENTIFIER (user traceid)
• DESTINATION_SERVICE_NAME (redirect URI)
• SOURCE_ADDRESS (user IP address)

Data sent to PIPE

All data put into the shared authentication state along with the HTTP headers are exposed and sent into the pipe.

Data put into the state by this authenticator is:

OIDC request data

Expected data from PIPE

In order to use data from PIPE the response must contain one item. All data from that item will be available under the exports scope ( ${exports.mail} ) during expansion, when creating the ID token and access token.

Available data for ID_token and Access Token claims

Data is extracted with the help of expansions.

The following scopes are available:

Scope	Description	Example
request	The current authentication request including HTTP headers and params	${request.client_id}
session	The current session.	${session.sub}
exports	Exports data. Note: All pipe data is available under the exports scope.	${exports.sub}