Hey there!
We’re migrating our in-house user management solution to auth0 and have encountered a problem I’d like to ask about.
Eventually, our system should incorporate four different APIs (three ours, one 3rd party). One API of ours together with the 3rd party one are actually being used in the same product. We want to access these APIs from two SPAs (one ours, one 3rd party → the same one as above).
The goal we’re pursuing:
When the user authenticates through the 3rd party SPA, they can only access the 3rd party API.
When the user authenticates through our SPA, they can access both our APIs and the 3rd party.
We are operating within the same tenant.
I haven’t found a straightforward solution to this, but am considering using logical API to encapsulate the two “connected” APIs (one of ours and the 3rd party) to tackle this. Would that let me deny the users authenticated through 3rd party SPA access our APIs?
Hey @michal.zimmermann, Happy Friday!
Thinking tentatively, you could consider the following scenario:
(I)
A separate Auth0 connection is enabled for this 3rd party’s SPA, and a separate connection enabled for your SPA. This way, there will be 2 logical representations of the same user (depending on what SPA they currently log in) to which you can add relevant roles (and permissions associated with those roles).
Later, APIs access is managed per user roles and permissions. For further discovery, feel free to peek in here: Sample Use Cases: Role-Based Access Control
(II)
The second scenario (also RBAC-based) I can think of is having one connection enabled for both SPAs and altering the access level via an Action script that would run during login and alter the permissions based on the client ID (SPA) the user’s login to. Further reading: Sample Use Cases: Actions with Authorization
Please let me know if the suggested scenarios meet your needs or if you have any follow-up questions on this topic 
PS: While testing the RBAC, please remember about marking relevant API settings to allow Role based Access Control (I noticed members sometimes forgot about it while implementing):
Hope this helps!
Hey, @marcelina.barycka!
By a separate auth0 connection you actually mean two separate user pools/databases?
Right now, I have a working sample of using post login action to check what audience is the user trying to access → I deny the 3rd party SPA’s users access to our API. This seems to work fine, yet I’m curious about what you’re saying 
Yes 
, for example 2 Auth0 hosted database connections:
We can have two users (different ids) with the same email address if they are stored in separate connections - (and this is what I meant by saying "2 logical representations of the same user = the same email address)
1 Like
