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

oauth-2.0 openid-connect

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).

Appetere

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.

Do you have any references for this? Eugenio claims you can refresh an id token in his answer. Is this true?

You can't refresh an ID token, in the sense of extending its expiry (in the way an access-token can be refreshed by using an offline-access token). But if you have an unexpired authentication session with the OpenID Connect Provider (eg a cookie after logging into IdentityServer3) then when you repeat a login request the Provider can skip the authentication (because the cookies says you've done it) and just return a new ID Token (& access-token if requested). This only works if the cookie has a longer lifetime than the ID Token, of course.

While you can do this, I am not sure as to whether it is correct to do so. It would also not be seamless to the end-user, since it would require a handful of browser redirects.

@Kir If you are using a Javascript single page app (SPA) then the first attempt at an acces-token renewal would typically be a background process, so the end-user wouldn't be interrupted. Eg if your resource's API responds that the access token has expired, then the SPA makes a background request to the Identity Server for a new access token. Only if this fails (because the ID token has expired) do you have to ask the user to login again. See the JavascriptImplicitClient sample at github.com/IdentityServer/IdentityServer3.Samples/tree/master/… for example code.

@Nth.gol When you request an Access Token from the IdP you specify the "scope" parameter. This can include scopes like "profile" and "email" that the IdP may support on a User Info endpoint, so yes, it can protect IdP resources, as you say. But you can also specify scopes for your resources (eg APIs), "api1, api2", so the same Access Token is also used for securing those resources.

VadymVL

I had to dig into this for my own reasons and wrote it up, so I'll post what I learned here...

First, I'll answer the question at the risk of stating the obvious: The ID token cannot be trusted and its content must be ignored if the current time is greater than the expired time. The questioner's answer states that the after the initial authentication of the user, the ID Token isn't used again. However, since the ID Token is signed by the identity provider, it certainly could be useful at any time to give a way of reliably determining who the user is to other services that an app might be using. Using a simple user ID or email address isn't reliable because it can be easily spoofed (anyone can send an email address or user ID), but since an OIDC ID Token is signed by the Authorization server (which also usually has the benefit of being a third party) it cannot be spoofed and is a much more reliable authentication mechanism.

For example, a mobile app may want to be able to tell a backend service who the user is that is using the app and it may need to do so after the brief period following the initial authentication, at which time the ID Token is expired, and thus, cannot be used to reliably authenticate the user.

Therefore, just like the access token (used for authorization - specifying what permissions the user has) can be refreshed, can you refresh the ID Token (used for authentication - specifying who the user is)? According to the OIDC specification, the answer isn't obvious. In OIDC/OAuth there are three "flows" for getting tokens, The Authorization Code flow, the Implicit flow, and the Hybrid flow (which I'll skip below because it's a variant of the other two).

For the implicit flow in OIDC/OAuth you request the ID Token at the authorization endpoint by redirecting the user in the browser to the Authorization endpoint and including id_token as the value of the response_type request parameter. An Implicit Flow Successful Authentication Response is REQUIRED to include the id_token.

For the Authentication Code flow, the client specifies 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 the authorization code and, according to OIDC Core Section 3.1.3.3 Successful Token Response the response MUST include an ID Token.

So for either flow, that's how you initially get the ID Token, but how do you refresh it? OIDC Section 12: Using Refresh Tokens has the following statement about the Refresh Token Response:

Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 except that it might not contain an id_token.

It might not contain an ID Token and since there is no way specified to force it to include the ID token, you must assume that the response will not contain the ID Token. So technically there is no specified way to "refresh" an ID Token using a refresh token. Therefore, the only way to get a new ID Token is to re-authorize/authenticate the user by redirecting the user to the authorization endpoint and starting the implicit flow or authentication code flow as described above. The OIDC specification does add a prompt request parameter to the authorization request so the client can request that the authorization server not prompt the user with any UI, but the the redirect still has to happen.

If you are writing a general software to work with arbitrary Authorization provider, you can’t rely on returning id_token from refresh. However if you are working with the particular provider(such as IdentityServer4), you can check it’s capability, and use id_token received after refresh request

So how can the id_token be refreshed?

@jwilleke AFAIK, as said above "the only way to get a new ID Token is to re-authorize/authenticate the user by redirecting the user to the authorization endpoint"

@MichaelFreidgeim Interesting, do you mean through the Open ID Connect Discovery mechanism? How exactly do we do that?

Good answer on the "response body of refresh might not contain an id_token". Upvoted. By the way, my understanding is the OIDC specs does leave a leeway for using Refresh Token to obtain a new ID token: the client can do so by specifying "id_token" as one of the scope; but general caution still applies here, because it is the Authentication Server to make the final decision on whether to honor your requested scope.

Morrowless

If I understand correctly, according to this and the OpenID Connect Core 1.0 spec, the ID token itself can be stored in cookies as a mechanism to persist sessions, and sent with every authentication-requiring request to the Client. The Client can then verify the ID token either locally or through the Provider's verifier endpoint (if provided, like Google does). If the token is expired, it should make another auth request, except this time with prompt=none in the URL parameter. Also make sure to send the expired ID token in the id_token_hint parameter, otherwise the Provider may return an error.

So, it does seem natural for the ID Token to expire, but prompt=none ensures the new ID token can be obtained smoothly with no user intervention (unless of course the user is logged out of that OpenID).

Eugenio Pace

It is the same intent: you can't use the id_token after it is expired. The main difference is that an id_token is a data structure and you won't need to call any servers or endpoints, as the information is encoded in the token itself. A regular access_token is usually an opaque artifact (like a GUID).

The consumer of the id_token must always verify the (time) validity of it.

I'm not 100% familiar with IS, but I would guess it is a convenience field. You should always check the exp claim.

Expiration is just one of the validations. id_tokens are also digitally signed and that is also a validation you must perform.

Thanks Eugenio. The main question I have is what you should do when the ID token expires? I thought (possibly wrongly) that to renew a short-lived access-token you HAD to use a refresh-token. But if the ID-token has the same expiry as the access-token, you will immediately have an expired ID-token, so it would seem pointless refreshing the access-token. Think I might be missing something here!

You would use the (non revoked) refresh_token to get a new access_token or id_token. Or simply as the user to login again. id_tokens are logically equivalent to access_tokens. Just a different format.

My latest understanding is that when the user has an authenticated session with the authorization server, when the access token expires the 401 => 302 redirection to the authorization server will get new access & ID tokens without the user's intervention. But in offline mode a refresh_token will only return a new access_token which says a particular user is allowed to access some resource. It can't return an id_token, as that would be saying that the particular user is authenticated and in offline mode that is not the case.

This would be a great answer to a question regarding what is the difference between id_token and access_token (especially when using opaque / reference tokens). Focus on answering the question first and then clarify how access tokens and id tokens are used?

pashute

Refreshing a token means that you can use it again for requesting something from the authorization server (in this case the OP - the OpenID-Connect Provider) EVEN WHEN THE USER IS NOT LOGGED IN. You typically allow this for limited resources only, and only after the user has logged in and been authenticated at least once. The refresh tokens themselves should be also limited in time.

In OIDC implicit flow you call the Authorization endpoint, and receive the ID token in the response along with all the scopes and in them all the claims info. Subsequent calls to an API are meant to be done with code flow. Implicit flow is meant to enable a javascript only or browser only app. Not an app that is interacting with a server. So even if there was a way to "refresh" this token, you should not - security wise - allow it to live too long. It will be stolen and reused by unauthorized users impersonating the id. You should force a new login for that.

In code flow you call the OP's Authorization endpoint, and receive an Authorization code (also called an authorization token, or authcode for short). This should expire similar to the id_token that you received in implicit flow, for the same reasons and cannot and should not be renewed.

Your UI or app then call the OP's Token endpoint, and receives (sometimes after the user's further consent through a UI to allow use of their owned resources on the OP's server) both:

An id_token, for authentication - which should never be used again in server calls, except as a hint during logout, when its expiration is not important anymore, and so, for the reasons above should be let to expire, and never be refreshed.

An access_token - which later on, when calling an API, can be given to the OP's UserInfo endpoint. That will return the claims, and the API can authorize accordingly.

You can refresh this access_token, since it only tells the API what claims the user has, and what resources (by scopes and each scope's claims) the user agreed to give you. As explained above this is for allowing access even after the user is not logged in anymore. Of course you never wish to allow the id_token to be refreshed, because you don't want to allow impersonation without logging in.

What you've said about the implicit flow is partly incorrect. A client that uses the implicit flow can obtain an access token in addition to an ID token and can use that access token to interact with a server.

There is a common practice, that when the id_token expires, the client requests new tokens from the server, so that the user does not need to authorise again. E.g. see damienbod.com/2017/06/02/…

dgonee

I wanted to post this answer as a comment but since I haven't been very active on StackOverflow, I guess I'm posting it as an alternate answer.

You also use id_token as the id_token_hint when attempting to log the user out of a session http://openid.net/specs/openid-connect-session-1_0.html. I honestly don't think that it really matters if the id_token is expired at this point since you're only concerned about logging out a particular user.