Why is the IdentityTokenLifetime default to 300 sec?

Question

Maybe I should ask what the intended use of the Identity token is. I thought it is used to identify the user and it can be passed to other services (e.g. backend services) and the that services use the id_token to validate it is a valid user? But I don't see any current available endpoint to validate the id_token. If not, what should be passed from one service to another service to validate the user?

The only end point that takes the id_token parameter is the End Session Endpoint where it is passed as the id_token_hint. But in that case, why is the IdentityTokenLifetime default to 300 sec only? I don't expect the user end the session in 300 sec.

Answer 1

The identity token is a one-time only token.

It contains the identity of the user and authentication metadata. Once the token is validated, it could (in theory) be deleted. Just pick out the claims you are interested in.

The is a situation where you want to keep the identity token around for special features during sign-out.

The identity token is never passed around. That's what the access token is for.

Answer 2

According to the OpenID Connect specification, authentication is built upon ID Token,

The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure

Once you receive the ID Token, you can authenticate the end user you are dealing with. ID token can be short lived (as you have seen). In that case you are supposed to use access token for other communication purposes.

Now to expand this answer, I like to mention about user info endpoint, token introspection and refresh tokens.

User info endpoint

OpenID Connect specification define an en endpoint named userinfo.

The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User.

One can use a valid access token to exchange authenticated user information. These information can be used by endpoints who rely on access tokens to authenticate and validate an end user.

Identity server reference - LINK

Token introspection

RFC7662 define a way to check the validity of an access token. It simply expect the access token as a bearer token and provide the validity information of the token.

Token refresh

This is the most interesting part. One can use above two mentioned endpoints to validate access tokens and end user who are bound to the access token. But as you have mentioned id tokens and access tokens expires. But A refresh token COULD be non expiring. Google uses non expiring refresh tokens (But it does not necessarily say you have to do that since Google do so.!). And one can refresh access token and id token using refresh token. Yes, the OIDC spec. does not mention about an id token for a refresh request. But identity provider can send an updated id token (Or it could be a configuration). MS Azure AD use this approach.

Now as you can see, there are lot going around the token validation. Your final solution can be a combination of available options through OIDC spec.

As the final thought, long lived tokens could posses security threats. Specially if your client type is public. Be mindful about configuring token life time to larger values and instead of doing that, try to get use of other available features of specification.