OpenID Connect claims in SURFconext

When you connect to SURFconext you can use OpenID Connect or SAML as a protocol to authenticate a user using SURFconext. Different standards result in different protocols and in their turn tend to use a jargon specific to that standard. It comes to no surprise this is the case with OpenID Connect and SAML. This page depicts how to translate the commonly used SAML attributes to OpenID Connect claims and vice versa.

OpenID Connect Claims and SAML attributes

Most services require extra information about the authenticated user, such as a name, email address or affiliation. In OpenID Connect (OIDC), this extra information comes in the form of claims, whereas in SAML, claims are called attributes. In SURFconext, the user authenticates at his Identity Provider (called OpenID Provider in OIDC) - this all happens using SAML. SURFconext translates the incoming SAML attributes to OIDC Claims and provides them at the userinfo endpoint for your Service Provider (called Relying Party in OIDC) to consume.

An extensive list of SAML attributes together with their details and properties can be found on our support page about attributes.  Those SAML attributes are provided by institutions connected to SURFconext as Identity Provider. You can use any of those attributes in your service (SURFconext translates them to OpenID Connect claims), however you must comply with our data minimisation policy, meaning you are only allowed to receive the bare minimum of attributes strictly needed for you to operate your service.

The following table describes the translation from OpenID Connect Claims to SAML attributes.