My tenant has multiple applications (dev, test and UAT), each one with a different database connection.
I’m using Auth0 Action (post-login) to manipulate the access token and for one of these items, in some scenarios, the Action needs to access the ManagementAPI to retrieve some data.
I understand that with Actions we now need to use clientId, clientSecret and domain to be able to make any request and I’ve also found another post explaining how to save these information into the secrets tab.
My question is how can I make my Action to be flexible enough to be reused in all my applications? I’ve saved the clientSecret into the secrets tab but the value is for a specific application and it won’t work when a request is done in another application.
Or do I have to duplicate the secrets (i.e. clientId1, clientId2, clientSecret1, clientSecret2) and add the condition to my code depending on the event.resource_server.identifier?
P.S.: I’ve found out that I can retrieve the clientId using event.client.client_id. This is scope safe so I just need a way to dynamically retrieve the domain and the clientSecret.
Typically we would recommend using seperate tenants for different environments (dev, staging, prod, etc.).
Also, I’m not sure I understand the entire scope of the question. Why won’t a single client work for your Action? Are you using the same credentials (client ID and secret) in your external apps as in your action?
Yes, I have two different applications (One for the Dev and the other for the UAT environment) with their own credentials (IDs and Secrets) under the same tenant.
We would like to have the user’s database separated as a user that is allowed to login in the Test environment is not necessarily allowed to login in the Dev environment. Could I have achieved this with a single client/application?
We do use the clientID and clientSecret on our .Net api but not for the login calls.
For the login API calls, we are sending the username/password to validate the credentials and using Actions to manipulate the jwt.
Does this clarify? Not sure if that is what you meant when you said “external apps”.
It would be easiest to have separate applications for the two different DB connections. It’s certainly possible to use a single set of client credentials but will cause some headaches.
The scenario you describe sounds like it could be resolved using a single database connection to store the users and metadata to determine what the user has access to.
What makes your test env and dev env different? If it’s the same application, what is the difference?
From a code point of view it is only a couple of versions behind but fundamentally the same application.
The reason behind the segregation was that the client’s login credentials have no access to our dev environment.
We have the same scenario set up for UAT and Production. They are under the same tenant (different from the Dev/Test) but different applications (XxxxxUAT and XxxxxProd).
Each application has it’s own database connection and set of users.
Sorry for repeating myself here but it might help you to understand the overall scenario:
Actions now run globally under a tenant (not per application) and I need to call the Management API but I can no longer use token: auth0.accessToken, domain: auth0.domain. I was using this way in Rules before.
The solution I found is to use domain: event.secrets.domain, clientId: event.client.client_id, clientSecret: event.secrets.clientSecret instead but since Actions are global in the tenant level then my event.secrets.clientSecret won’t work for both calls, Dev and Test (or Uat and Prod).
My workaround would be to save two clientSecrets into the secrets vault and check if event.client.client_id == 'xxxxxxxx'thenevent.secrets.clientSecretDevelseevent.secrets.clientSecretTest but I was looking for a more elegant solution than hardcoding the if block into my Action.
Thanks for expanding on that. I think this was the missing information needed.
The most common solution for this scenario is to have a tenant for each environment. This keeps all aspects of the each deployment separated. Duplicate tenant config/settings with the Deploy CLI Tool.
If that isn’t something you want to set up I would suggest using two actions, one for each client. You can run the the action for only a single client using the strategy in this example, similar to how you described.
Unfortunately, at this point in time, I will not be able to set up a new tenant so I will proceed with the duplication of the action with a single if block at the beginning of the code.
