Clarification on having multiple login API for different application in Auth0

A simple question of design on which is the correct way of implementing multi application login.
In my recent project i have a scenario where two applications (multiple applications in future) requires different logins. I am using Password-Flow strategy. I made it to work but i do not know whether this is the correct way.

  1. I created an Application (App-A) with 1 API (Api-A).
  2. When user login using App-A (backend service called different application in Auth0 based on which backend service the user has called). Following successfull login Auth0 It generates a custom token for App-A and sends it to the user.
  3. Similarly i also created an another Application (App-B) with 1 API (Api-B).
  4. Similar to the previous one i called different login service in Auth0 based on which application the user login in from.
  5. I have a common custom DB connection, and also in the server the information about the user is in the same database table. But the only difference is based on different login application jwt tokens will have different information added to it.

Question:

  1. Do i create a new Auth0 database connection for different Auth0 application (same tennant) because on login query (Custom Database) i ask for different information which in-turn is added into app/user metadata.
  2. The above step is to enable me to create a customised jwt-token for different applications.
  3. Are the above steps the correct way of building when we have multiple application login using Auth0.
  4. I also have custom library (Actions → Library → Custom library) to create tokens for different application (get those info from app/user metadata). I have a question, can actions be added to different application in Auth0 or is for the whole tennant. i.e Since i have different application in Auth0 to support different logins, is it possible to attach different actions (in my case post login for creating custom token) based on which application calls the login service. Any leads will be much appreciated.

Hey there @walter.adbe sorry for the delayed response on this one but wanted to share a couple thoughts here.

Using separate connections is one way to go about it - Organizations might be something to consider as well. Our Architecture Scenarios documentation may be useful as well.

The solution you’ve outlined is one possible way to achieve what you’re looking for. Again, organizations might be an option as well.

Yes - While the Actions themselves are tenant level, you can certainly introduce logic to single out specific applications. In particular, I am thinking of event.client.client_id. This as well as other post-login Action objects are outlined here.

Hope this helps!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.