How to make a multi-step login page that's 1Password friendly?

jsnajdr
jsnajdr
Community Member
edited January 2019 in 1Password in the Browser

I'm a developer working on a login page for a web app. Because we support things like passwordless logins, the login flow is multi-step. First you enter the username, then click "Next". Only at this moment the password field appears and can be entered.

Are there any best practices recommended by the team on how to help 1Password fill both fields in one step? Many login pages have the password in DOM all the time and it's just hidden with "display: none". 1Password doesn't fill the field if it or any of its parent elements is hidden.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni

    @jsnajdr: Thanks for getting in touch. Indeed, we don't want 1Password filling hidden fields generally, since that's a common trick for malicious pages to collect user data. Though that's generally targeting browser autofill since that happens without user interaction, it's something we all have to be concerned about, as users and as the makers of an app to protect sensitive data.

    Anyway, it's an interesting question, and I'm not sure anyone's asked that before. :) I'm not sure there's an easy answer, but sticking to web standards makes a huge difference. So I guess my question is why a multi-page login process at all? That isn't any better for security, and it can be much more difficult for users -- especially those trying to use a password manager to save and fill login credentials in order to use a long, strong, unique password. If you do that, there just won't be any way for your users to successfully save a login for your site, since (I'm guessing) saving on the first page would only include the username, and saving on the second page would only include the password; so they'd most likely end up either being stuck with two login items for your site (and always have to select the right one at each step). On the other hand, if you have a standard login form on the same page, it's easy for users to save and fill their login credentials there using 1Password. That said, I would love to hear from a web developer perspective why a multi-step login process would appeal to you for your particular use case, if you'd be willing to share. :)

  • jsnajdr
    jsnajdr
    Community Member

    Hi @brenty! The main reason I see sites implementing multi-step flow is passwordless login. Some sites (WordPress.com, Tumblr) support "magic links", where the user logs in by clicking on an email link instead of typing password (very useful on mobile). Other sites (Google, Microsoft's live.com, many banks) authenticate users with a specialized auth app. Similar to an OTP in 2FA, but here the OTP is the one and only factor.

    The flow then looks like this:
    1. Enter username, click "Next"
    2. Browser issues an XHR request to retrieve auth methods for the username. Can be "password", "magic-link", "app".
    3. The next step depends on the user's auth methods.
    4a. Show password field (finally!)
    4b. Let the user choose between available method, like Tumblr does:

    4c. Start the OTP process, start polling for result, proceed after the user confirms login in the app.

    Many sites have a hidden (display:none) password field in the DOM even in the first, "username" step. Apparently that works with some password managers and browsers. Some sites (live.com) hide the password field with position:absolute and zero width and height. 1Password doesn't detect that as hidden (for now?) and fills the field. That's the route we'll probably take with our login form now.

  • beyer
    beyer
    1Password Alumni
    edited February 2019

    Hey @jsnajdr!

    We have in the past supported the filling of hidden fields which is indeed a solution that would allow 1Password to fill many multi-step forms. Unfortunately, it also led to decreased filling accuracy on other websites. There's a chance that we could add it back in a smarter and limited capacity, but I much rather see all of our 1Password apps support session based filling like 1Password X.

    With 1Password X when you fill an item, we create a new fill session that allows us to track if the username, password, or OTP have been filled. When the page updates we continue filling until all fillable fields from your item has been filled, or the session expires. So for 1Password customers who use any Chrome-based browser or Firefox I highly recommend they give 1Password X a shot! Unfortunately, for us at least, Safari doesn't support the same WebExtensions API which means we have some additional technical challenges to bring all of the excellent features 1Password X has to one of our favorite browsers. Luckily it's not impossible it's definitely on our list to work on. In the meantime, I've opened an issue (fill-340) to look into this further. I'll carve out some time to see if it's viable to reimplement the filling of hidden fields within the same form.

    I hope that helps!

    ref: xplatform/filling-issues#340

This discussion has been closed.