Question about accessing UserInfo endpoint after ID token expiration

[kaeruko]

As described below, UserInfo endpoint needs a ID_token,

[NOTE: Due to the possibility of token substitution attacks (see Section 16.11), the UserInfo Response is not guaranteed to be about the End-User identified by the sub (subject) element of the ID Token. The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token; if they do not match, the UserInfo Response values MUST NOT be used.](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse)

Although access tokens and ID tokens have an expiration date,
Only the access token is newly issued by refresh, and expire can not be renewed even if the ID token is reissued.

I am wondering how to get the latest user information after the ID token has expired, but in that case it is ok to use the expired ID token when accessing UserInfo?

[Takahiko Kawasaki]

(I talked with her before she registered this issue, so I add complementary info.)

What she wants to clarify is:

OIDC Core, 5.3.2 Successful UserInfo Response, requires that the RP confirm that the sub claim in the userinfo response matches the sub claim in the ID token which was issued together with the access token. If the RP wants to access the userinfo endpoint after the ID token has expired, is it required to get a new valid ID token in some way or other in order to compare the sub claim in the userinfo response to the sub claim in the new valid ID token? Or, is it enough to confirm that the sub claim in the userinfo response matches the sub claim in the expired ID token?

(This issue shouldn't have been registered to FAPI Issue Tracker, though.)

[Takahiko Kawasaki]

If the implementation of the userinfo endpoint might return sub which is different from the sub associated with the access token on the second and successive API calls, the client would not be able to know whether it is the legitimate response from the userinfo endpoint or a result of a token substitution attack.

So, if you are using an authorization server whose userinfo endpoint may return a different sub on the second and successive API calls, you cannot repeat to call the userinfo endpoint with the same access token. This means that you have to get a new ID token every time you call the userinfo endpoint.

On the other hand, if you are using an authorization server whose userinfo endpoint returns the same sub for the same access token, you don't have to get a new ID token every time you call the userinfo endpoint. That is, it is enough to check whether the sub claim in the userinfo response matches the sub claim in the expired ID token.

[Joseph Heenan]

We discussed this on the 16th Oct WG call and don't think this is specific to the FAPI spec so are going to close it here. You may wish to open an issue on the openid connect bug tracker, https://bitbucket.org/openid/connect/issues?status=new&status=open