OpenID Connect Provider

An OpenID Connect Provider (OP) is a server that authenticates users and provides identity information to applications using the OpenID Connect protocol. It’s a service that:

1. verifies who the user is (authentication),
2. issues identity tokens (usually in JWT format),
3. shares user information (like email, name, etc.) with trusted applications, called Relying Parties (RPs).

General parameters:

• OPENID_PROVIDER: boolean default false; enable OpenID Provider service.
• OPENID_PROVIDER_WITH_ENDPOINT_APPLICATION (opzionale): boolean default false; make the endpoint application reachable.

Parameters for the element where n is a positive natural number:

• OPENID_PROVIDER_CLIENT_ID_n: string; it identifies the OIDC client during authentication flows.
• OPENID_PROVIDER_CLIENT_SECRET_n: string; a confidential string shared between the OpenID Provider (OP) and the client application (also called the Relying Party)
• OPENID_PROVIDER_SUPPORTED_CALLBACK_CSV_n: string; specifies a comma-separated list of allowed redirect URIs (callback URLs) for the corresponding client
• OPENID_PROVIDER_TOKEN_BROKER_n: boolean default false; enables the token brokering functionality that allows propagating the original access token from the upstream remote Identity Provider across the federation chain. In a scenario where this OP also acts as a Relying Party to another OP (e.g. RP_A → OP_B (RP_B) → OP_C), this functionality allows RP_A to obtain the original access token from OP_C via OP_B, thus enabling direct access to the remote Identity Provider’s APIs.

The discovery endpoint is located in {context}/.well-known/openid-configuration; {context} can vary depending on where the rule is applied: it can be empty or, for example, /application if /application is the configured base path.

Token Brokering Usage

Having a federation chain like this RP_A -> OP_B (RP_B) -> OP_C:

• RP_A: The relying party application that wants to access OP_C’s original access token
• OP_B: Acts as an OpenID Connect Provider to RP_A
• RP_B: The same Identity Link acting as a Relying Party federated to OP_C
• OP_C: The original upstream Identity Provider that issues the access token

To retrieve the access token from the remote Identity Provider (OP_C), RP_A must make an authenticated GET request to OP_B’s endpoint using the access token received from OP_B in the initial authentication flow:

// RP_A makes an authenticated GET request with Bearer token
const response = await fetch('https://op-b.example.com/{context}/token', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${accessTokenFromOpB}`
  }
});
 
// The response is a classic OpenID Connect token response
// {
//   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",  // Original token from OP_C
//   "token_type": "Bearer",
//   "expires_in": 3600,
//   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
//   "refresh_token": "8xLOxBtZp8..."
// }
 
// Now RP_A can use the access_token to directly call OP_C's APIs
const apiResponse = await fetch('https://op-c.example.com/api/some-authenticated-api', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${tokenResponse.access_token}`
  }
});

This mechanism allows RP_A to access protected resources from OP_C without having to directly manage federation with OP_C, delegating this responsibility to OP_B which acts as an intermediary.