The "Last time you logged in with" button

IAM
#1

tl;dr: Can someone help do any user testing/a survey/data gathering about users use of the “Last time you logged in with” button?

When we first enabled the Auth0 Lock and began using Auth0, we enabled an option in Auth0 so that if the user already had an active session with Auth0, it would prompt them to confirm that they wanted to log into the relying party (website) they were going to with their current user or give them the chance to change and login as a different user.

Inline image 1
Last-time-you-logged-in-with.png626×589 15.7 KB

Without this option enabled, the user never sees this prompt and is immediately sent to the relying party as the identity they are currently logged into Auth0 as.

The reason I pushed for this option being enabled was so that if John Doe visited mana and logged in as jdoe@mozilla.com, and then later went to discourse where they had an account under the email address john.doe@gmail.com, they’d have an opportunity to change to using the correct identity with discourse as opposed to having a new account created on discourse as jdoe@mozilla.com

Since the deployment of Auth0 I’ve heard anecdotally complaints about always having to click the grey button. As someone who probably doesn’t have any accounts on relying parties that use auth0 other than my primary gene@mozilla.com identity, I’m also irritated by having the click the button.

Can someone help us to do some kind of data gathering or user testing to determine if people want this button, need this button, don’t want this button etc?

Once we have any data other than annectdotal stories about whether this is good or bad, we can either leave it or disable it.

-Gene

1 Like
#2

Note, also referenced this here: https://github.com/mozilla/standup/issues/425#issuecomment-331263141

#3

Great highlight @gene, I too would love to understand usability around this prior to our lock refresh. I’ll loop in Rina Jensen (my research counterpart) and we’ll see what we can get set up. Stay tuned!

Side note: I’ve heard in passing from users that they either ‘love’ this feature or ‘hate’ this feature. Perhaps we look toward providing users the option to enable this or not? Then I realize that I’d like to better understand the technical implications of enabling such a thing. (I feel that we’ve talked about this somewhere back on a snowy day in Berlin long ago…)

Megan

#4

I played with the current lock last week to see how feasible it is or not:

  • In the current lock we need to either upgrade libraries (it is some work) or write a specific function for this. Both of these are some work to get right and this is entirely due to how specific our current lock is

  • In any lock rewrite (including “using new auth0 libraries”) it’s pretty much an on/off setting and easy to implement (or even write ourselves should we not use the auth0 library - it’s simple to do): https://auth0.com/docs/libraries/auth0js/v8#using-nonce

A few other notes, including my own 2cts on the issue:

  • Okta SSO would also log you in directly if you had a session open (as most SSO’s do)
  • Some people think they’re logged out of Auth0 when they see this button due to the way it looks like, and that this is easier than having to re-login - but it’s not correct, they’re still fully logged in and we voluntarily stop them here so that they get a chance to change identity
  • Changing identity is messy because it only works when calling the lock directly (like the SSO Dashboard does). Going directly to the RP bypasses that and you may or may not get prompted.

Due to this last point, I personally would want to have it a on/off behaviour (as you propose) where people can choose within the SSO Dashboard instead of the lock

1 Like
#5

Thanks for the clarity @kang, super helpful. I have a gut level assumption that using the SSO Dashboard as a source of truth for log in preference such as this is the best way to move forward.

And also agree, most users don’t necessarily understand that the current button is a tool for identity management (rather than a result of a ‘keep me logged in’ type selection at the lock level).

Testing will help us confirm/deny these hunches and decide how best to implement in the new iteration(s).

2 Likes
#6

Megan, what if anything should we do around this to get this on the board and tracked and into a sprint or something? I’m unsure how best to slot this into the flow of work.

#7

Thanks for the flag Gene, this fell through the cracks. I’ll follow up this week and determine how we move forward. If a survey of some sort is feasible, I will get that added to the backlog and update when there is data to share.

#8

@gene I’ve had a chance to speak with Rina about this overall user flow. We both agree that this ‘extra click’ is creating a barrier and feel comfortable saying: we can forgo testing and disable it. This is said with the assumption/understanding that a future goal for account management includes a way for users to choose their authentication method at the SSO Dashboard level. Additionally, if users want to enable this feature themselves, we could create that functionality as well (see @kang’s previous comment).

All of this said, if the team feels it is worthwhile to test it as is now, here are some options [w/t-shirt sizing for potential effort]:

  1. [medium] Do you have any way to aggregate this data from the user base? Meaning are we collecting any data on the backend that tells us user behavior around how many email accounts they use to auth? e.g. this user logs in across RPs with 3 emails vs this user who only logs in with 1. If so, this would be sufficient info to help confirm a decision to disable or keep this step in the user flow.

  2. [large] We could move forward with a survey that is hard-coded at this point in the flow and asks users something along the lines of “Do you have more than one email that you use to authenticate?”. Additionally we could get into further questions about “What do you think this button does?” and “Do you ever log in using a different account?”. Rina would work with us to write a quick script that one of you would need to implement as code.

  3. [small] We can disable the feature now with the intent of building further account management tools into the SSO Dashboard. Also, with the potential of providing users and enable/disable feature sooner than later.

This is a great use case example for basing user journey iteration on known heuristics over usability testing (another way of saying: users don’t want to click more than they have to and we already know that).

Let me know thoughts & thanks for your patience!
Megan

cc @r_Up2mI1KfXvmSMPkEfhC6eg @akrug

2 Likes
#9

Is it possible to bring this button back as a user option or something? I was perfectly happy with the extra step as it lets me confirm which of my two identities (personal vs. staff) should be used.

I don’t like being forced to use container tabs to separate them when it worked perfectly well before this change.

1 Like
#10

I don’t like being forced to use container tabs to separate them when it worked perfectly well before this change.

Some users do, some users don’t. There’s a lot of discussions around this (we are some newer topics around here and in GitHub) and I figure that we’d still like to be able to give the option so that you can follow your preferred flow at some point though this is still being tested/discussed/etc.

That being said, do note that it does not work well with the back button and there are issues that are inherent to that design: https://github.com/mozilla-iam/auth0-custom-lock/issues/43#issuecomment-368171831 (and more discussion here as well https://github.com/mozilla-iam/auth0-custom-lock/issues/34)