Permissions, Apps, and Customers, Oh My!

Help
1

I’m trying to figure out if the following situation is either supported or can be made to work:

My system has two APIs: subscriptions and billing. Each API has various permissions, e.g. subscriptions has read:current-plan and write:change-plan while billing has read:show-payments and write:refund-payment (among others).

The above scenario seems pretty easy: I’ve got two APIs and each API has its respective set of permissions and these permissions can be put together into various well-named roles which can then be assigned to the appropriate users. So far so good.

Here’s the tricky part: A single user will often service or be affiliated with multiple customers. For example, I might have a small auto-repair shop as a customer and then another being a brick-and-mortar, clothing outlet, but a single individual will often have different permissions to interact with our billing and subscription APIs depending upon the customer.

To recap: a user jim might be admin role in our billing API with the repair shop customer (ID: 123) while at the same time only being a viewer role for the billing API with the clothing store customer (ID: 456).

I’m trying to make sure the system can handle 50K+ customers, so I’m not sure if creating an “Auth0 tenant” per customer makes sense, otherwise it seems like I’d overwhelm the Auth0 system and my administrative capabilities. By administrative capabilities, I mean that if I did use Auth0 tenants, wouldn’t I have to define all of the APIs, roles, permissions, connections, etc. in every. single. new. tenant?

I’m not scared of code, I’m happy to write the necessary code to facilitate the above situation. I’m mostly trying to determine if this is something that comes out of the box and which be enabled quickly and easily, or if this will require extensive amounts of coding and really goes against the fundamental design concepts and primitives baked into Auth0.

I’m really trying to avoid things like “login with you Gmail to handle the repair shop customer and then login with Github to do stuff for the clothing outlet customer.” I’d prefer to have the individual use whatever logins they want to identify themselves and then my app could inspect the claims/scopes/whatever to see what permissions they have as they attempt to perform API operations for the repair shop or clothing outlet, etc.

Any advice/thoughts would be appreciated.

2

Hi joliver1,

This sounds like a pretty straightforward B2B scenario, you should have no trouble with this. 50K users is not a problem (though 50K tenants might be).

First, can you clarify that this is B2B? And assuming it is so: are you doing a multi-tenant app or a single tenant app? For a multi-tenant app, repair shop customers (including both billing and admin) would log in to something like repairshop.yourapp.com and clothing store customers would log in to something like clothingstore.yourapp.com. For a single tenant app, customers would log in to login.yourapp.com.

In answering this question, consider whether it makes sense to a customer at the clothing store to say “I am using the same credentials I used at the repair shop”. If it doesn’t, a multi-tenant app is probably the way to go. If it does, then single-tenant, and you’ll have to package up authorization somehow. That’s a slightly more complex topic. Completely doable, but a tad complex.

Put more details here, and we’ll try to help

John

1 Like
3

Yes, the app is B2B. It’s a Node-based JS single-page app with 2 backend APIs. People go to login.myapp.com and once logged in, they can select which customer they’re targeting through a drop-down menu. The JS then performs HTTP calls to backend APIs that contain the customer ID in the URL, e.g.: GET https://<api-name>.api.myapp.com/v1/<customer-id>/<resource-name>

A request to the repair shop customer to see the list of payments would be:
GET https://billing.api.myapp.com/v1/123/payments
where 123 is the customer ID of the repair shop

A request to modify the subscription of the clothing outlet customer would be:
POST https://subscription.api.myapp.com/v1/456/subscriptions (with JSON payload)
where 456 is the customer ID of the repair shop

The person invoking these actions might be a simple, lower-privilege user over the repair shop customer while at the same time fill a highly privileged, administrative role over the clothing outlet customer.

It’s good to know that I don’t have to create 50K “Auth0 tenants”. That said, in some ways, it appears that Auth0 is doing this same thing I’m trying to achieve but internally with its own customers. Auth0 itself is a B2B organization in which I could theoretically be associated with 1+ customers—the first as an admin, the second as a viewer, and the third as a (pick an arbitrary set of permissions). The way that Auth0 seems to achieve this end is via the creation of tenant partitions in the dashboard.

In our use case, a given individual will usually be associated with one customer, but could conceivably be associated with a dozen or more customers, but that would be uncommon. Even so, we’re trying to figure out how to facilitate our use case.

Thanks for being so responsive!

4

We’re very interested in leveraging Auth0 for our solution and we’d love to get some tips or pointers to help us get started on how the authorization might work. We’re fine with “Completely doable, but a tad complex”

1 Like