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:

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.

Services that are registered in the customer portal are synchronized to the dashboard dataporten so you don’t need to register a new service in dataporten dashboard to register or get access to API.

If you are registered as an administrator in the Feide customer portal, you will be able to login to the dataporten dashboard with the same credentials. For users without a Feide account, choose Feide Guest users when login into dataporten dashboard.

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

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

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.