OIDC / OAuth 2.0 SSO - Prerequisites FAQ

Does the application support OAuth 2.0 / OpenID Connect?

Yes.

We connect as a confidential client using the Authorization Code flow, the standard and most secure OIDC pattern for server-side applications. Sign-in is completed server-to-server over TLS, and no tokens are exposed to the user's browser.

We support Microsoft Entra ID / Azure AD, Okta, Auth0, OneLogin, Salesforce and any provider that publishes standard OpenID Connect discovery. SAML 2.0 is also available if your team would prefer a SAML integration instead.

For Microsoft Entra ID there are two connection methods:

Option A - Standard OpenID Connect (recommended). We read the user's identity from the standard OIDC claims. This needs the three standard OIDC permissions only, and no Microsoft Graph resource permissions.
Option B - Microsoft-specific connection. We read the user's identity from the Microsoft user profile endpoint. This additionally requires the delegated User.Read permission.

We recommend Option A, as it requires the smaller permission set. Questions 3 and 4 below give the answers for each option.

What we need from you to build the connection:

Client ID
Client secret, and the date it expires
Your issuer / authority URL (or tenant ID for Microsoft Entra ID)
Confirmation of which claim or field carries the user's email address, if it is not the standard email claim

Does the application require Redirect URI(s)?

Yes - one Redirect URI, which we will provide to you.

We configure our side first and send you the exact URI to register. You do not need to construct it yourself.

Points for whoever registers the application on your side:

Register it as a Web platform redirect URI. Please do not register it as a Single-page application (SPA), as we are a confidential client and authenticate with a client secret.
The URI must match exactly - HTTPS, correct case, no trailing slash.
A front-channel logout / sign-out URL is not required.
The Redirect URI is specific to the provider type rather than to your individual connection. If you later add further connections that use the same provider, they share the same Redirect URI and no new registration entry is needed.

We will also supply the sign-in link for your users, which is what you place behind a portal tile, bookmark or launch button.

Which token types are required?

ID Token and Access Token, both collected during the standard code exchange.

ID Token: the primary source of user identity - unique identifier, email address and name.
Access Token: used to read the profile of the person who is signing in. Under Option A this is the standard OIDC UserInfo endpoint, and is only called when the email address is not already present in the ID Token. Under Option B the Microsoft user profile endpoint is read at each sign-in.

In both cases the access token is used only to read the profile of the person currently signing in. It is never used to browse your directory, read other users, or reach mail, files, calendars or any other resource.
Refresh Token: not required. We do not request offline_access .

Please note that Microsoft hosts its OIDC UserInfo endpoint on the graph.microsoft.com domain. If your team monitors outbound calls, requests to that domain may therefore appear under Option A as well as Option B. Under Option A the call requires only the openid permission and reads nothing beyond the signed-in user's own profile.

Please leave the "Implicit grant and hybrid flows" checkboxes unticked, both "ID tokens" and "Access tokens." We use the authorization code flow and receive both tokens directly from the token endpoint, so implicit issuance is unnecessary and should stay disabled.

Claims required in the token:

Unique user identifier (sub ): required.
Email address (email ): required. This is the key we use to create and match the learner record. If your provider supplies it under a different name, tell us and we will configure it. Under Option A, please make sure Entra is configured to release the email claim, as sign-in cannot complete without an email address.
Name (name , or given name and family name): recommended, used for the learner's display name.
Roles: optional, only if role-based enrolment is in scope (see question 5).
Groups: optional, only if group-based enrolment is in scope.

Credentials you supply are encrypted at rest. The client secret cannot be displayed or retrieved once saved; it can only be replaced with a new value.

Which Microsoft Graph or API permissions are required?

No Application permissions are required under either option. Every permission below is Delegated.

Option A - Standard OpenID Connect (recommended):

openid (Delegated): required by OpenID Connect, identifies the signed-in user.
email (Delegated): returns the email address used to create and match the learner record.
profile (Delegated): returns the user's name for their learner profile.

No Microsoft Graph resource permissions are required.

Option B - Microsoft-specific connection, adds:

User.Read (Delegated): allows the signed-in user's own basic profile to be read from the Microsoft user profile endpoint, which is where this option obtains their email address and display name.

User.Read is the minimum Microsoft Graph permission available for reading a signed-in user's own profile. It grants no access to other users and no directory-wide access.

Application permissions required: none.

We perform no background, unattended or app-only access to your tenant, and we do not read directory data. Every request is made on behalf of the user who is actively signing in, using that user's own delegated token. No business justification for Application permissions is required, because none are requested.

We also do not request offline_access , so we hold no long-lived access to your tenant. The token is used at sign-in and then discarded.

If your tenant requires admin consent for these delegated permissions, granting tenant-wide admin consent once at registration will avoid a consent prompt for every individual user.

If your provider requires an additional scope beyond those listed, please raise it with us early, as support varies by connection method and we will need to confirm whether it can be accommodated.

5. Does the application require App Roles?

No, not by default.

Course and group access is normally managed on our side, per connection or per enrolment link. This is the recommended setup and needs nothing from your identity provider beyond the permissions in question 4.

App Roles are optional. They are only relevant if you want your identity provider to determine which courses a user receives - for example, a user assigned the Compliance-Training role in Entra is automatically enrolled in the matching course.

If you would like that, please:

Define the App Roles and assign the relevant users or groups.
Confirm the roles are included as a claim in the ID Token.
Send us the role names and the claim name, so we can map them to the correct courses.

Please raise this with us as early as possible, and before go-live. Role-driven enrolment is not simply a matter of ticking a box at your end; depending on the connection method it may require configuration work on our side, and we will need time to set it up and test it with you. Group-based enrolment is available as an alternative to App Roles.