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.