Is it possible to access the query params that were passed to the login page when on the Guardian Multifactor
hosted login page (HLP)? When on the initial login page these are in the query parameters and are parsed to extraParams. I would like to customize the UI of the Guardian Multifactor HLP based on certain query params.
Hi @alex7. I’m afraid it’s not possible. The extraParams is a legacy thing from the past that is definitely not part of the OAuth2/OIDC protocol. Since the Guardian page never offered access toextraParams, I doubt it will ever be available unless a sound use case is presented.
May I ask, out of curiosity, what would you customize if those values were available from the Guardian page?
I thought the OAuth2/OIDC spec did allow additional query parameters passed to the authorization endpoint?
That being said, I am passing parameters to control the title / icon on the HLP. Right now I am able to do that for the HLP but since that info is lost when directing to the guardian page, I cannot customize the logo / title on that page. While extraParams might not be possible, is there anyway way to add info using the guardian rule that can be incorporated using the liquid syntax when generating the guardian page?
Hi again. It’s not possible to pass additional parameters to the Guardian page through the rule either.
Not trying to make a excuse, but the line of thinking is that the authorization server is a separated entity from the applications that request an authentication. Think of Google and its many applications: Gmail, Youtube, Chrome, Android and so on. When you log in, you always see the “Google sign in” experience, almost identical each time (i.e. not branded for each specific application). This helps the user understand that it’s the same Google identity that can be used to authenticate to multiple assets (even though you see “to continue to {application name}” in the bottom) and that the same Google session is shared across all applications that request it.
If you are protecting just one application with your Auth0 domain, it might make sense to tie the whole authentication experience to that single application (even though you will get an obvious disruption if you use an external identity provider like a social connection). But if your Auth0 domain serves as the identity provider for many applications, the idea is to convey a single image for the authentication subsystem and SSO between the applications using the same identity and session.