Skip to content

Frequently Asked Questions

Are the new tokens backwards compatible?

The new token schemas provided for OIDC and SAML applications are not fully backwards compatible.

Significant changes:

  • Only necessary data is included, other personal information can be queried from the Authorization Service API if required by your application
  • The full list of e-groups has been removed. This is replaced by the concept of Roles, which you define for your application and map to e-groups plus requirements on identity assurance and multifactor.
Attribute Legacy SAML Field Example Value Migration Note
User identifier (duplicate of email) upn The value in this attribute is not backwards compatible. UPN previously contained the email which was misleading and insecure as it could be modified. The new UPN claim is a permanent, unique, non-reassigned ID. For CERN users it represents the CERN Login name, for federated users it is a unique identifier scoped to the identity provider, e.g. 12387234@google or
User identifier (duplicate of email) UPN As above
Email EmailAddress Maintained
Display Name DisplayName Marie Curie Maintained
First Name Firstname Marie Maintained
Last Name Lastname Curie Maintained
CERN Person ID PersonID 755555 Maintained
CERN Unix ID uidNumber 55555 Maintained
CERN Unix GID gidNumber 5555 Maintained
Preferred Language PreferredLanguage FR Maintained
Groups Group [list of e-groups] Replaced by Roles, mapped to e-groups, level of assurance and single/multi factor criteria
CERN Identity Class IdentityClass CERN Registered As above
Authentication level (Normal or Multifactor ) AuthLevel Normal As above
Phone Number PhoneNumber +41227655555 Discontinued, available from the Authorization Service
Mobile Number MobileNumber +41754115555 Discontinued, available from the Authorization Service
Building Building 11 1-111 Discontinued, available from the Authorization Service
CERN Department Department IT/MIA Discontinued, available from the Authorization Service
Home Institute HomeInstitute CERN Discontinued, available from the Authorization Service
Common Name CommonName mcurie Discontinued (For CERN people, this matches the UPN)
Account source Federation CERN Discontinued
CERN Role role CERN Users Discontinued

Why is my SAML application not working with the new SSO?

First, make sure you follow the SAML Application checklist. If it is still not working and you are getting the message "Invalid Client" from SSO, you may need to ensure that your Metadata includes <md:KeyDescriptor use=”signing”> - your signed authentication requests will only be validated if SSO knows which key to use to check the signature.

How can I look up groups for a user?

You will no longer receive all e-groups in your SSO tokens. Instead, you must define roles for your application that are linked to groups. This change has been implemented to protect the privacy of users' personal data. If you have a genuine reason to query all the groups for a user, you can request permission to use the Authorization Service API with an OIDC Application.

How do I redirect my application to the 2FA login page?

If you intend to bypass the default CERN login page, and redirect users directly to the Two-factor authentication page, you need to add the kc_idp_hint=mfa query parameter in your Keycloak login URL.

You can use the Keycloak JavaScript library to make this easier:

let kcLogin = keycloak.login;
keycloak.login = (options) => {
  options.idpHint = 'mfa';

This will generate a URL similar to:

How can an insecure frontend and secure backend work together with OAuth?

A common use case is having an insecure (e.g. single page web app) frontend sending authenticated requests to a secure backend protected by OAuth. There are two main ways to do this:


Token exchange (Purple, dashed lines)

  1. User authenticated on the frontend via an OAuth public client
  2. Token is exchanged for a token made for the backend (i.e. audience set to the backend client)
  3. Token is sent to the backend

Multiple Audiences accepted by backend (Orange, solid lines)

  1. User authenticated on the frontend via an OAuth public client
  2. Same token sent to the secure backend, which accepts token audience equal to the frontend client as well as its own

We provide the following libraries and examples which might be of use: