Passing additional inputs from Universal login page

Hi

Greetings!
I am trying to do the below use case with Auth0.
Our user credentials are in the SQL back end and APIs are there to authenticate the user.
User permissions are in nosql database and we have apis for that as well.
When authenticating the users, I need to pass some additional parameters which will be required by the authorization apis to return the claims properly and embed them in the access token.
A few queries on implementing a solution for this.

  1. Is it possible to customize the universal login page per application - to get the additional inputs from the user during login which can be used later only for specific applications? (I am assuming going for the custom ui might help, but requires more development)
  2. Is it possible to pass any additional parameters to the custom connection - login script, apart from username, password and callback function?
    reference: https://auth0.com/docs/connections/database/custom-db/templates/login
  3. Is it possible to store session parameters anywhere apart from the user object data, global variables, that can be used only for the current user session - that can be referred in the rules that are executed? [or] Is it alright to store such temporary information in the user object data?

Thanks
Selva

Hi @Selva,

1- You can customize the whole universal login hosted page as per your requirement and display the relevant UI on the basis of application_id
2- Yes, you can pass as many params as you want, just concatenate all params and pass the string to custom connection and in custom database script parse all those params as you concatenate those in login page.
3- I am not sure about your point. Would you please explain it more according to your requirement.

1 Like

Hi @rashid779939

Thanks for your inputs. Just to confirm my understanding,

  1. Auth0 Management UI -> Universal Login -> Login -> Customize Login Page (ON) -> Script is where I am doing the customization. Is it possible to get the application id there? Or you are referring the custom ui development as in https://auth0.com/docs/libraries/when-to-use-lock
  2. But the login script currently does not take any parameters apart from username, password and callback as mentioned in https://auth0.com/docs/connections/database/custom-db/templates/login. Can i add an additional parameter here which will be routed by auth0 from the login screen?
  3. I am trying to get an additional input from the user along with the username, password and say an environment flag. Based on the flag, i should be executing different API calls in the custom connection. For doing that, I am trying to understand whether i can store the additional input (entered during login by the user) in some storage which later be referred from the auth0 rules/hooks.

Regards
Selva

1- Yes, you can get client_id using this fields config.clientID. This is how you can get client id of allication
2- If you using custome database connection simply concate you extra fields with pass in login screen and at the custom db script parse the pass fields and extract all those extra fields. For e.g
Let your pass is : abc123
Your extra fields is: extrafields1= ef1
Your extra fields is: extrafields2= ef2
So pass will be after concatenation:
pass= abc123:ef1:ef2
Now in custom DB script parse this pass fields and separate your extra fields and set in user profile.
3- Simply put that additional fields in user profile just like above and get that fields anywhere in rules.

Hi @rashid779939

Thanks for your inputs.
1 - Yes, you are right. I can see the config being accessed inside the template.
2 - This is what I am doing now. But is this correct - looks like more of a patch? Can i not pass an additional custom parameter downstream? (Login page -> Connection -> Rules)
3 - This is what I am doing. But is there a more temporary place for the current user login session that i can use? In my tenant, user can login via multiple applications at the same time. Then I will end up maintaining application specific local variables inside the user attributes. Is this a good idea?

Thanks
Selva

1- ok fine.
2- I believe this is the only way to pass multiple fields in case of custom database connection ihave seen so far.
3- Sorry i didn’t get your questions. If you can explain it a little.

Hi @rashid779939
Thanks.
3. As soon as the user enters the additional input in the custom login screen, I am pushing it in the password variable (with a separator), parse the password in the login script and I need a place to store the variable which can be accessed later in the rules. As of now, I am storing it in the user attribute itself which is accessible in the rules. But this is a temporary variable and valid only for the session. User might login next time with a different input or login from an another application (which is authenticated by the same tenant using the same login screen) with a different input. In this case, I will end up maintaining another application specific variable in the user data. So, I am wondering, is this the right place to store the value for this session specific variable? Is there any other alternate provided by Auth0 to store the session specific variables that are accessible in the steps of the login pipeline?
Hope this clarified my query.

Thanks
Selva

I am trying to get an additional input from the user along with the username, password and say an environment flag.

I suggest to search for for upstream_param or extraParams here in the forum, it should give some hints how to possibly do it.
(Two older threads with another older approach show up when you search for referrerId.)

Is it possible to get the application id there?

That’s available automatically in the ULP as well as later on in Rules. In Rules, that’s in context.clientID.

In the ULP, it’s available via:

var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
var clientID = config.clientID;

Hi @mathiasconradt

Thanks. I got the client id both from rules and Universal Login page.
Regarding the first one, custom login script accepts only 3 parameters as shown below.
async function login(email, password, callback) {
I can get the extra param from the application till the login screen (as part of config object). But is it possible to pass it downstream to login script?

Also please share if you have any inputs on maintaining a session variable (question 3 above).

PS: I am currently embedding that additional parameter along with the password.

Thanks
Selva

I can get the extra param from the application till the login screen (as part of config object). But is it possible to pass it downstream to login script?

There is a possibility, which isn’t standard, but I’d like to see if that would actually be the right approach. Because you mention this:

I need to pass some additional parameters which will be required by the authorization apis to return the claims properly

This sounds to me more like some logic that would make sense in a Rule rather than login script. Or what exactly does your login script do with that additional third parameter?

Can you rule out that a Rule and custom claims (added to ID and/or access token) not work for you?

1 Like

Hi @mathiasconradt
User authorization claims for multiple lower environments will be maintained/managed in a common store. When the user logs in to an application, he can mention which environment he is logging in to. That input should be passed as a parameter to the authorization APIs to fetch the environment specific claims.
To do this, I am modifying the ULP as this is a custom input from the user during login. I am getting the claims via a rule, but that rule needs this input for getting the proper claims. So I am storing this input in user attribute (which is my 3rd question above) from the login script. And reading the custom attribute in the rule before calling the AuthZ API.

Thanks,
Selva

When the user logs in to an application, he can mention which environment he is logging in to.

Where does the user make this selection? In the ULP (with an additional field in the customized login page) or beforehand within your application, prior to redirecting him to the login page (i.e. like Slack does it, see thread below)?

Asking because a similar scenario was described here, where the environment selection happens before the actual redirect to the login, which would make things a bit easier:

1 Like

Hi @mathiasconradt

In the ULP today as per UI design.

Do you suggest to move it out of the login page, pass it via extra param and access it from the rule using context.request.query.extra_param? (also this has to be stored somewhere, so that this can be accessed during refresh token and other flows where query parameter will not be available)

Thanks, Selva

It would make things easier, it’s what I’d recommended in the linked thread, where I actually described different approach, one being a preference due to certain privacy reasons.

Storing the selection: that could be via cookie or localStorage on your client side.

Hi @mathiasconradt
Thanks. I will discuss with our user experience design team on this. Could you please also share the alternate just in case they prefer having it during the login?
Also if the selection is stored in cookie or local storage, will it be accessible in the server side rule/hook?

Thanks
Selva

Also if the selection is stored in cookie or local storage, will it be accessible in the server side rule/hook?

You would need to pass it on in the request, however you refresh / request a new token, i.e. via getTokenSilently() option or whatever SDK you’re using.


Could you please also share the alternate just in case they prefer having it during the login?

This is a bit more complicated:

"enable_script_context": true,
"realm_fallback": true,
  • in the tenant settings, you’d need to set the Default Directory to your custom DB

  • adjust the login page, where the login call will pass on an additional parameter named realm with whatever value the user selected:

webAuth.login({
  realm: realmValue,
  username: username,
  password: password
},
  • in the custom database login script, add an additional context parameter in the function header, such as
function login(email, password, context, callback) {...

You’d then get have the third parameter available in context.realm in there.

2 Likes

Hi @mathiasconradt
Thanks. Let me try these options.

Regards
Selva

Hi @mathiasconradt

I think “enable_script_context”: true should be sufficient as i can access the context variables in the login scripts.
But when i try to perform the first step to enable the script context by calling the management API, I’m getting the below error. Should i be enabling any permissions?

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Payload validation error: 'Additional properties not allowed: enable_script_context'.",
  "errorCode": "invalid_body"
}

Below is the body content that I am passing.

{
"enable_script_context": true
}

Thanks in advance.

Regards
Selva

Hi
Appreciate any inputs on the error mentioned above. :point_up:

Thanks
Selva

Ok, the property seems to be under options and patching the options require the user list to be empty in the connection. Patching the below body returns 200.

{
"options": {
"enable_script_context": true
}
}
2 Likes