OIDC Best Practices

Proof of Key Code Exchange - PKCE

PKCE stands for “Proof of Key Code Exchange” and is pronounced “pixy”. It is an extension of the OAuth 2.0 protocol that helps prevent code interception attacks. OAuth 2.0 allows users to share their data securely between different applications, and PKCE provides an additional security layer on top of it.

The edu-Id OpenID Provider (OP) is configured as follows.

  • PKCE is mandatory for public clients. Authorization requests without PKCE are discarded.
  • PKCE is voluntary for confidential clients. However, today's best practice recommends using PKCE for confidential clients as well.
References:

Claims in UserInfo vs ID Token

Information from the edu-ID OP about an authenticated user can be obtained in two ways in OIDC: via UserInfo endpoint or via ID Token. Both of them have advantages and disadvantages over each other. In the Resource Registry, RP operators can configure which claims are received which way. Please consider the following points before configuring your RP.

Flow of user authentication

After user authentication, the RP receives an authorization code. With this code, it can make a request to the token endpoint of the OP in order to receive an Access Token and an ID Token. In the standard case, an access token can be used to send a request to the UserInfo endpoint in order to receive up-to-date claims about the user.

Method comparison

The table below shows different aspects when it comes to receiving user information via ID Token and UserInfo endpoint.

  Claims via UserInfo endpoint Claims in ID Token
Specification Standard OIDC endpoint for user general claims. Corresponding scopes need to be included in the request (profile, email, etc.) All claims but the subject are optional. The ID Token is primarily used for the authentication context (who has been authenticated and when/how)
Access Requires an additional request to the userinfo endpoint after the token request using the Access Token RP gets ID Token in the token request using the authorization code and client authentication
Freshness Up-to-date claims at time of request, can be refreshed with valid Access Token Claim values computed once at time of user authentication
Size limitations No size constraints (response is JSON over HTTPS) No size limitation for the flows which the Switch edu-ID OP supports (authorization code and refresh token). Other flows might have constraints
Use cases Get all required information, including sensitive attributes Minimal, non-sensitive claims needed immediately (e.g., sub, maybe email, information about the authentication like MFA)

The conclusion is that the ID Token is actually only meant to know who the authenticated user is and how/when they have authenticated. For more sensitive data, the UserInfo endpoint is preferable.

Configuration options

By default, if no attribute release rules are setup in the Resource Registry, the ID Token and the UserInfo endpoint both only release the pairwise/public subject (sub claim), the ID Token additionally contains information about the user authentication like whether MFA was used.

For any further claims, client operatorscan request those claims in the Resource Registry for both of the two methods. Note that the corresponding scopes need to be added to the authorize request and that not all users have values for each available claim.

We strongly recommend to fetch user information, especially if it is sensitive, via the UserInfo endpoint only. Generally, only data that is required should be requested.

References