Create icon / API for PWAs to enable password managers

Something that PWAs lack (intentionally) is the browser chrome, at least once saved to homescreen.

That means when you need to login, you cannot ‘share’ the page to a password manager like the browser can, or lastpass/1password.

Apps can get around this by including it as part of their inputs, e.g:

password-entry.jpg1242×2208 144 KB

The circular icon with a squiggle in the email field opens up your default password manager, which can then fill in the username/password fields. Without it you have to app-switch, which adds many steps to the process, and will reduce the numbers using PWAs.

Can an equivelent be created for chromeless browsers?

I don’t think adding an icon to trigger this is a good idea. That’s putting the browser into altering the UX of the web application in question. I think it would be best if there was some method exposed for PWA’s launched directly for password manager’s and OSes to look for to know which domain it belongs to. That way, it’s behind the scenes and things “just work” like normal.

Well, that is how most password managers work, e.g. Lastpass puts icons on the inside-right of each username/password input.

But anyway, I’m looking for a method of seamlessly using a password manager in a PWA, I’m not set on the specific example. Given that saved PWAs are essentially Chromeless, I think something would have to be added to the page?

I understand that is what password managers do in browser extensions. But in the context of a PWA you aren’t working in a browser context. You’re working as a regular application. So, I think it would be best to explore methods of working with the native platforms which provide password management APIs already vs just throwing something into the design of an app.

Do PWAs not work within a web view?

The way the native one works (in iOS) is with native code (Swift, Objective C), AFAIK that isn’t available to PWAs.

Presuambly there does need to be something provided by the native platform, but that something needs to work in a webview, no?

PWA’s as far as I understand it aren’t necessarily tied to any web view implementation. They extend from the browser itself they are initiated with.

Android for example has the autofill framework to allow apps to autofill content within other apps. I think there should be a way for PWAs to take advantage of this kind of API in this context. If iOS doesn’t provide a comparable method at the OS level for this, then that is up to them to get figured out. They do have some form of a Password Autofill API using your Apple Keychain data. So that would probably be the same thing that gets triggered in this case.

Now the native APIs may need some work to make this achievable cleanly, but that’s something to push for over forcing an icon into text fields in my opinion.

In iOS (tested with Twitter Lite) you have access to the Safari password manager. Yo do not have access to another password manager through the sharing dialog like in Safari.

I guess this is a limitation of Safari and not the Web standard. I think if you have a input field with type password then this is enough markup for a browser to know that it should show the password manager field.

That’s a good point, my device is setup to use an external PW manager, so saving passwords in Safari is disabled - I get no options in Twitter lite.

But if type=password should be enough, then it’s a matter of raising bugs per platform… somehwere.

I think password managers are just an intermediates solution, like screen scraping. The ultimate goal should be login-form-less authentication.

Chrome and Firefox currently support the Web Authentication API.

This is an alternative to password based logins that would allow PWAs to authenticate using the phone (or OS) itself, e.g. biometric authentication on the iPhone. Password managers (or the phone OS) would then only take care of storing and syncing the public keys.

Passwordless might be the ultimate goal, but my understanding of the webauth spec is that it enables second factor, and easy re-authentication. However, there still needs to be some core username and password separate from the webauth aspect.

Even if it did support replacing passwords (and you weren’t locked to one device), there would be a long transition time while many people still need a username / password.

It also doesn’t remove the core scenario of having a service (Eg Facebook), saving the PWA to your homescreen and logging in the first time. You wouldn’t have biometrics enabled from this device because this is the first time, so you need to use the credentials from elsewhere, a username / password.

It seems like this use case would be satisfied by enabling the credential management api to work with third party managers. https://developers.google.com/web/fundamentals/security/credential-management/

If you are happy being locked to one browser across devices, then that credential management would presuambly work for PWAs? At least ones created from that browser.

However, as someone that doesn’t want to be locked into one device or browser, I’d rather there was a share mechanism that allows for 3rd party password / credential management.

There is currently an open issue to add direct support for extensions to handle the credential management api: https://crbug.com/707900

It would currently be possible for third party managers to handle the api by replacing the native navigator.credentials object with their own.