The "Last time you logged in with" button

(Gene Wood) #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.

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, and then later went to discourse where they had an account under the email address, 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

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 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.


(kang) #2

Note, also referenced this here:

(Megan Branson) #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…)


(kang) #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):

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

(Megan Branson) #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).

(Gene Wood) #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.

(Megan Branson) #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.

(Megan Branson) #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!

cc @hmitsch @akrug