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 ID token only includes the minimum information required by the standard. More information, including the user’s name and email, can be gotten 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

Attribute groups

When adding OIDC-configuration, the openid scope and userid automatically gets added. Those are not visible in the user information tab for the service.

OpenID Connect also defines a few other standard attribute groups. Of these the userinfo-photo, userinfo-name and email are supported by Feide.

When you use the userinfo-name attribute group, the token get access to whichever of the userinfo-name attribute groups that have been enabled in the client configuration.

The application should include openid in the scope parameter of the authorization request. If you are using an OIDC library, this is probably already taken care of.

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 enabled for the client and 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).

facebook

Automatically send user to Facebook.

twitter

Automatically send user to Twitter.

linkedin

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. As part of the OpenID Connect standard the ID token is encoded as a JWT, and signed using the JWS standard.

ID Token example:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvYXV0aC5kZ
XYuZmVpZGVjb25uZWN0Lm5vIiwiYXVkIjoiNWFjODc1M2YtODI5Ni00MWJmLWI5ODUtNTl
kODk3NjkwMDVlIiwic3ViIjoiNzZhN2EwNjEtM2M1NS00MzBkLThlZTAtNmY4MmVjNDI1M
DFmIiwiaWF0IjoxNDQ5MDY1NDMyLCJleHAiOjE0NDkwNjkwMzIsImF1dGhfdGltZSI6MTQ
0OTA2NTM2NH0.bObvZ\_Ampf\_exj4iUcocptJwHKt\_zZI4GnZ-VrXoqYlXaGGgwACzCz
hSpck\_z1C87gZYlOdK-TQwILHcGyObmi1rH5VCvrYL1xNyGeHYlYs8bQ8odhZAPiYjb9c
et5nP1aP4ZeJu5aInWwLIaeVUgavQEVAl1xGiPRh8WjKZdP-P1WslLACnVZu84YLrOZQYn
kGMpDS\_VBGHVSK3VPVjRd14vhqYCoGTaKSXrp49LlejU0dzaokmGI\_ZAejwVY1BCFMon
EyDNwZVZKoq2GbHwqpjhucWOZRQjYzeWTEXlly18EwYg55k6awNPZt8fKp0XoRoTB4we5W
GoFV6XZuaGA

ID Token JWT decoded

{
    "iss": "auth.dataporten.no",
    "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.

iss

Issuer

aud

Audience - the client ID

sub

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

iat

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

exp

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

auth_time

Time when the end-user authentication occurred

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 auth.dataporten.no and aud has to match the client id. See the OIDC standard for full details about ID Token Validation.

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