Checking user permissions allows you to have more control over access to your ASP.NET Web API.
Read more…
Brought to you by @andrea.chiarelli
2 Likes
What’s up Devs! How did you like this post? Please share any comments or feedback with us on this thread
With this approach, is it possible to make permissions editable from UI? I mean, if today I want users with ‘Staff’ role to edit student data but later I want to disable it via the UI. Could you please extend your blog to support this scenario if it is not possible with this?
Hey @prinkpan, you can edit user’s permissions and roles via your Auth0 Dashboard, of course.
If you want to build your own UI, you should use the Management API.
Please, check out this document to learn more.
Hi,
We are using this approach. We are getting all the permissions in access token but now permissions are getting large as we have lot of modules. What is the other way to access user permissions in asp.net core API instead of keeping it in access token?
Hi @bilalhashmi,
Welcome to the Auth0 Community 
It’s not easy to answer your question in a few words without knowing the specific context, and I’m afraid I haven’t the definitive answer. However, I can give you a high-level reasoning about authorization mechanics.
First, I think you should investigate why the number of permissions has grown so much.
Token-based authorization is appropriate when you have a well-defined set of permissions that don’t change dynamically. If your set of permissions is growing, maybe you need to think differently. Are these new permissions really needed? Can you represent them differently? Take a look at this question and the related answer to give you an idea of what I mean.
If your authorization needs are more complex than before, you may need to reorganize the information needed for making authorization decisions. Maybe you need to integrate information coming from the access token with information coming from other sources (e.g., a database).
Depending on your use-case complexity, it may be preferable to use different approaches like ABAC or FGA.
I know this is not a practical answer, but the appropriate solution depends on the specific scenario. For more detailed information, I suggest reaching out to professional services
Thanks for your response. I am working on a microservices based system and we have only one logical API in Auth0 to represent the permissions for different actions defined in them. For example, in the start, we have only one microservice called Glossary and we defined only three permissions create:term, update:term, delete:term and later on added FAQ microservice with permissions create:faq, update:faq, delete:faq and it is growing. You see permissions are not dynamic but these are growing due to new microservices. ABAC or FGA does not apply to my scenario.
I can’t contact professional services because I am still evaluating the Auth0 for my scenarios.
As you have realized, storing permissions in the access token may not be the right way for your scenario. But I also think storing permissions in the authorization server may not be the right way in this case.
Relying on permissions stored in the access token works for simple scenarios where the resource to be protected (almost) coincides with your API. In your scenario, it looks like you have multiple resources to be protected.
In your case, the source of information your API relies on to make authorization decisions can’t be the access token. I’m afraid you need to create your own permission store and a module to evaluate your authorization policy. Not sure if FGA can help in this case. For this reason I suggested reaching out to professional service, which can help you better than me even in this discovery phase.
Hi, I am Juan from Argentina.
I followed all of your guides about using auth0 with .NET Web APIs.
What I understand is that here you are generating a token with all those permissions/roles. It is possible to have different tokens with different permissions/roles with this approach?
Hi @RoblesJP,
Welcome to the Auth0 Community!
The approach described in this article is focused on the API side, where permissions are validated regardless of how tokens are generated.
To make your client application provide tokens with different permissions based on the specific user or user’s role, you have two approaches:
- By defining roles (see this article on Role-Based Authorization if you haven’t already checked out it)
- By attaching permissions following your custom criteria through Actions (see this article for an introduction to Actions and this example to get an idea of how to add claims to an access token)
I hope I have understood your question correctly and given you helpful guidance.
3 Likes
Thanks for the reply Andrea.
I saw that article of yours and I am not very sure about something but I need to check it first when I have time. I will post the question in the corresponding thread when I have things clearer.
Greetings Andrea and thanks again.
1 Like