stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Questions are community supported only and the authors/maintainers may or may not have time to reply. If you or your company would like commercial support, please see here for more information.
github-actions[bot]
I have a question regarding the reason why you'd want to choose between a user token (a token that was granted to the client by the user) vs an app token (a token normally obtained through ClientCredentials, and which doesn't have a user identity associated).
In the normal use-case, where the client is untrusted, and if I understand correctly, one reason you use a user token is to be able to allow the client to have access to whatever data the Resource Server serves about that user, but to also control which user identity the context is talking about. Thus, the token being signed, the client can't change which user's data will be returned. Which sounds fine in the context of an untrusted client.
But what about the scenarios where the client is trusted (it's part of the identityserver landscape, it might even use ROPC even thought, yeah, it's not generally recommended). In the case of a trusted client what's the difference between using a user token vs using an apptoken, and having the userid just part of the normal request, and not part of the token. In theory the trusted client could change the userid to fish for another userid, but you trust it not to.
Is it worth the headache of using a user token in that scenario, over an app token and just using the userid as a public parameter of the api interface?
Thanks, and I'm really curious about the answer.
EDIT: One thing that might be worth mentioning is that I'm only asking about access tokens. Not identity tokens. Though that should be faily obvious, now that I'm writing this. Anyway, I'll leave the remark here just to make sure.