1 Reply
      Latest reply on Jun 7, 2018 5:57 AM by gero206
      gero206 Level 1 Level 1 (0 points)

        I am in the process to design a login for a new app that will be associated with a domain, i.e. be the counterpart to an SPA.

        Obviously I want to use

        • iOS 11 Password Autofill, and
        • Shared Web Credentials

         

        I have read the documentation on autofill as well as watched the WWDC video about it. Also, I checked the article on Shared Web credentials, which I think is older than the new, reworked autofill. Said article recommends:

        Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.

        This strikes me a little odd, because it

        • Means I have to cover more possible inconsistencies, i.e. synchronize the keychain somehow wit the shared web credentials (what if I have credentials in the keychain as well as the shared web credentials, but they're different?)
        • Potentially leaves "garbage" behind in the keychain if my user user uninstalls my app (naturally I hope they won't ever do this, but let's be realistic, some will)

         

        Especially the last point had always bothered me in the past (before shared web credentials and autofill were a thing, or when my app doesn't have an associated domain). Unlike on macOS, the iOS Accounts & Passwords feature (in the Settings app) doesn't list ALL passwords, but only the ones used by Safari (i.e. the shared web credentials), correct? Keychain Access on macOS instead offers a means to view and manage all credentials, even those that aren't synchronized over iCloud.

         

        I understand why the same is not offered on iOS, but it also means that for those passwords that my app saves (locally) to "its" keychain "part" can only be managed if I offer a UI for this in my app. And if the user uninstalls the app before using this, the item will stay in the keychain, at least it was that way when I tried it a couple of years ago.

         

        My main question now is, wouldn't it be easier to disregard the article's advice and only rely on the shared web credentials for password storage? That's the part they can edit in Settings (if ever need be) and also it will reflect any password changes done on the website. I would design my app like this then:

         

        • First launch: App starts on the Login screen and offers the username/password via Autofill
        • User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
        • App gets relaunched, e.g. after a device reboot: The app skips the login screen due to the flag and gets the password and user name from the shared web credentials (assuming the user previously granted it permission, of course)
        • User explicitly logs out: The app deletes the flag, basically setting everything back to first launch
        • User deletes the username and password from the shared web credentials (e.g. in the Settings app or with Keychain Access on macOS): The app falls back to the login screen as soon as it detects this (e.g. when attempting a remote request, or after relaunch), regardless of the flag. I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)

         

        This setup would avoid any issues with different items in the keychain and shared web storage and it would immediately propagate updates done in the webpage to the app as well (which is what I'd intent for my app anyways). Is there anything that would keep this app flow from working?

        • Re: Shared Web Credentials and (local) keychain
          gero206 Level 1 Level 1 (0 points)

          Thankfully someone on Stackoverflow answered this for me, so here's the link to this.

           

          The summary is: Don't just use the shared web credentials, as they require user interaction every time you get a password. I misunderstand this aspect, or rather, I assumed it would work like on macOS and give the option to "always allow this app access".