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 attribute groups are authorized for the application.

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"
    ],
    "https://n.feide.no/claims/userid_sec": [
        "feide:andreas@uninett.no"
    ],
    "https://n.feide.no/claims/eduPersonPrincipalName": "andreas@uninett.no",
    "name": "Andreas \u00c5kre Solberg",
    "email": "andreas.solberg@uninett.no",
    "email_verified": false,
    "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.

If the token only has the profile and userid scopes, and the userinfo-name attribute group is authorized for the service, the accessible user properties become:

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

User Profile photo

Userinfo-photo may include a jpegPhoto 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

Some attributes can be enabled using self service at the customer portal. See the list of attributes groups and attributes for details. For other attributes, you will need to contact Sikt at kontakt@sikt.no to request access.

The data structure at this endpoint is the same 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 attribute groups 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 JWT token exchange 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

See testing the integration for how to get test user and how to enable login with test user to test your application.

OpenID Connect details

OpenID Connect details