Skip to main content

OpenID Connect mechanism for SSO

Using the OpenID Connect mechanism for SSO is very similar to the general-purpose OpenID Connect authentication flow. Just append the sso_token and prompt=none parameters to the OpenID Connect authentication URL, for example https://{your-id-server}/openid/auth?sso_token={sso-token}&prompt=none. These parameters ensure the user is signed in without any interaction or confirmation dialogues (even in case of errors).

The rest of this page walks through wiring this up end-to-end between two example client sites.

Example: SSO between two OIDC client websites​

This tutorial is intended for developers and administrators configuring external websites where they want a user who is already signed in at one site to arrive at another site already signed in, without needing to click a sign-in link at all. All such sites must already support the normal OpenID Connect sign-in process.

Pre-requirements​

You have multiple websites which already use normal OpenID Connect authorisation for user sign-in.

Goal​

You want to avoid users needing to click "Sign in" when they arrive at a new site.

  1. User goes to site 1.
  2. User signs in at site 1.
  3. User goes to site 2 for the first time.
  4. User appears to already be signed in at site 2, without needing to interact with the UI.

How this works​

The goal is made possible by having the user's browser make a request to site 2 during site 1's authorisation process. During this request, site 2 receives a token which it can use later to sign the user in without interaction. Site 2 should set a cookie in the browser, which it reads later when the user arrives at site 2 for the first time. When this happens, site 2 redirects the user to the OpenID Connect authorisation URL with the token parameter included. If the token is valid, the user is signed in to site 2 and redirected back without interaction.

Step 1: Create an SSO callback endpoint​

Each site that wants to participate in this SSO scheme needs an endpoint which receives the token, adds browser cookies, and optionally returns an icon for display during authorisation.

The endpoint should be in the same domain as the site and its other authorisation callbacks.

The endpoint should:

  • Read the query parameters added to the call:
    • sso-token — the single-use SSO token.
    • sso-validity — the token's validity time in minutes from the time of the request, after which the token is invalidated if still unused.
  • Store the received information, and add cookies to the browser from the site's own domain. The cookies should contain enough information to use the above data later.
  • Optionally return a small logo image file in the response, since this request came from an <img src="callback-url" /> element.

Step 2: Provide the callback URL​

Go to the site's OpenID Connect client configuration in Trivore ID, find the Single Sign-On Callback URL field, and enter the callback endpoint's URL there.

Step 3: Add a Single Sign-On target​

Each target client is sent its own SSO token, and each SSO token works only with that specific client.

In the Trivore ID Management UI, go to the Single Sign-On view.

Every site has its own OpenID Connect client registered. For each site:

  1. Click Add, and select OpenID Connect as the mechanism.
  2. Select the site's OpenID Connect client.
  3. Configure other details if needed.
  4. Save the new target.

Step 4: Use the SSO token when an unsigned-in user arrives​

When a new user arrives at a site, and the site's browser cookies show that they have an SSO token available for use, the site should redirect the user to the authorisation URL with extra parameters:

  • sso_token={user's SSO token} — the user's SSO token.
  • prompt=none — no interactive UI is shown to the user; sign-in fails if the token is invalid, and the user is redirected to the site's failure URI.

If the token was valid, the authorisation goes through without confirmation and the user is redirected to the success callback without interaction.

Last updated on