> For the complete documentation index, see [llms.txt](https://docs.fortifiedid.se/access/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fortifiedid.se/access/key-components/modules/oidc/relying-party.md).

# Relying Party

Configuration and usage guidance for Relying Party in Fortified ID Access.

**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](/access/key-components/authenticators/protocol-managers/oidc/oidc-relying-party.md).

### 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.

{% tabs %}
{% tab title="Properties" %}

<table data-full-width="true"><thead><tr><th>Name</th><th>Description</th><th>Default value</th><th data-type="checkbox">Mandatory</th></tr></thead><tbody><tr><td><code>app_tag</code></td><td>JsonArray containing strings used for filtering and similar operations.</td><td>N/A</td><td>false</td></tr><tr><td><code>client_id</code></td><td>Unique identifier for the client (Relying Party).</td><td>N/A</td><td>true</td></tr><tr><td><code>client_secret</code></td><td>Secret shared with the OP, used for token endpoint authentication.</td><td>N/A</td><td>false</td></tr><tr><td><code>redirect_uri</code></td><td>List of allowed redirect URIs to which the OP may send authorization responses. Must match exactly what the client requests.</td><td>N/A</td><td>true</td></tr><tr><td><code>post_logout_redirect_uris</code></td><td>List of URIs the user may be redirected to after logout (front-channel logout).</td><td>N/A</td><td>false</td></tr><tr><td><code>pipe_id</code></td><td>Pipe reference. Pipe is run directly after user authentication. Use to transform or enrich token content.</td><td>N/A</td><td>false</td></tr><tr><td><code>authorization</code></td><td>Optional per-application authorization configuration. Use this to run an authorization pipe before the final OIDC response is returned. See the <code>App-specific authorization</code> section below for details.</td><td>N/A</td><td>false</td></tr><tr><td><code>request_object_keystore</code></td><td>Keystore used to verify signed OIDC request objects received through the <code>request</code> parameter. If <code>type</code> is omitted, <code>PKCS12</code> is used. If <code>alias</code> is omitted, the first alias in the keystore is used. If <code>key_password</code> is omitted, <code>password</code> is used.</td><td>N/A</td><td>false</td></tr><tr><td><code>id_token_headers</code></td><td>Optional JOSE header parameters to include in issued ID Tokens.</td><td>N/A</td><td>false</td></tr><tr><td><code>id_token_claims</code></td><td>JSON map of custom claims to include in the ID Token payload.</td><td>N/A</td><td>false</td></tr><tr><td><code>access_token_headers</code></td><td>Optional JOSE headers for JWT access tokens (if enabled).</td><td>N/A</td><td>false</td></tr><tr><td><code>access_token_claims</code></td><td>Custom claims added to the JWT access token payload.</td><td>N/A</td><td>false</td></tr><tr><td><code>userinfo_claims</code></td><td>Claims to be fetched from the userinfo endpoint when access token is of opaque type. If NOT configured, <code>access_token_claims</code> will be used.</td><td>N/A</td><td>false</td></tr><tr><td><code>refresh_token_persist_pipe_id</code></td><td>Pipe to send the refresh token to. It is up to the administrator to decide what the pipe will do.</td><td>N/A</td><td>false</td></tr><tr><td><code>refresh_token_resolve_pipe_id</code></td><td>Pipe to load/resolve a refresh token. The pipe should also create and persist a new refresh token.</td><td>N/A</td><td>false</td></tr><tr><td><code>userinfo_pipe_id</code></td><td>Used to generate userinfo data when incoming access tokens is of JWT type.</td><td>N/A</td><td>false</td></tr><tr><td><code>client_credentials_pipe_id</code></td><td>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.</td><td>N/A</td><td>false</td></tr><tr><td><code>redirect_on_error</code></td><td>When authentication fails, send a redirect back to RP.</td><td><code>false</code></td><td>false</td></tr></tbody></table>
{% endtab %}

{% tab title="Example" %}

```json
"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}"
    }
}]
```

{% endtab %}
{% endtabs %}

## 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

{% tabs %}
{% tab title="Properties" %}

<table data-full-width="true"><thead><tr><th>Name</th><th>Description</th><th data-type="checkbox">Mandatory</th></tr></thead><tbody><tr><td><code>pipe_id</code></td><td>Pipe used to evaluate whether the authenticated user is authorized for this RP. If the <code>authorization</code> object is present, this property is required.</td><td>true</td></tr><tr><td><code>fail_location</code></td><td>Fallback redirect target used when authorization fails and no <code>failed_redirect</code> entry matches the failure message.</td><td>false</td></tr><tr><td><code>failed_redirect</code></td><td>Array of pattern-based redirects. Each entry contains <code>pattern</code> and <code>target</code>. The first matching pattern is used.</td><td>false</td></tr></tbody></table>
{% endtab %}

{% tab title="Example" %}

```json
"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"
        }
    ]
}
```

{% endtab %}
{% endtabs %}

### 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`

{% hint style="info" %}
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.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.fortifiedid.se/access/key-components/modules/oidc/relying-party.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.