I have a requirement to vary the look and feel (and some options) on the Universal Login page based on the application the user is logging in to. I am able to do this in Rules by reading the “client_metadata” associated with the application. However, on the Universal Login page this information doesn’t seem to be available
This prior topic is related to the same issue:
However the solution provided is impossible. The universal login page is a web page on the client side. You cannot call the Auth0 management APIs from the client side. That would require a client secret which should NEVER be exposed client side.
How can I vary the look and feel of the Auth0 Universal Login page based on the application being logged in to?
Same issue. Backup idea would be to host a small endpoint, or a json file on S3 or somewhere similar, that can map the clientID to the style settings. Then add a fetch call in the JS of the login pages.
Yeah that could work @FullStackFool . I just hate the idea of having an entire piece of code and infrastructure for something like that.
Auth0, maybe if you’re concerned with exposing the client metadata automatically [i.e. that users could have put secrets in it], you could add a configuration option at the tenant and/or client level that’s “Expose Client Metadata to Login UI” or something of that nature so that people could opt in to do this and explicitly state that they’re ok with exposing this info (could even put a warning when they enable it).
Some of my need is stylistic like showing a different color scheme depending on which app you’re logging in to.
But other parts of the need is to actually vary the functionality of the login process (i.e. some apps allow generic Auth0 sign up, some do not because they handle it themselves outside of the login flow). I can enforce these through Rules and Custom Database functions, but I have no way to get the data on the actual client side to vary the experience.
Technically because the Client API supports a “custom_login_page”, I could partially do this but it means I have to manage multiple versions of the login page for the different configuration and a programmatic way to keep them up to date with source control and if I want to change those things, I have to change them all through the API. A very complex workflow that means I have to develop custom software to just vary the login page in any way between clients.
I’ll open up a Feedback topic so we can all vote and make suggestions on the solution to this need.