Skip to content

Single sign-on

Single sign-on (SSO) lets people from your organisation sign in to the Cognassist web platform with the identity provider you already run, with no separate Cognassist password. Their existing account, and your password and multi-factor policies, apply as they do for your other applications.

You register an application with your identity provider, send us a few configuration values, and we complete the connection on our side. SSO is a managed setup, not self-serve, and it is optional: you do not need it to run an integration.

Should you turn SSO on?

SSO changes only how people sign in to the web platform. It is a good fit when everyone who will sign in is already in your identity provider, so you get one set of centrally managed credentials, your own security policies enforced, and access removed in one place when staff leave.

The catch on an FE estate is that SSO is all-or-nothing. When it is on, it applies to everyone who signs in, staff and learners alike, with no mixed mode where staff use SSO and learners stay on email accounts. Where your staff are in your directory but your learners are not, that all-or-nothing rule is what pushes a learner-heavy estate toward keeping everyone on email accounts.

For learner-heavy estates, keep everyone on email accounts

If any learner who needs to sign in is not in your identity provider, do not enable SSO, or those learners will be locked out. The recommended pattern for a learner-heavy estate is email-based accounts for everyone. Reserve SSO for a staff-only tenant where every person who signs in is already in your directory.

This is the same identity decision described in planning your integration. Pick the model that covers everyone before you build.

SSO is separate from API authentication. Enabling one does not change the other: people signing in use SSO, while a machine-to-machine integration obtains a bearer token with OAuth 2.0 client credentials against POST /v1/auth. If you are building an integration, start at get access; the auth request and response schema live in the API reference.

Supported providers

Provider Notes
Azure AD (Microsoft Entra ID) The common choice across FE and training providers.
OpenID Connect Any OIDC-compliant provider, via its discovery document.

For every provider, the redirect (callback) URL you configure is:

https://auth.cognassist.com/login/callback

Register your application, gather the values below for your provider, then send them to us through get access, saying you want to set up single sign-on. We complete the connection and confirm when SSO is live for your organisation.

Azure AD (Microsoft Entra ID) values

Register an application in Azure AD, then send us three values: your Application (client) ID, a client secret, and your Azure AD domain.

  1. Register the application. Follow Microsoft's register an application guide. Set Supported account types to the option that fits you (usually Accounts in this organizational directory only) and set the Redirect URI to https://auth.cognassist.com/login/callback. Note the generated Application (client) ID from the app's Overview screen.
  2. Create a client secret. Follow Microsoft's add credentials steps and record the secret value.
  3. Send us the Application (client) ID, the secret, and your Azure AD domain.

If you configure an expiring secret, record its expiry date and send us a renewed value before it expires, or sign-in will break.

OpenID Connect values

For an OIDC provider we require two values:

Item Description
Issuer URL The URL of your provider's OpenID Connect discovery document.
Client ID Your client ID.

Configure your provider to allow the callback https://auth.cognassist.com/login/callback, then send us both values.

If you are already working with a Cognassist account manager or onboarding contact, they can arrange the SSO setup for you. There is no self-service configuration screen.