10

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.

romeovs
  • 5,785
  • 9
  • 43
  • 74

2 Answers2

12

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).

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • 1
    Yes, but that would defeat the use of bearer tokens no? The idea is that a client does not have to talk to our Resource Server at all. – romeovs Sep 16 '16 at 13:06
  • You are mixing bearer with JWT and RS with AS – Hans Z. Sep 16 '16 at 13:17
  • Could you explain me what RS and AS mean? You're saying there's no use case for accessTokens that contain the access rights the token itself has? – romeovs Sep 16 '16 at 14:27
  • 1
    I'm actually still running into this issue. The reason we're using Bearer tokens is that we do not want to have to talk to our Authorization Server (or its database) at the time of validating the token, because that creates a single point of failure on the AS. – romeovs Sep 18 '17 at 11:38
  • Bearer != JWT. Bearer token doesn't mean it is self-contained, it just means that anyone presenting that token will get access. What you probably mean that you don't want to get away from **JWT** tokens. Then you'll have to deal with the size limitation. – Hans Z. Sep 18 '17 at 11:58
2

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.

Heikki
  • 199
  • 5