CODEWITHSUNDEEP
permissionsjwtaccess-tokenauth0claims
ahsan kamal
ahsan kamal

Reputation: 41

how to handle/manage a lot of permissions in access-token? what's the best approach?

I'm getting a "Request header is too long" error when i was trying to access my API and send token in header. How we can manage a permissions in access-token because i have a lot of permissions in access-token it's approximately 15kb in size. I know it's not recommended to store permissions in access-token then what's the best approach to authenticate and authorize the users on API side?

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?

    {
  "roles": [
    "Admin"
  ],
  "iss": "Issuer",
  "sub": "sub",
  "aud": [
    "https://example.com/api",
    "https://example.com/userinfo"
  ],
  "iat": 1666198659,
  "exp": 1666205859,
  "azp": "azp",
  "scope": "openid profile email offline_access",
  "org_id": "company1",
  "permissions": [
    "permission.1",
    "permission.2",
    ........
    "permission.150",
]
}

Upvotes: 4

Views: 2550

Answers (2)

Maria Ines Parnisari
Maria Ines Parnisari

Reputation: 17486

This could be a solution: https://fga.dev/. There's also the open source version: https://openfga.dev/

Basically, since every user has a lot of permissions, you don't store them in the token anymore; you can call this service which stores them for you.

Disclaimer: I am part of the team building this solution :)

Upvotes: 3

perustaja
perustaja

Reputation: 191

You have two options.

  1. You can try to shorten the permissions down using something like the approach here. There are lots of other similar questions with similar approaches. However, know that you limit your number of permissions based on what you inherit from so this may or may not work. You can stick a string into the JWT with each char working as a flag for a permission. This comes with more downsides, namely keeping the data up-to-date.

  2. You setup a remote system for authorization. Something like Policy Server from Duende. This means no authorization data in the JWT. For instance you can make a simple http call to your identity server from your api/client and have the identity server evaluate if the user can do what they want to.

The latter seems right for your scenario because of your large amounts of permissions. It comes with overhead but there isn't really an alternative. https://github.com/Perustaja/PermissionServerDemo is an example that uses the built in ASP.NET Core authorization evaluation along with gRPC for the network calls. You can make something leaner and simpler that basically does the same thing if you don't want a lot of infrastructure.

Upvotes: 1

Related Questions