Skip to main content

OpenID Connect

Trivore ID includes a certified OpenID Connect (OIDC) provider, so your applications can delegate sign-in to Trivore ID instead of building and maintaining their own authentication. This page introduces what that gets you; for the technical details of implementing a client against it, see the Developer Guide's OpenID Connect section.

What OpenID Connect is​

OpenID Connect is an identity layer built on top of the OAuth 2.0 authorization framework. OAuth 2.0 on its own is about authorization — letting an application act on a user's behalf, or access an API, without needing that user's actual credentials. OIDC adds authentication on top of it: a standard way for an application to verify who a user actually is, and to obtain basic profile information about them.

A few terms recur throughout this documentation:

  • OpenID Provider (OP) — the identity provider itself, in this case Trivore ID. It authenticates the user and vouches for their identity.
  • Relying Party (RP) — your application or service, once registered as an OIDC client with the OP. It relies on the OP's authentication rather than handling credentials itself.
  • ID token — a signed token (a JWT) the OP issues after a successful sign-in, containing claims that identify the user — who they are, not what they're allowed to do.
  • Access token — a token your application uses to call APIs on the user's behalf, such as the Management API.
  • Scopes and claims — a client requests a set of scopes; each scope grants access to a corresponding set of claims (individual pieces of user data, such as name or email address) in the ID token, access token, or UserInfo response.

The most common way a user reaches your application through Trivore ID is the Authorization Code flow: your application redirects the user's browser to Trivore ID's authorization endpoint, the user authenticates (and consents, if required), and Trivore ID redirects back to your application with a code it exchanges — server-side — for the actual tokens. This keeps tokens out of the browser's URL bar and history.

Trivore ID being an OpenID Certified provider means its implementation has been tested against the official conformance suite for the OIDC flows it supports — a standard OIDC client library should be able to integrate with it without Trivore-specific workarounds.

Signing users in​

Once your application is registered as an OIDC client, users authenticate against Trivore ID's standard OpenID Connect endpoints and your application receives tokens describing who they are — no need to store or handle passwords yourself. Up-to-date configuration for a given deployment, including endpoint URIs and supported scopes and claims, is always available at its discovery document, https://{your-id-server}/.well-known/openid-configuration.

Single Sign-On​

Beyond standard OIDC sign-in, Trivore ID can automatically sign a user into any number of other services the moment they sign in once — to Trivore ID itself, or to any other connected service — without the user noticing it happening. See Distributed Single Sign-On and Single Sign-Out for how this works and how to set it up.

New user registration​

Applications don't need to build their own account creation flow: the OIDC sign-in view can offer new user registration directly, either through a form built into Trivore ID or by handing off to your own registration flow at a custom URL. See User Registration for how to configure and link to it.

Identity verification during sign-in​

Sign-in can require a user to verify their email address or mobile number — either immediately, blocking sign-in until they do, or afterward, letting your application check verification status later via the UserInfo endpoint. See Email Address and Mobile Number Verification During Authentication for the available options. For a stronger form of identity verification entirely — a government-backed or in-person check of who the user really is — see Strong Identification instead.

Last updated on