OpenID Connect details#

OpenID Connect (OIDC) is a simple standardized identity (authentication) layer on top of OAuth 2.0.

After a successful login, the user agent is in possession of an access token and an ID token. The access token looks the same as for plain OAuth2. The ID token is a signed JSON Web Token with info about the user. The information is also available from the userinfo endpoint described in the reference doc:

Userinfo Endpoint.

Discovery and configuration#

All you need to know in order to configure your OpenID Connect client to the Feide platform is available through the discovery endpoint:

https://auth.dataporten.no/.well-known/openid-configuration

Client registration#

In order to access the Feide APIs, you need to register your application, and obtain the OIDC/OAuth credentials for your application.

The customer portal allows Feide administrators to register and manage applications.

When registering a client, you need to know the redirect URI endpoint of your application. This is under the configuration tab when editing the service.

Screenshot of adding Redirect URI to a configuration

Scopes, claims and attribute groups#

In the Feide customer portal, administrators allow or deny access to information in attribute groups. These mean the same for SAML and OpenID Connect.

Developers of OpenID Connect applications will encounter two additional concepts:

scopes: Access tokens carry scopes which determine which information can be retrieved. The concept is defined in the OAuth2 standard. The OpenID Connect standard defines some standardized scopes.
claims: Each piece of information in ID token and OpenID Connect userinfo is a claim. Some claims are specified in the OpenID Connect standard. Others are specific to Feide and defined by us.

The authorization request takes a scope parameter. It can be used to request what information the access token should grant access to. However, the openid scope is special. Instead of requesting access to information, it is used to tell OpenID Connect apart from other variants of OAuth2. The application should include openid in the request. If you are using an OIDC library, this is probably already taken care of.

When adding an OpenID Connect configuration in the customer portal, the scopes openid and userid are automatically authorized.. Those are not visible in the user information tab for the service.

Typically, the authorization request will only mention the openid scope. The resulting access token will be authorized for all attribute groups that are configured for the service.

If a more restrictive access token is wanted, the desired scopes can be requested explicitly. Names of attribute groups can be used as scopes in Feide. In addition, some scopes are defined in the standard. According to the standard, profile requests name and photo. Which of these, if any, are returned depends on which of the attribute groups userinfo-name and userinfo-photo are authorized in the customer portal. The standardized scope name works if userinfo-name is authorized, and picture needs userinfo-photo.

OpenID Specifications#

Supported features#

Authorization Code flow response_mode: code
Implicit grant flow response_mode: id_token token
Hybrid flow response_mode: code id_token
ID token signed with PKI (RS256)
Proof Key for Code Exchange (PKCE) may be used with authorization code flow and hybrid flow. code_challenge_method: S256

Implicit grant flow response_mode: id_token token is also still supported. But due to weak security, it should be avoided for new clients. Existing clients should migrate to authorization code flow with PKCE.

Dynamic registration is not supported.

Requiring a specific authentication level#

The application can request a specific authentication level via the optional acr_values parameter. For more details refer to this page.

An organization can also request a specific authentication level for some or all users, see the multifactor authentication deployment guide.

Login hints - bypassing the login discovery page#

The default behaviour when a client sends the end user to Feide for authentication is that the user first meets either the account chooser or the ID-provider discovery page.

Sometimes the client may want to let the user bypass the discovery page / accountchooser and go to a specific ID provider. This is possible by using the OpenID login_hint parameter to the authorization endpoint.

The following prerequisites needs to be met to use this functionality:

The client owner needs to configure the client to not require user interaction. This can be done using the customer portal on the OIDC-configuration when editing the service. Uncheck the checkbox «Always require user interaction».

Screenshot of require user interaction

Consider the security implications of allowing Single Sign-on to automatically login users to your site without user interaction.
Make sure that the openid scope is included in the authentication request. If not, the request is interpreted as a plain OAuth request, and then the login hint functionality is not supported

The login_hint parameter is sent as part of the authentication request to Feide as a query string parameter. The parameter may have one of these values:

feide|all

Automatically send user to Feide login page with no specific organization preselected. Feide will remember if the user has selected an organization previously.

feide|realm|uninett.no

Automatically send user to Feide login page with the specific organization Uninett. Uninett will then be preselected in the Feide login page.

feide|realm|uninett.no|andreas@uninett.no

Automatically send user to Feide login page with the specific organization Uninett. Uninett will then be preselected in the Feide login page. Also specify which user we expect to login. If user tries to login with another account the user will get an warning that the user was not expected, but the userID is not enforced beyond that.

idporten

Automatically send user to ID-porten.

eidas

Automatically send user to eIDAS (European authentication framework).

edugain|urn:mace:entity

Automatically send user to the Identity Provider with entity ID urn:mace:entity via eduGAIN.

openidp

Automatically send user to Feide’s OpenIdP (guest accounts).

ID Token#

The ID token is a signed information object representing the authenticated identity of the user. It is specified in the OpenID Connect standard. The ID token is encoded as a JWT, and signed using the JWS standard.

For details on Feide ID tokens see the reference docs.

The client must validate the ID token. In particular, the iss claim has to be https://auth.dataporten.no and the aud claim has to match the client id. See the section about ID token validation in the OIDC standard for full details.

To see what is inside an ID token, the online JWT debugger at https://jwt.io is useful.