Relution as Identity Provider

From version 26.5.0, Relution can act as its own OpenID Connect / OAuth2 Identity Provider — client applications are registered directly in Relution, allowing users to sign in with their existing Relution account across all connected applications.

Feature overview #

• Standard OIDC login flow using the Authorization Code flow with PKCE.
• Per-client configurable scopes (profile, email, phone, relution), including a consent screen shown to users. The relution scope provides Relution-specific data (e.g. organization membership).
• Single sign-out: both RP-initiated logout and OIDC Back-Channel Logout 1.0 are supported.
• Signing keys (JWK): The keys used to sign tokens are automatically managed and regularly renewed by Relution — no action is required.

Revoking signing keys #

Automatic rotation fully covers normal operation. For exceptional cases (e.g. a security incident), a signing key can additionally be revoked manually. Note that connected applications (relying parties) may still have the previous key cached for a while, so tokens signed with it may not be recognized as invalid until that cache expires.

Endpoints for integration #

At the top of the Identity Provider settings page, the issuer URL and the discovery document (.well-known/openid-configuration) are provided and can be copied directly. The discovery document itself can be used to look up any further technical endpoints (e.g. the JWKS URI) without assembling them manually.

IdP chaining #

Relution can also be chained behind an upstream identity provider (e.g. Microsoft Entra ID → Relution → connected application).

Registering a client #

A dedicated client is created for each connected application:

• Name: Freely chosen, shown to users on the consent screen, and used by administrators to distinguish multiple clients.
• Client ID and client secret: Generated automatically and required by the connecting application (relying party).
• Redirect URI(s): Provided by the connecting application and must be entered accordingly.
• Scopes: Scopes configured as required or optional must be explicitly requested by the connecting application during the login flow.
• Admin consent: Consent for all of a client’s scopes can be pre-approved by administrators (all-or-nothing, not per individual scope) — users are then not prompted to accept them on the consent screen the first time they log in to the application.

Visibility by organization level #

The organization level at which a client is registered determines which users can sign in through it:

• Global: All users across the entire system can sign in.
• Meta organization: All users of the meta organization and its suborganizations can sign in.
• Suborganization: Only users of that specific suborganization can sign in.

Token preview #

A preview of the resulting token claims can be viewed for a client’s current scope configuration — making it possible to check in advance which information a connected application would receive in the token.

Logging #

Logins through the Identity Provider are recorded both in the audit log and in the respective user’s login history.