What is the purpose of expiring an ID in OpenID Connect?

Question

In OpenID Connect, the access token has an expiration time. For an authorization code stream, this is usually short (for example, 20 minutes), after which you use an update token to request a new access token.

The ID also has an expiration time. My question is, what is the purpose of this?

The ID token expiration time is shorter than the renewal token expiration time, which means that you will eventually have a token with an expired identifier, but a valid access token.

So you should:

• give your identifier token a validity period longer than the expiration of the update token, or
• set it for the same period as the access token, and take some action (what?) when it expires, or
• just consumes the identifier token in your client upon receipt, and then ignores the expiration time after that?

The OpenID Connect specification says that when checking for an ID token

"The current time MUST be before the time represented by the exp Claim." 

which (possibly) supports the third option above.

---

EDIT

Since OpenID Connect is based on OAuth2, the answer to an additional question can be found in the specification below.

But what does "expires_in" mean in this case? Access token, update token, or identifier token?

(For information, sets this at the time the access token expires).

Answer 1

I answer my question because I found that some of the assumptions behind my question were incorrect, so it’s easier to clarify, rather than rewrite the question.

The identifier token is intended to verify to the client that the user is authenticated and who he is as a result.

When a client receives an identifier token, it usually does something like converting it to ClaimsIdentity and saves it, for example, using a cookie.

The ID must have expired at this point of use (as it should be, since it has just been released). But after that, it is no longer used, so it doesn’t matter if it expires while the user still has an active session. The client has the required authentication information and, in turn, can choose its own policy regarding how long the session lasts before the user logs back in.

My wrong assumption, when asked a question, was that the identifier token and access token should be used together, and therefore both should have valid expiration dates. This is not true for various reasons:

• IDs are intended only for authentication to the Client (as described above).
• Access to tokens has nothing to do with Clients. They are designed to access resources, and the client processes them only if, in turn, it is necessary to call the resource.
• Something like a standalone MVC application or WebForms only requires an ID token. If it does not call an external resource, access to it is impossible, therefore there is no access token.

Answer 2

I had to delve into it for my own reasons and write, so I will post what I learned here ...

Firstly, I will answer the question at the risk of stating the obvious: the ID token cannot be trusted, and its contents should be ignored if the current time is longer than the elapsed time. The response to the questionnaire indicates that after the initial user authentication, the ID is not used again. However, since the ID is signed by the identity provider, it can certainly be useful at any time to enable you to reliably determine who is the user of other services that the application can use. Using a simple user ID or email address is not reliable because it can be easily faked (anyone can send an email address or user ID), but since the OIDC token is signed by the authorization server (which also usually has the advantage of being a third party), it does not can be tampered with and is a much more reliable authentication mechanism.

For example, a mobile application may want to indicate the server service that the user is using, and this may be required after a short period after the initial authentication, after which the ID has expired, and therefore cannot be used to authenticate the user.

Thus, just like the access token (used for authorization - specify what permissions the user has), can be updated, can the identifier token be updated (used for authentication - indicate who the user is)? According to the OIDC specification, the answer is not obvious. OIDC / OAuth has three “streams” for receiving tokens, an authorization code stream, an implicit stream, and a hybrid stream (which I will skip below because this is a variant of the other two).

For an implicit flow in OIDC / OAuth, you request an identifier token at the authorization endpoint, redirecting the user in the browser to the authorization endpoint and including id_token as the value of the response_type request parameter. Response to the implicit stream of successful authentication id_token include id_token .

For the authentication code stream, the client indicates code as the value of the response_type request parameter when redirecting the user to the authorization endpoint. A successful response includes an authorization code. The client client makes a request to the token endpoint with an authorization code and, according to OIDC Core Section 3.1.3.3 Successfully responding to the token , the response MUST include the identifier token.

So, for any thread, how do you get the identifier token first, but how to update it? OIDC Section 12: Using update tokens contains the following expression about the response to the update token:

After successfully checking the update token, the response body is the token response in section 3.1.3.3, except that it may not contain id_token .

It may not contain an identifier token, and since there is no indication to force it to include an identifier token, you should assume that the response will not contain an identifier token. Thus, technically there is no specific way to “update” an identifier token using an update token. Thus, the only way to obtain a new identifier token is to reauthorize / authenticate the user by redirecting the user to the authorization endpoint and starting the implicit stream or authentication code stream, as described above. The OIDC specification adds a prompt request parameter to the authorization request so that the client can request that the authorization server does not request any user interface from the user, but the redirection should still occur.

Answer 3

This is the same intention: you cannot use id_token after its expiration. The main difference is that id_token is a data structure, and you will not need to call any servers or endpoints, since the information is encoded by the token itself. A regular access_token usually an opaque artifact (e.g. GUID).

The id_token user must always verify its authenticity.

I am not 100% familiar with IS, but I would suggest that this field is for convenience. You should always check exp .

Expiration is only one of the validations. id_token also has a digital signature, and it is also a check that you must perform.

Answer 4

I wanted to post this answer as a comment, but since I was not very active on StackOverflow, I assume I am posting it as an alternative answer.

You also use id_token as id_token_hint when trying to log in a user from the http://openid.net/specs/openid-connect-session-1_0.html session. I honestly don’t think it really matters if id_token expired, since you only worry about id_token specific user.

Answer 5

Updating the token means that you can use it again to request something from the authorization server (in this case, OP is the OpenID-Connect provider) EVEN WHEN THE USER IS NOT ALLOWED. Usually you only allow this for limited resources and only after the user has logged in and authenticated at least once. Light tokens themselves should also be limited in time.

In an OIDC implicit stream, you invoke the authorization endpoint,
and get the ID in the response along with all areas and in them all the data claims.
Subsequent API calls must be made using a code stream .
Implicit stream is intended for use only for javascript or only for browser. Not an application that interacts with a server.
Therefore, even if there was a way to “update” this token, you should not - a reasonable defense - let it live for too long. It will be stolen and reused by unauthorized users personifying the identifier. You must force a new login for this.

In the code stream, you call the OP authorization endpoint and get an authorization code (also called an authorization token or short authorization code). This should expire similarly to the id_token that you received in the implicit stream, for the same reasons it cannot and should not be renewed.

The user interface or application then calls the OP Token endpoint and receives it (sometimes after the user consents through the user interface to allow the use of their resources on the OP server):

• The id_token identifier for authentication - which should never be reused in server calls, except as a hint at the time of logout, when its validity is no longer important, and therefore, for the reasons mentioned above, it should be allowed to expire and never be updated.
• Access_token - which later in the API call can be provided to the UserInfo OP endpoint. This will return the claim, and the API may resolve accordingly.

You can update this access_token since it only tells the API what the user is claiming and what resources (by area and each claim area) the user has agreed to give you. As explained above, this allows access even after the user is no longer logged in. Of course, you never want id_token to be updated because you do not want to allow impersonation without logging in.

Answer 6

If I understood correctly, according to this and the OpenID Connect Core 1.0 spec , the identifier token itself can be stored in cookies as a mechanism for saving sessions and sent with each authentication request for the Client. The client can then verify the identifier token either locally or through the endpoint of the provider verifier (if provided as Google ). If the token has expired, it must make another auth request, except for this time with prompt=none in the URL parameter. Also, do not forget to send the token with the expired ID in the id_token_hint parameter, otherwise the provider may return an error.

So, for the Token ID it seems natural, but prompt=none ensures that the new identifier token can be obtained smoothly without user intervention (unless, of course, the user has left this OpenID).

Answer 7

TL; DR;

Check the identifier token before trusting its words.

More details

What is the purpose of expiring an ID token in OpenID Connect?

The goal is to allow the client to verify the identifier token, and the client must verify the ID token before operations that use the ID token information .

From the specification of the implicit OpenID stream :

If any of the verification procedures defined in this document fails, any operations that require incorrect validation MUST be interrupted, and information that has not been verified MUST NOT be used.

To confirm this, the Google OpenID Connect Documentation talks about ID Token Identification:

One thing that makes ID badges useful is the fact that you can pass them around the different components of your application. These components can use the ID token as a lightweight authentication mechanism that authenticates the application and the user. But before you can use the information in the ID token or rely on it as a confirmation of user authentication, you must confirm it.

So, if our client application takes some action based on the contents of the ID token, we must check the ID token again.