What is intent of ID Token expiry time in OpenID Connect?

Question

In OpenID Connect an access token has an expiry time. For authorization code flow, this is typically short (eg 20 minutes) after which you use the refresh token to request a new access token.

The ID token also has an expiry time. My question is what is the intent of this?

Any ID token expiry time less than the expiry time of the refresh token will mean you will eventually have an expired ID token, but a valid access token.

So are you meant to:

• give your ID token an expiry longer than the refresh token expiry, or
• set it to the same expiry as the access token and take some action (what?) when it expires, or
• just consume the ID token in your client on receipt, then ignore the expiry time after that?

The OpenID Connect specification just says that when validating an ID token,

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

which (possibly) supports the third option above.

---

EDIT

As OpenID Connect builds on OAuth2 the answer to the supplementary question below can be found in the OAuth2 specification which says,

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

---

A related question is when you exchange an authorization code for the tokens, the same specification says you might get a response such as:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

But what does "expires_in" relate to in this case? The access token, the refresh token or the ID token?

(For information, IdentityServer3 sets this to the access token expiry time).

Answer 1

I'm answering my own question as have discovered that some of the assumptions behind my question were wrong, so easier to clarify here, rather than re-write the question.

An ID token is meant for proving to a Client that the user has authenticated, and who they are as a result.

When a Client receives an ID token, it will generally do something like convert it to a ClaimsIdentity, and persist this, eg using a cookie.

The ID token has to be un-expired at this point of use (which it should be, since it has just been issued). But after this it is not used again, so it does not matter if it expires while the user still has an active session. The Client has the authentication information it needs, and in turn can choose its own policy for how long the session lasts before the user has to log in again.

My wrong assumption when asking the question was that an ID token and access token should be used together, and therefore both needed to have valid expiry dates. This is wrong for various reasons:

• ID tokens are only for authenticating to a Client (as described above).
• Access tokens have nothing to do with Clients. They are for access to resources and a Client only handles them if it in turn needs to call an resource.
• Something like a standalone MVC or WebForms application only needs an ID token. If it isn't calling an external resource, there is nothing to grant access to, so no access token.