Usage of the user's id_token

[JannesLathouwers]

I have a general design question considering the user's id_token in the context of a web service.
The information I would like some clarification on comes from this document:
https://docs.google.com/document/d/1rHaTBPSZ-jKYLPFjGDR-7nvyrRWqhEITbwzKxpD2KY4/edit#

From this document it seems that when a user authenticates, the browser webapp is supposed to store the user's id_token and pass this along with any request made to a protected resource. The UMA user agent/PEP will use this id_token to check if access is allowed.

What happens when this id_token is expired? By default it is only valid for 60 minutes. Does this mean that a user has to re-authenticate every 60 minutes to access a protected resource? It is my understanding that id_tokens cannot be refreshed programmatically, unlike access/refresh tokens.

So what is the recommended way of using these tokens?

[rconway]

The ID token is used to support the uma flow implemented by the resource guard - ref. https://system-description.docs.eoepca.org/iam/uma-user-agent/.
Maybe an access token can alternatively be used for this flow - or can be used by the resource-guard to obtain the ID token, which can then be used for the uma flow.
@AlvaroVillanueva Can you advise.

[AlvaroVillanueva]

For security issues yes, the id_token has the expiration date (which could be increased if needed in the GluuUI) and therefore a re-authentication would be needed if this time limit is reached.
Also the UMA flow will need it to retrieve a valid RPT with the token claim format described here: (http://openid.net/specs/openid-connect-core-1_0.html#IDToken), I'd suggest to use the resource-guard with the access_token to regenerate the id_token in case is not a straightforward automation for you.

[rconway]

From your reply @AlvaroVillanueva it sounds like we may need to modify the uma-user-agent to accept an access token - which it can then use to obtain the ID token for the uma flow. Is that what you are suggesting?

[AlvaroVillanueva]

Yes, I'd say is the best option, or a nice to have feature but I thought the uma-agent already had it implemented. Knowing that, I'd first try out other alternatives to this such as changing the client used to return access_token as JWT, which I believe worked before in a similar situation (wouldn't put my hand on the fire). This can be activated in the specific client configuration in the Gluu UI under advanced settings tab. If it doesnt work, then yes, the user will need to authenticate again or try through the uma-agent if/when implemented.
There is a good clarification for the expiration date in id_tokens here:
https://stackoverflow.com/questions/25686484/what-is-intent-of-id-token-expiry-time-in-openid-connect

[rconway]

The suggestion from @AlvaroVillanueva to use the access_token has been tested and shown to work.
The client through which the token is obtained must be configured to receive the access_token as a JWT (this is an option in Gluu at least).

Through testing it has been verified that the access_token (as JWT) can be used by the resource-guard in the UMA flow to exchange the ticket for an RPT and so assert the policy decision - this also works for rules that specify is_operator.

The access_token should be obtained with a refresh_token that can be used to cope when the short-lived access_token expires.
The access_token should be provided in the Authorization: Bearer <token> request header in the calls to the protected resource-servers (such as ADES protected by resource-guard).