This post is about understanding tokens roles in OpenID Connect (OIDC) intégration:
OpenID Connect Specification is described at
OpenID Connect is provided on top of OAuth2 layer, defined in RFC 6749.
OpenID provides authentication which is expressed throughout an ID token. Aside ID token, an access token can be provided (depending of the type of the flow request used.)
OpenID connect provides 3 flows which are:
-Authorization Code flow
The description of the flows is provided at:
(https://openid.net/specs/openid-connect-core-1_0.html, section 3 provides a description of the different flows and token provided according to the request type)
2. Understanding ID Token role in OIDC
OpenID Connect issues an ID token and an Access Token (if requested in the OIDC request type).
An ID Token is used for authentication. The claims present in the OIDC token allows to assert/validate the identity of a user and its validity.
Duration of ID Token is represented by the claim « exp » (expired time, expressed in secs since 1/1/1970).
Issuance Authentication time is represented by the claim « iat » (issue authentication time, expressed in secs since 1/1/1970)
An easy way to compute it is by making the difference between « exp » and « iat » (issued token time), always expressed in seconds.
For example, Google has a validity time of 3600s, once a ID token has been issued.
3. Access Token role along ID Token in OIDC
Access Tokens are provided to grant or deny access to resources, based upon authorization server.
The scope/role of the Access Token is thus totally different from the role ID token which is used for authentication.
Some OIDC flows (Authorization Code and Hybrid) allow to cater for a refresh token.
4. Using a Refresh token in OIDC
The OpenID specification does not mandate to provide a new id token, upon a successful refresh response.
This point is left open in the spec:
12.2. Successful Refresh Response
Upon successful validation of the Refresh Token, the response body is the Token Response of Section 18.104.22.168 except that it might not contain an id_token.
Concretely, it means that upon a successful refresh response, there is always an access token, but a new ID Token delivery is not granted.
It means also that it is not be possible to perform user verification, as the existing ID Token has already expired. The new access token
generated allows to grant/deny access to the resources for the user.
Performing a refresh is typically used to allow to access limited resources (defined in the access scope) where authentication is not required.
Whenever a new ID Token is needed, the user has to re-authenticate.