So, we have access_token for APIs and id_token for client to show like 'Hello Alice!' and access_tokens can be refreshed using approach like ATM. But, what is the recommendation for id_token lifetime that cannot be refreshed that easily in that case? Also, Microsoft OIDC client by default creates Principal from id_token and for apps that are quite old (monolith, OWIN, you know.. (and it even doesn't redeem code for access_token by default..) that drives us towards bad practice of managing access via it (say, role claims inside id_token). What would be your recommendation here too? If it was already discussed I will be glad for the link as couldn't find it after several tries.
I was even thinking about adding Principal created from access_token, but cookie handler doesn't work with multiple principals, so that would not be easy to do.
In OIDC you would use the access token to refresh the claims of the user at the userinfo endpoint.
Generally speaking i would not recommend putting data that frequently changes into tokens.
Thanks for clarification.
Hm.. but I suppose that wouldn't work out of the box in case of federation. As gateway, at least in some scenarios, will need to identify user's original IDP and ask it for user info than do transformation (if required) of received claims...
True. The protocols don't help you here. You need to come up with custom data management.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.