In an application I'm building, we're using JWT tokens as OAuth Bearer token.
Say we have a resource collection called things
, addressable by thing
ID, eg. things/1
, things/44
, etc.
Currently, whenever someone request an access token with the scope things
, we include a list of all the rights the user has to each of the things
it has rights to:
{
"sub": "Romeo",
"scope": [ "things" ],
"things": {
"1": [ "read", "write", "delete" ],
"44": [ "read", "write"],
}
// ...
}
This works fine, but things go bad when the user has a lot of things
. Because all the rights are encoded inside the JWT token, the token gets really bigger for every thing
the user has.
This is not scalable, and I need to find a solution for this. I could scope the tokens to belong to a single thing
at a time, but then token management for a client that manages becomes a hell (I need a token that can list the tokens and need to keep one token per thing
).
I can't get rid of Bearer tokens because some of our components are not able to talk to the token issuer for multiple reasons.
Is there a standard way to solve this problem? I was thinking about making tokens with the things
scope interchangeable, so I can exchange restricted tokens that only have a part of the things
in them for other tokens that have other parts of the things
in them.
That information doesn't necessarily need to be in the token. As long as the token contains a reference to the user, the Resource Server can do a lookup in to some backend service/database to retrieve the corresponding permissions, associated with exactly the resource that is being requested at that time.
That service doesn't need to be the Authorization Server itself; it can also be a database or any type of backend system (probably the same that the Authorization Server would talk to).
I think @hans-z has it correct. oAuth does not solve this problem for you.
When you hit the pain barrier, I would suggest your implement a User-Service where "things" can be requested with the JWT token.
To postpone the pain barrier, you might consider changing to JSON Web Tokens or another implementation where token compression is supported or re-code the tokens with protobuf when sent over the network.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With