OpenID Connect and authentication

The OIDC userinfo endpoint provides basic information about the end user.

What information the endpoint returns about the user depends on which scopes the application has.

The userinfo endpoint is: https://auth.dataporten.no/openid/userinfo

Here is an example request:

GET /openid/userinfo HTTP/1.1
Host: auth.dataporten.no
Authorization: Bearer 083a7ef0-ea97-49ec-8804-379dc1e9b54c
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{
    "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f",
    "dataporten-userid_sec": [
        "feide:andreas@uninett.no"
    ],
    "name": "Andreas \u00c5kre Solberg",
    "email": "andreas.solberg@uninett.no",
    "email_verified": true,
    "picture": "https://api.dataporten.no/userinfo/v1/user/media/p:a3019954-902f-45a3-b4ee-bca7b48ab507"
}

sub is the userid for Feide over OIDC/OAuth - a UUID.

With only the profile and userid scopes, the accessible user properties become:

{
    "sub": "76a7a061-3c55-430d-8ee0-6f82ec42501f",
    "name": "Andreas \u00c5kre Solberg",
}

User Profile photo

Userinfo may include a picture attribute, which is a URL. If given, the application may fetch a profile photo from it. The photo is often square, and 128 x 128px. If not square, the longest edge will be 128px, and the aspect ratio will be unchanged from the original.

Extended userinfo from Feide directories

A separate userinfo endpoint is available for extracting more details directly from the user’s Feide directory. This is only available for Feide users. You will need to contact Uninett support@feide.no to request access to some special scopes to extract information from this endpoint.

The data structure at this endpoint is very similar to the attribute set returned from Feide in the SAML 2.0 Response.

API endpoint:

https://api.dataporten.no/userinfo/v1/userinfo

Example output from one of the test users:

{
    "eduPersonPrincipalName": "asbjorn_elevg@spusers.feide.no",
    "eduPersonEntitlement": [
        "urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn2",
        "urn:mace:feide.no:go:group:b::NO856326499:10A:2016-01-01:2019-06-20:student:Klasse%2010A",
        "urn:mace:feide.no:go:group:u:MAT0010:NO856326499:XMAS-10A:2016-01-01:2019-06-20:student:Matematikk%2010.%20%C3%A5rstrinn",
        "urn:mace:feide.no:go:group:u:ENG0012:NO856326499:XENS-10A:2016-01-01:2019-06-20:student:Engelsk%2010.%20%C3%A5rstrinn%20skriftlig",
        "urn:mace:feide.no:go:group:u:NAT0010:NO856326499:XNA-10A:2016-01-01:2019-06-20:student:Naturfag%2010.%20%C3%A5rstrinn",
        "urn:mace:feide.no:go:group:u:SAF0010:NO856326499:XSA-10A:2016-01-01:2019-06-20:student:Samfunnsfag%2010.%20%C3%A5rstrinn",
        "urn:mace:feide.no:go:groupid:b:NO856326499:10A:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:groupid:u:NO856326499:XMAS-10A:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:groupid:u:NO856326499:XENS-10A:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:groupid:u:NO856326499:XNA-10A:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:groupid:u:NO856326499:XSA-10A:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:groupid:a:NO856326499:10A-LAB1:2016-01-01:2019-06-20",
        "urn:mace:feide.no:go:group:a::NO856326499:10A-LAB1:2016-01-01:2019-06-20:student:Laboratoriegruppe%201"
    \],
    "norEduPersonNIN": "23080374554",
    "eduPersonAffiliation": \[
        "student",
        "member"
    \],
    "eduPersonPrimaryAffiliation": "student",
    "displayName": "Asbjørn ElevG Hansen"
}

Security considerations

The community now has long experience with OIDC and OAuth 2.0 in practice, and recommendations have evolved. One important change concerns the implicit flow. It was always considered less secure than the others, but back when the standards were defined, it was the least bad solution for native apps and single page web applications. Best current practice is not to use implicit flow at all, but to use authorization code flow instead. Clients which are unable to keep secrets, i.e. native and single page apps, must combine it with PKCE. The only case where implicit mode is appropriate is if you have to support very old browsers which do not support cross origin resource sharing (CORS).

Use TLS, and validate the certificates on all endpoints.

To limit the consequences of security breaches, only request scopes that you actually need.

The longterm scope lasts two years, and should not be used if the information protected is sensitive or valuable.

If you find the default access token duration of 8 hours too long, you can set the OIDC prompt parameter to login and make the user log in again.

Prefer OIDC over OAuth2 with the legacy Feide userinfo endpoint. Validate the ID token:

  • iss (issuer) must be https://auth.dataporten.no
  • aud (audience) must be your application
  • exp (expiry) must be sufficiently far in the future
  • iat (issued at) and auth_time must be in the past, but probably not too far in the past
  • The signature must validate

If you have to use the legacy userinfo endpoint, make sure you validate audience.

Protect against cross site request forgery (CSRF) attacks with PKCE or the state parameter to the authentication request.

Use the native system browser for mobile applications. Avoid embedded web views.

To protect from theft, store tokens in transient memory if possible.

Do not share tokens with third parties. Use the application gatekeeper instead.

Do not store client credentials in code or bundled resources.

If an app has to authenticate to more than one OIDC/OAuth provider, e.g. a Feide app that consumes a cloud resource elsewhere, you should use different redirect urls for each provider. Otherwise, one provider may impersonate another.

This section has only skimmed the surface. The best in-depth coverage is currently OAuth 2.0 Security Best Current Practice - an IETF draft. There are also Best Current Practice documents specifically for native applications and for single page applications. There is an IETF RFC OAuth2.0 Threat Model and Security Considerations, and the OIDC standard has a chapter about Security Considerations. However, both are old and must be read in the light of the documents above.

Logout

If your application uses OpenID Connect, you can use the logout mechanism described in OpenID Connect logout. It lets you control which page the user is redirected to after logging out.

In the application, include a logout link that performs the following:

  • First, kills the local session for the current user.
  • Then, redirects the user to the end session endpoint.

The user will then automatically be logged out from the Feide core platform, as well as the authentication source Feide, ID-porten or similar, and the end user will be shown a page telling the user he/she is now successfully logged out.

Notice that the end user will not be automatically logged out from other Feide applications.

For OpenID Connect applications, the end session endpoint is https://auth.dataporten.no/openid/endsession. For legacy applications, it is https://auth.dataporten.no/logout.

Test users

Contact support@feide.no to get test users’ username and password to test your application.

OpenID Connect details

OpenID Connect details