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",
}
Read in OpenID Connect details about the relationship between SAML attributes and OpenID Connect claims and scopes.
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 behttps://auth.dataporten.no
aud
(audience) must be your applicationexp
(expiry) must be sufficiently far in the futureiat
(issued at) andauth_time
must be in the past, but probably not too far in the pastThe 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.