Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

04.05 Configuring OIDC

SimpleRisk does not currently ship native OpenID Connect (OIDC) support. The Authentication Extra federates via SAML 2.0 and LDAP/AD only. This article explains the available alternatives and why most OIDC-capable IdPs can be configured for SimpleRisk via SAML instead.

Requires: Authentication Extra

Federation via the Authentication Extra at simplerisk/extras/authentication/. The Extra supports SAML 2.0 and LDAP/AD. Native OIDC is not available; this article explains the alternatives.

Why this matters

OpenID Connect (OIDC) is the OAuth 2.0-based identity federation protocol that has gained substantial enterprise adoption since around 2015 — it's lighter-weight than SAML, JSON-based instead of XML-based, and the de facto choice for new SaaS integrations. Customers exploring SimpleRisk SSO often start by asking "does it support OIDC?"

The honest answer: no, not natively. The Authentication Extra implements SAML 2.0 and LDAP/AD. There's no extras/authentication/oidc.php handler, no OIDC client library bundled in the vendor tree, no settings page for OIDC issuer / client ID / client secret. Configuring OIDC against SimpleRisk requires either using the IdP's SAML endpoint instead, or fronting OIDC with a SAML-capable broker.

This article exists to spell out those alternatives so the integration conversation lands in the right place quickly. It isn't a "how to configure native OIDC" guide (there's nothing to configure natively), but it covers the practical paths.

The good news

Every major OIDC-capable IdP also speaks SAML 2.0. OIDC and SAML are different wire protocols, but they cover overlapping use cases (federated authentication for browser-based applications). The IdPs SimpleRisk customers most commonly want to integrate with (Azure AD / Microsoft Entra ID, Okta, Auth0, Google Workspace, Ping Identity, OneLogin, AWS IAM Identity Center) all expose both protocols. Configuring SimpleRisk against the SAML endpoint of any of these IdPs is fully supported.

The user experience is identical. Users land on SimpleRisk, get redirected to the IdP, authenticate (with whatever MFA / Conditional Access the IdP enforces), and bounce back to SimpleRisk authenticated. From the user's perspective, "SAML SSO" and "OIDC SSO" look the same — a redirect-bounce login flow. The protocol differences matter to the implementer, not to the user.

If your IdP supports both, configure SAML and stop reading. See Configuring SAML SSO for the walk-through. The rest of this article is for the narrow case where the IdP genuinely doesn't speak SAML.

When the IdP only supports OIDC

A handful of newer IdPs and identity-provider-as-a-service platforms only expose OIDC. If your environment is one of these, the path forward is one of:

Option A: Federate the OIDC IdP through a SAML-capable broker

A broker IdP (one that speaks both SAML and OIDC) sits between the OIDC IdP and SimpleRisk:

  • Users authenticate against the OIDC IdP (the system of record).
  • The broker (e.g., Azure AD, Okta) is configured as a federation relay — it accepts the OIDC assertion and re-issues a SAML assertion for SimpleRisk.
  • SimpleRisk talks SAML to the broker; the broker talks OIDC to the original IdP.

This is the typical enterprise pattern when an organization runs multiple IdPs (corporate identity in Azure AD, project-specific identity in Auth0, etc.). The broker becomes the single SAML SP-facing surface for downstream applications.

The cost: a broker license and the federation configuration. The benefit: SimpleRisk and any other SAML-only application gets the OIDC IdP's identity through a stable SAML interface.

Option B: Use LDAP/AD if available

If the OIDC IdP also exposes an LDAP-compatible directory (some do, via gateway or sync), configure SimpleRisk against the LDAP path. See Active Directory and LDAP. This is appropriate when:

  • The user base is small enough that the LDAP path's lower-fidelity attribute mapping and lack of MFA-at-the-protocol-level isn't a blocker.
  • The LDAP gateway is reasonably reliable (some OIDC-IdP LDAP gateways have known stability issues).

Option C: Pre-provision users and skip federation

For smaller deployments, the practical answer is sometimes "skip SSO." Use Core local authentication (Local Authentication and Password Policies), enforce MFA (Multi-Factor Authentication), and pre-provision users via the v2 API. The user count where this stops scaling depends on the program; for a 20-user install, local auth with MFA is operationally simpler than fronting an OIDC IdP through a broker.

Option D: Open a feature request

Native OIDC support is a recurring request and may ship in a future release. The way to influence that prioritization is to file the request via the SimpleRisk support channel; see Getting Help. Include the specific IdP, the use case, and why SAML federation isn't viable for your environment.

What "OIDC support" would look like if added

For context, a future native OIDC implementation would look like:

  • A new section in the Authentication Extra's settings UI for OIDC configuration.
  • Settings for the OIDC discovery URL (https://your-idp.example.com/.well-known/openid-configuration), client ID, client secret, scopes (openid profile email), and callback URL.
  • An OIDC client library bundled with the Extra (likely jumbojett/openid-connect-php or similar).
  • A type='oidc' user type for OIDC-provisioned users, alongside the existing type='saml' and type='ldap'.
  • The same auto-provisioning, attribute-mapping, and group-to-team mapping behaviors as the existing SAML and LDAP integrations.
  • IdP-specific guidance for the major IdPs (Azure AD, Okta, Google Workspace, Auth0, Keycloak).

None of this exists today. Track future SimpleRisk releases for native OIDC support; in the meantime, use one of the alternatives above.

Common pitfalls

  • Assuming native OIDC works because the documentation mentions OIDC. This article (and the chapter README) mention OIDC; the codebase doesn't implement it. Don't waste time looking for the OIDC settings page — it isn't there.

  • Trying to use the SAML configuration with OIDC URLs. The SAML configuration accepts SAML metadata XML or a SAML metadata URL; pointing it at an OIDC discovery URL won't work. The two protocols use different metadata formats and different wire flows.

  • Configuring the IdP for OIDC and then expecting SAML to "auto-detect." Most IdPs configure SAML and OIDC as separate applications. To use SAML, configure a SAML application on the IdP side; the OIDC application stays separate (and unused for SimpleRisk).

  • Skipping SSO entirely without considering the operational cost. Local auth at scale (50+ users) means manual provisioning, manual deprovisioning, and per-user password management. The break-even with SSO setup effort comes in pretty quickly. If the user count is growing, plan for SAML or a broker rather than indefinitely deferring it.

  • Asking the IdP team for "OIDC for SimpleRisk" without exploring SAML first. The IdP team will configure what you ask for. Ask for SAML; the configuration on their side is comparable in effort, and the SimpleRisk side actually supports it.

Related