We are using AuthO for our authentication purposes. It’s working great so far. Currently we have only one type of user - say A.
We are now introducing a new type of user to the application - say B.
We want that based on the type of user (i.e A or B), user should be re-directed to different page after login. The application flow will be different based on type of user.
One solution I can think of is creating a different tenant for each type of user. Hence each user type will have its own authO domain, redirect url etc. We would be providing different login urls to each user type.
I am interested in knowing the best practice as far as authO is concerned for handling such scenarios.
Is there a better alternative to the above approach?
If everything identity-related is the same between type A and B (login page branding, registration process, etc.), it doesn’t make sense to burden yourself with a separate tenant. Application-specific logic should remain in the application.
If you know before the user login which type he/she is, then you can define two separate callbacks based on type and initiate the authorization flow with a different callback URL.
If you only know the type after user authentication, then you could do something like this:
- add a user type claim to the id_token with a rule
- your application callback logic should parse the id_token and redirect users to the appropriate page based on their type
Hey @VnceB thanks for your response.
We intend to have different login page for user of type B. The application flow and also screens (content, layout etc) would be different for user type B as compared to user type A.
In the light of this information, do you think it would be better to have a different tenant for user type B?
Thanks in advance.
There are other ways but the simple solution is to have multiple tenants. The only constraint is that your application must have the ability to support multiple authorization servers and token signatures.
It comes down to how many user types you will have, You don’t want to end up with too many Auth0 tenants …