I have a user in Auth0 that can have an access of multiple websites (e.g. www.app1.com and www.app2.com) depending on the data stored in user_data (e.g. app_data: { subscribed_site: “app1” } ).
Is it possible to initiate authentication with classic universal login page and use it with custom Action/Rule that can read data from user_data, check value of specific tag (e.g. if “subscribed_site” == “app1”) and redirect user to one of the listed callback url of Auth0 application, so that user can login to either app1 (clientId 1) or app2 (clientId 2)?
It’s not possible today to change the callback url from within an Action or a Rule. Doing something like this would typically be considered an anti pattern as it could potentially lead to undesired consequences (such as potential security issues).
Also, having some user experience where one logs in to one application but is redirected to another is typically considered counter intuitive. Imaging the users surprise; they’d likely think they mistyped, and probably retry (browser) navigation again.
Assuming that the user isn’t prevented from using an application - as in there is some authorization restriction - then simply using out-of-box SSO (see How to Implement Single Sign On for details) would typically suffice. If there are authorization restrictions then you can certainly use an Action or a Rule to prevent token(s) being generated.
However, if you do have a definite need to solve for this use case, then your best approach would be to have all applications defined with a single callback, and then implement custom logic in that callback - e.g. using some (custom) claim in the token - to perform the final redirect to the intended destination. You can easily add additional (custom) claims to a token by following the guidance provided here.
What you are saying perfectly makes sense Peter. Odd it is, but this is a business requirement for a valid reason. Also, we cannot have same callback url for multiple partner applications.
But I found a way to resolve the issue using intermediate application that decides the target application and then initiate the silent authentication. So, all good.
Also, having some user experience where one logs in to one application but is redirected to another is typically considered counter intuitive. Imaging the users surprise; they’d likely think they mistyped, and probably retry (browser) navigation again.
