asp.net核心/ openiddict和客户端spa具有自定义权限的授权

Question

I need some help in understanding a basic thing or two with Token-based authentication. My setup is a backend asp.net core app with openiddict for token auth. It's all working well so far - I now need to add user-permissions. I will have a lot of them (eg User can view xy, user can edit xy, user can delete xy, with many different xy-components). Backend is working well so far, my problem is now: How to get these permissions via token to my client side app..

• As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?

• But how can I pack them into my id_token/ How can I add them to my payload?

• Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)

Thanks for your help!

Answer 1

As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?

In theory, nothing prevents you from representing permissions as claims, just like you'd do with roles or any other claim. In practice tho', it's rarely the best approach, because the number of actions a user can do is usually important (and often unlimited: can the user A update the product 124? And this other product?).

A possible alternative is to catch the 403 responses returned by your API when a user is not allowed to execute a specific action so you can display an adequate error message. Another one is to create an API endpoint that dynamically determines whether a user is allowed to execute the action, according to your own policy.

Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)

Both access tokens and identity tokens are digitally signed, so they can't be tempered with (at least, not easily). You don't need to validate signatures yourself, as it's already done by the validation/JWT middleware.