Announcement Announcement Module
No announcement yet.
OAuth2 Scopes regex (wildcard) support/best practices Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • OAuth2 Scopes regex (wildcard) support/best practices

    Hello everyone,

    We've found ourselves in a situation when we need to use scopes to restrict individual entities access for oauth clients.
    For example we might have scope like customer.1.write, customer.2.write,... where there can be a thousand of customers and different users can have different permissions for particular customers. We're using CloudFoundry UAA which maps intersection of client allowed scopes and user authorities to access token scopes.
    The problem here that UAA uses strict match for scopes and this means that we have to list all possible scopes for all customers in the oauth_client_details what really creates complexity (scopes column length limit, scopes explosion).
    What we're thinking about is to introduce scopes regex(wildcard) support.
    For example we can register the customer.\d.write scope with oauth client and use regex match when calculating list of granted scopes.
    But we're still not sure about this solution.

    That's why I want to ask you whether someone was facing the same problem and how did you solve. I've tried to search on different forums but surprisingly I haven't found anything useful.

    Thanks a lot in advance

  • #2
    The UAA is (or can be) responsible for user data, but I'm not sure that the customer data belongs there, since it sounds overtly like business data. It seems like that data and any decisions associated with it would maybe belong in the resource server that is handling the requests (or some other centralized service).

    Having said that, if you really think customer data is natural in your authorization server, a better approach than changing the client scope matching rules would be to add additional rules not connected with clients at all. You said in the formulation of the problem that "different users have different permissions for particular customers", which suggests to me that it is nothing to do with clients registrations. You could have a single scope registered with a client that enables all customer.write operations from that client, and then add the additional scopes as necessary based on user-customier relations. The scopes in a token might look like this: [customer.write,customers.1,customers.2].

    We actually have a similar problem brewing in CloudFoundry, so I don't think it's unique. Cloud Foundry v2 has an entity-based hierarchical permissions structure (org-space-role-user) managed today by the Cloud Controller, but ideally we would like to manage that data in the UAA itself, just to centralize it. We are still debating how to handle the design, and we have started with an implementation where the top level (orgs) of the permissions are mapped to UAA groups, but the data are still managed externally.

    In the UAA you have a secondary but serious problem which is that the scopes in a token (by default) are all encoded in the JWT token value. This is fine if the scope numbers are bounded, and guaranteed to be fairly small, but it's no good for an open ended problem really because the tokens are sent as HTTP headers and, while the protocol itself doesn't impose size restrictions on headers, most commercial web servers do. The solution we are probably going to adopt in the UAA is to require clients to obtain a new token if they want to change the target (e.g. the customer in your case). We might do that with a refresh token grant, or some other exhange based on the old access token.


    • #3
      Thanks a lot for your reply. It’s nice to see that we are not the only who are having such issue. You told that you were still debating about the design. Could you please tell us whether you have email or forum threads with these debates so we can watch and participate in them as we are really interested in this feature? We can also provide assistance in code writing if needed.