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?
(Note: I asked the same question on the apple developer forums, so if you see that as well don't be confused. I will update any potential answers from there to here and vice versa.)
Edit to address #Aaron's answer:
Thank you so much for the info. Your answer helped me realize I misunderstood something about shared web credentials: I assumed that for an app with associated domain, you can access the credentials without user interaction (after perhaps an initial authorization). Like you can set the checkbox on macOS when an application requests credentials. I now realize this is wrong and on iOS you would always have to verify with the user, thanks.
For completeness sake, I still want to point out some of the other things you said:
You are right, we will eventually use token based authentication, so I will save that in the keychain (probably in addition to the password, see below). I just tried to keep the question simple enough at first.
Our app is like an email client where you update new incoming "mail". The mentioned "login flag" in something like the user defaults would thus just indicate whether the app should behave as if subscribed to an inbox or not. Like in Mail, you wouldn't expect to have to login even after relaunch.
For this reason I will probably eventually save the user's password in the (local) keychain along with a token. If the token expires, I can request a new one without user interaction, that's important in our general site and app design. Only if that request fails I would use the shared web credentials (updating my local copy of the creds in the process).
For what it's worth, the last point you mentioned is probably debatable. On macOS, for example (where you can edit the entire keychain, not just Safari passwords) de facto logs you out of an app. Mail, again, as an example. If the keychain item for an inbox is gone, Mail re-asks that the next time it is launched and tries to access the content (effectively a "kind of" login in a way).
Again, thank you a lot for answering, now I can close an open todo. :) Also thanks to #HamZa for giving out a bounty!
Considering this advice:
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.
The main issue here is that the shared web credentials process is a little clunky — it requires user interaction and takes time to resolve the credentials. So if the user has already authenticated with your app you want to avoid showing them the login page at all. You can do this by storing credentials in your app's keychain where you can access them immediately without a network connection or user permission.
This doesn't mean you need to store the user's password in the keychain. Typically you would store something like an OAuth access token in the keychain. The presence of this token means the user is authenticated - and if an API endpoint rejects your token then you can take them back to the login page.
This suggestion:
User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
is possibly insecure depending on what you're hiding behind the login page, but typically any content belonging to the user should require a valid token to access, not just a bool in the user defaults.
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)
I disagree with this; I would not expect an iOS app to log out because I deleted a password from my Safari keychain.
Related
I'm writing an offline application that uses the Dropbox API. When a user comes to the application, I'm using the https://api.dropbox.com/oauth2/token (docs) to get a refresh_token, which I store for later use.
I am calling the same endpoint every time the user logs in (unless I've already got the user's data in a cookie). I'm not sure that this is the best way to go about it: I at least need to get the user's account_id, so that I can look up their refresh_token in the database if I already have it. But every time I call https://api.dropbox.com/oauth2/token, the user is redirected to the Dropbox app authorization interface, as if they've never approved the app before.
So I would either like to know how to stop Dropbox from forcing the user to re-authorize an app every time. Or, if that is just how https://api.dropbox.com/oauth2/token is supposed to work, I'd instead like to be able to get their account_id somehow when they visit my page.
(In case it's relevant, the app is still in development mode at this point.)
The https://api.dropbox.com/oauth2/token endpoint is an OAuth endpoint that the app can call to get an access token/refresh token. Being an API endpoint, it does not itself redirect the user to the Dropbox app authorization page.
The Dropbox app authorization page is at https://www.dropbox.com/oauth2/authorize (documented here), and the app decides if/when to direct the user there to authorize the app.
You generally only need to send the user through the app authorization flow (sending them to https://www.dropbox.com/oauth2/authorize and then calling https://api.dropbox.com/oauth2/token) once per user for an "offline" application. Once you do so, you should store the resulting refresh token for that user. You'll typically store the refresh token for that user tied to their user account in your own app.
Exactly how you manage the user accounts in your own app will depend on how it's built, but, as it sounds like this is a web app, typically you would use the user's browser cookies to identify the user when they return to your page so that you can look them up in your database and retrieve their details, such as their corresponding refresh token. (Or, if they're not already signed in to your web app, you would have them do so first.)
Greg's answer is very helpful, and very politely addresses my misunderstanding of the auth flow. (I was revisiting old code I'd written years previously—obviously I should have documented it better than I had!)
In the end I believe that Dropbox was forcing me to reauthorize because my application was in development mode, and had a small user base. When I used the identical code in an app set to production mode, it stopped forcing me to reauthorize. So the “problem” is really a Dropbox security feature, and the solution was just to use production mode.
I want to offer some paid content in the app but I don't want the user to go through an Authentication process. I would like him to enter the app and directly be able to buy some of the content and remember that this user has bought it if he comes back later or uninstall/reinstall the app later on. (Like most meditation app on the Store right now)
Is it possible using Firebase Services and if so, what would be the good way to track paid content for anonymous user?
An Anonymous user IS a user without details (Name, email, password, etc). It has a unique UserID
So YES. You can save anything to the database using the User's unique ID. But remember. Every app is capable of performing operations inside their sandbox directory. which also has a unique ID and resets when the app is uninstalled.
In a sentece. Firebase won't remember the Anonymous user ID if the app was deleted intentionally.
The docs does state this very well:
You can use Firebase Authentication to create and use temporary
anonymous accounts to authenticate with Firebase. These temporary
anonymous accounts can be used to allow users who haven't yet signed
up to your app to work with data protected by security rules. If an
anonymous user decides to sign up to your app, you can link their
sign-in credentials to the anonymous account so that they can continue
to work with their protected data in future sessions.
Read more:
Authenticate with Firebase Anonymously on iOS
You could theoretically set it up to where it would redirect the user to a TextField page asking him/her to make a "password" and "PIN" of sorts. This "password" and "PIN" could then be stored into a SQL server database as an anonymous user. When re-downloading the app you could have a page dedicated to purchase recovery where all a user would need to do is input this "password" and "PIN", after they have correctly entered both it would return purchases to their account.
things to be wary of:
-People may use the same password, which is why I recommended a PIN as a way of two-step authentication. Keep in mind also that your app will need to test the password against the server before uploading to make sure that the password doesn't already exist and tells the user that the password cannot be used in such case.
-This is essentially the same thing as an account with a username and password... the only difference is that you aren't going to be collecting other information on them, such as email and birthday, etc., making it more anonymous.
-This is a very rare case of question and I know this is a crappy answer, but honestly this isn't the best idea to implement unless your app heavily relies on it.
On iOS 11, Apple introduced a new way to share auth data between the web and a Mobile App with SFAuthenticationSession.
It would be a bad user experience to show the SFAuthenticationSession prompt to every new users - that might have never used my website - to have them agree and then get nothing out of it and have ask them to login.
The documentation is pretty empty on Apple side. This is the only example I found.
Is there a way to know if there is a cookie available before showing the SFAuthenticationSession prompt? Or maybe, with the Associated Domains enabled, when authenticating with my domain, the system should not show the prompt?
No. Even if there aren't cookies, the user can login entering his username/password and then clicking on "Login"/"Enter" on the website (E.g: Facebook, Instagram).
Accessing the cookies won't be enabled:
When the webpage is presented, it runs in a separate process, so the user and web service are guaranteed that the app has no way to gain access to the user’s credentials. Instead, the app gets a unique authentication token.
Official docs
Working example for Instagram-OAuth: https://github.com/dvdhpkns/SFAuthenticationSession-Instagram-Oauth
And the GitHub repo you added was posted by the author to send a bug report about errors in cookie sharing for local servers (rdar://33418129. Original tweet)
Are cookies shared between Safari and SFAuthenticationSession?
#DVDHPKNS
They’re supposed to be shared, but we have some timing bugs right now. Please do file bugs about what you’re seeing.
#rmondello (Apple employee)
P.S: They added more information to the docs since your original post date.
I am creating an application using Appcelerator wherein the user needs to enter the username and password to login. Once logged in, the user can enable TouchID for authentication. After logging out, the user can use the TouchID for authentication and use the application.
My flow is that once the username and password is provided, I store those two information in Keychain using the following module iOS Keychain Module. Then I use ti.touchid to authenticate the fingerprint, if success, then I retrieve the username and password from keychain and then send it over HTTPS web service call and login the user to the application.
My query is that, whether this is an acceptable approach.
I am not an iOS developer nor does any ti or keychain terms mean anything to me at all. That's for a start and to reduce the number of down votes i might get.
In terns of security, I would suggest that you imagine obtaining that particular user's phone where you know you have some authentication credentials stored. Let's say I am a user of your app, already logged-in and have my credentials saved somewhere on my device, and you obtain this phone by stealing it from me.
Now, will you be able to access my account in anyway? Will a hacker with access to the physical phone be able to retrieve any information stored in your Keychain storage?
If so, If you can think of anyway to do so, then your approach is not valid.
I understand you want to save users sometime by making sure they can login with just their fingerprint, which is a valid reason to think of such an approach, but you will have to think everything in terms of reverse engineering.
Additional recommendations would be using an on-the-fly hash to store information in the Keychain and making sure to check that before restoring the same. For example, user credentials saved on "home wifi" can be verified with your fingerprint only "at home" on the same wifi network where the same will be invalid on a different network.
i.e)
(keychainItem.x = y) is TRUE ONLY IF (something else)
where this (something else) is something that will prevent hackers from accessing the Keychain even if they have access to the device itself.
I do this myself when programming web applications with stored cookies. I for example use a stored cookie ONLY IF it is being accessed from the same IP it was saved from. Anytime that IP address changes, user will have to re-authenticate even if the cookie values are correct.
Hope this helps.
I am unable to revoke application access by a user via either a password reset or by explicitly clearing app keys in user management. The latter method gives a reply indicating that access has been revoked, but when the user hits the tool, they are not re-prompted to approve access to their information.
There are number of possibilities here:
It's possible that there is latency between the declared revocation of keys and the cleanup task that goes through the database and actually cleans them up; I believe that at one point, such a latency existed, was identified, and fixed through service packs and subsequent releases. Accordingly, you may address this issue by ensuring that your back-end service is up-to-date with its available service packs.
It's possible that what's being revoked is the keys, and the necessity to authenticate to rebuild keys, but not the confirmation step that would appear to the user asking for access permission (assuming the user once authenticated, and checked the "don't prompt me to ask for permission again") dialog.
Can you confirm if the request for user tokens by the client application actually does get back tokens? Or is it just that the authentication step happens with no notice of client confirmation to access?
Note that the re-authentication might appear to happen silently; if the client application's request for user tokens happens through a user's browser context where the back-end service can determine that the user is already logged in to the LMS, then the request for tokens could succeed automatically:
The user is assumed to have already authenticated in order to have an active web session, so there's no need to re-gather a username/password (or whatever user auth step the LMS uses) to re-confirm identity.
The user may already have confirmed access for the application and dismissed the confirmation step with "don't ask me again". If the user has confirmed access with "don't ask me again" this choice will get remembered, even if the user tokens get expired due to password change or access revocation by an admin.
If you explicitly log a user out of their LMS session, and then test the client app, this should indicate to you visibly whether the re-authentication step is actually taking place (the user's browser will then get directed to the login process for the back-end service).
Note that, although a user password change or access revocation by an admin can remove the recorded user Id/Key pair associated with an application, it does not remove the record of the confirmation form having been dismissed with "don't ask again". Currently our system does not expose a way to reset that confirmation state.
If after considering these points you feel you still have an issue, I would encourage you to open a support incident through your organization's approved support contact, or your account or partner manager. Desire2Learn takes security related reports quite seriously, and if you've uncovered an issue that hasn't yet been addressed, I would encourage you to report it as a defect.