How to refresh an id_token

Question

In the OpenID Connect Core 1.0 incorporating errata set 1 Section 12.2 is says:

12.2.  Successful Refresh 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.

Originally when the id_token is acquired, it is a signed, and perhaps encrypted, JWT. The id_token is then forward to other services within the same security domain. These other services require an assurance that the end-user has authenticated the request. This works well on the original request. However, in the refresh scenario, and if the id_token is expired, the "other services" have no method to confirm the user.

Sure the same information is available at the user info endpoint but this requires the "other services" to obtain the access token. Based on the least principle principals the Access Token has more privileges than the id_token being forwarded.

The only other option I am aware of is to copy the id_token into another JWT and send it but this is of course more "make work".

It seems to me that NOT returning an id_token is an issue if there were not scope changes from the original request.

Answer 1

OpenID Connect protocol leaves some implementation decisions to the implementer. This scenario you described is one such thing. But I see several options you can try out,

prompt=none

This allows a SSO behavior between authorization server

If the mentioned dependent services can consume the same shared session with authorization server, they can use prompt=none to obtain an interaction free id token.

The Authorization Server MUST NOT interact with the End-User in the following case:

The Authentication Request contains the prompt parameter with the value none. In this case, the Authorization Server MUST return an error if an End-User is not already Authenticated or could not be silently Authenticated.

Also, the authorization request can be sent with a minimal scope values if these dependent services have such requirement.

Session sharing

What if mentioned services reside inside the same domain and share the same session. Won't that make them to share the same principal.? This means you won't have to share id token with dependent services at all.