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 avilable 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:


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.


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:


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


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


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.


Automatically send user to ID-porten.


Automatically send user to eIDAS (European authentication framework).


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


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


Automatically send user to Facebook.


Automatically send user to Twitter.


Automatically send user to LinkedIn.

JWT Signing key

The signing key may be obtained here:

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.

The information included - the claims - depends on the scopes / attribute groups enabled for the application. Claims are namespaced, so that claims which are specific to Feide are prefixed with Claims without this prefix are specified in the OIDC standard or in RFC 7519 - JSON Web Token (JWT).

ID Token example:


Here is a decoded example of a minimal ID token:

    "iss": "",
    "aud": "5ac8753f-8296-41bf-b985-59d89769005e",
    "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f",
    "iat": 1449065432,
    "exp": 1449069032,
    "auth_time": 1449065364

The example above shows what the ID token includes when only the openid scope is enabled. All times are in seconds since 1970-01-01 00:00:00 UTC.




Audience - the client ID


Subject - The internal ID of the authenticated user. This ID is stable but opaque, not releasing any additional information about the user.


Issued at - Time issued (in seconds since 1970-01-01T0:0:0 UTC)


Expiration time (in seconds since 1970-01-01T0:0:0 UTC)


Time when the end-user authentication occurred

Here is an example of a decoded ID token which includes all supported claims:

    "iss": "",
    "jti": "f95ed523-b9b2-42e7-b193-a08143d9f342",
    "aud": "5ac8753f-8296-41bf-b985-59d89769005e",
    "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f",
    "iat": 1635509702,
    "exp": 1635513302,
    "auth_time": 1635505713,
    "nonce": "PLt3i3bT2~xTw7m",
    "email": "",
    "name": "Jon Kåre Hellan",
    "picture": "",
    "": [
    "": "",
    "at_hash": "DiafctHGah2reptMDjEqUg"

The user’s email. Requires the email attribute group


The user’s name. Requires the userinfo-name attribute group


A picture of the user. Requires the userinfo-photo attribute group

An array of secondary user IDs, with a prefix to indicate the source.

If the application has the userid-feide attribute group, and the user logged in with Feide, it will contain feide: followed by the eduPersonPrincipalName of the user. Example:

If the application has the userid-nin attribute group, and the user logged in with ID-porten, it will contain nin: followed by the national identity number of the user. Example: nin:10108012345

The user’s eduPersonPrincipalName. Requires the userid-feide attribute group. Only available if the user logged in with Feide.

The user’s national identity number. Requires the userid-nin attribute group. Only available if the user logged in with ID-porten.

The attributes acr, at_hash, c_hash and nonce may also be present. See the OIDC standard for info about these.

The client must validate the ID token. In particular, iss has to be and aud 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 is useful.