The OIDC strategy now calls the strategy get_user/2 directly rather than the previous nested call. This means that any custom implementation of get_user/2 for a OIDC strategy must use the validate_id_token/2 method to conform to OIDC specs.
The default get_user/2 behavior is to use the claims in the ID token rather than, as previously, fetching from the userinfo endpoint. The two strategies using OIDC uses the claims already so this simplifies things. If a strategy needs to call the userinfo endpoint, fetch_userinfo/2 has been added that conforms with validation requirements from the OIDC specs.
The OIDC strategy now calls the strategy
get_user/2directly rather than the previous nested call. This means that any custom implementation ofget_user/2for a OIDC strategy must use thevalidate_id_token/2method to conform to OIDC specs.The default
get_user/2behavior is to use the claims in the ID token rather than, as previously, fetching from the userinfo endpoint. The two strategies using OIDC uses the claims already so this simplifies things. If a strategy needs to call the userinfo endpoint,fetch_userinfo/2has been added that conforms with validation requirements from the OIDC specs.