I’d like to use Auth0 for API authorization on a multi-tenant SaaS product. Users in the SaaS product can be part of one or many tenants/companies. They should be authorized automatically for first-party clients, but should need consent for 3rd party clients.
What’s the best practice for providing limited access via 3rd party clients to particular companies?
How do we allow User A to grant access to Client B to access Company 1 but not to access Company 2?
Out in the wild there seems to be a few approaches to this:
Github approach – Oauth tokens are granted for a 3rd party token. (e.g. "aud":"http://api.example.com"), but github internally implements an ACL that prevents access to certain Organizations.
Google approach – If you are logged into as multiple users, you choose one user to use for authorization (e.g. "aud":"http://api.example.com/company1"])
To implement these via Auth0:
Implement an internal Whitelist/Blacklist for clients (Github approach)
Set up an audience-per-company approach, registering each new company as a resource owner via the Management API. Implement a proxy as the first step in a consent flow to choose a company, passing along that as the audience to the Authentication API. (Google approach)
I’m leaning towards the Github approach, but the user experience isn’t as nice as the Google approach.
Disclaimer: The answer below is an opinionated view on the subject described in the question. Given it’s almost impossible to describe all the assumptions in a single post, take it with a grain of salt.
Based on the information you provided and what I know about the API authorization functionality if your scenario strictly requires that the end-user is the definitive decision point in relation to what companies a third-party application can access on their behalf then the second option (the one you refer as Google approach) might require less effort to implement.
The reasoning here would be that, if end-user is the decision point, in order to go with the first approach (the Github one) you will have to implement a custom management interface where the end-user can see all the available third-party applications and state what they should be able to access or not on their behalf; in conclusion, a place for the end-users to manage their respective ACL that it would then be used by the API.
If you represent each company as a different resource server than the ACL management interface, although it will sill have to exist, can be achieved by leveraging the Auth0 provided consent page. The third-party application (Client B) could ask User A to access Company 2, but the end-user would reject that request through the consent page leaving the application without access.
The side-effect is that your single API will now have to accept access tokens with a bunch of different audiences and derive access control information from the received value. Additionally, if the ACL for third-party application could be reduced to a simple flag associated to each company the users has access, for example, a Enable third-party application access toggle on an existing settings page for the companies the user has access then my assumption that the Google approach would take less effort might not even be accurate.
In conclusion, despite the initial inclination for the Google approach, it kind of depends! If you can find a really simple way to derive the ACL for each user I would also serious consider the Github approach. On the other hand if it would take a lot of effort to provide the custom management for the ACL I would consider the Google one.
Finally, just as an additional note, we have plans to augment the possibilities around the customization of the current consent flow so even though I can’t provide a definitive ETA for this additional flexibility, it does seem to be an extra argument in favor of the Github approach as even though the current UX would not be ideal it could be later improved by leveraging extra levels of customization available for the consent flow while not having to model your API as different resource servers.
Thanks for the response, I figured that a resource-server-per-company approach would be pretty heavy handed. Looking forward to being able to customize the Consent UX.