OK...so I have a swift app that connects to a PHP backend. The user logs in, it stores a session on the server and sets an encrypted cookie in the cookieStorage on the app (I also store that cookie in keychain since cookieStorage can be volatile from what I'm told). I also store the username and password in keychain as well.
The session on the server expires after a time of non-use (let's say 30 days), but if the user comes back, the session renews itself if it's under 30 days old. So for example...lets say I don't come back for 15 days...my session is now reset to 1 day old and again has 30 days to expiration...however, if I come back on day 31, I have to re-login on the web app.
There are several viewcontrollers in this app that require the user to be logged in (a couple are uiwebviews that use the cookie to access the data on the server...those aren't a problem as they handle the sessions like a champ by default). The native views (tableview, etc) that require the user be logged in however are a different story.
Currently, on login, I set a switch in NSUserDefaults that the user is logged in...in didFinishLaunchingWithOptions, I just check to make sure the user is logged in...if they are logged in, we move them into the "private" area of the app, if they aren't logged in, we move them to the login screen (or signup screen).
All of this is fine and good...but with the sessions expiring on the server, I was wondering what is an appropriate way of handling this in an iOS app? I want them to stay logged in until they choose otherwise, but if the app stays closed for 31 days, the session on the server will no longer be valid. I was thinking that I could set a date in UserDefaults (last time app was opened) or something like that, and if they haven't opened the app in over 30 days, then I could just use the username and password stored in keychain to re-log them into the PHP backend and refresh their session and reset the stored login date (if the password is no longer valid, I would of course redirect to login view).
Is there a more appropriate way to handle this in an iOS app or does that sound like a valid approach? Should the date/session check be in didFinishLaunchingWithOptions and also in applicationDidBecomeActive ?
First, don't store anything that has to do with the login state in the userDefaults it's not secure.
Second, since you are storing the username and password in the keychain, why don't you just check the keychain and log the user in every time they open the app. This will give the user a persistent login until they log out then you can clear the keychain. Also this will give you another analytic point you can store in your database so you know every time the user opens your app.
Is there a reason you want to have a 30 day expiration?
Related
We have created an Identity server 4 application for single sign-on in Asp.net core 2.0. We use the Microsft Identity framework for login and account related pages.
The client applications are created using .net FW 4.7.1 in MVC 5 which are then connect to identity server for single sign-on purposes (used Identity server 3 in client application).
We have a requirement wherein allow users to log in to the application only from a single device at a time. To achieve this, on user login, we create a unique LoginSessionId and store it in DB. On logout, we just make this session-id null.
If someone else tries to login with the same user on another device, we just check if the LoginSessionId has value. If yes, then we give a message informing the user that he's already logged in on another device and if he wants to kill the other session. If he says yes, we let him login and reset the LoginSessionId with a new one. As for the first device login, we have a check-in place to log out that user if his current LoginSessionId does not match the one in DB, so he gets logged out.
We have also set the AccessTokenLifetime and IdentityTokenLifetime of the identity server-client application to 24 hours. Here is the problem we're facing:
When the 24 hours are up after user login, the user gets logged out since the Token must have expired. But the LoginSessionId mentioned earlier is not reset. Thus when a user tries to log back in, we end up showing the message of another user logged in, which is not really the case. Question is,
Is there is any way to raise the token expiry event so that we can clear the LoginSessionId there?
Is there any common place where we can identify the various reasons due to which user gets logged out. Like was it due to token expiry, or because he was idle for a long time (sliding expiry I think), or if he clicked logout himself etc.
What is the max value that we can set for AccessTokenLifetime and IdentityTokenLifetime.
One needs to implement IEventService and IEventSink in Identity Server 4 to get those evnts.
for more details, you can refer to this link.
link
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.
I'm using firebase authentication for my app and I have the users sign up, login, and log out all set up and going. However, I'm a little confused on how to manage the state of the users login status. Currently, if a user is logged into the app, but doesn't use the app for an extended period of time, firebase doesn't recognize them as logged in. I'm looking at the documentation and the approach is a bit unclear.
Should I be storing a FIRAuthCredential every time the user logs in, and then call reauthenticateWithCredential using that credential?
Firebase Auth only requires recent sign-in for sensitive operations like: deleting a user, changing a user's email or password. These are for obvious reasons. You want to make sure it is the same user before making such sensitive changes. Otherwise, the user is considered signed in indefinitely by the Firebase Auth backend (your assumption that "firebase doesn't recognize them as logged in" is not correct). Of course, a developer may also require re-auth before other operations like updating credit card, shipping address, etc. A developer would check the auth_time on the Firebase ID token. Only in such cases would you re-auth. You should never store credentials such as password on the client to avoid prompting the user to reauthenticate. It is needed to protect the user's account.
yes I think that is going to be right approach or second approach you can try is like when a user press login button instead of directly calling Authenticate User put a check in which last login timestamp value will be stored when user login compare timestamp value and then perform selected operation as you want . NOTE - you will be required to check weather user exist or not , but I think first approach will be better as if you had noticed in many Social apps like kik it ask for reauthentication after a long period of time but first it authenticate user instead of displaying home screen it take to reAuthenticate screen
How do I make that Firebase will logout from all accounts when the user is change its Password.
So if user have 2 devices that are connected to the same account, and one device change the password of the account, the other device will disconnect. The idea behind it is that if user's account is hacked, they can change their password and disconnected the hacker from their account.
You have to logout and login regularly to check if the credentials save on the device are still valid. Depending on your security requirements you have to decide how often you do this. The most restrictive way would be before every Firebase call, the least restrictive would be when your app becomes active. I would:
introduce a last password check Date entry in UserDefaults
introduce a timeoutconstant (5 minutes)
save Date() when logging in
write a wrapper around calls, that compares the time interval in between now and last password check with timeout
if timeinterval > timeout, re-login
I've developed an app where in the entered username and password by user is saved using NSUserDefaults.
Any request from user for any service needs this username to be sent. So using NSUserDefaults I'm sending username for each request. Still the iPhone app is logging out without clicking the logout button and starts from the beginning asking for username and password.
As facebook app and others remains once logged in. Please let me know why the app is logging out frequently without clicking logout button.
Thanks in advance.
On launch check if there is a saved username and password, if so use them. When the user enters these save them.
You need to look at the page source from the server for the form request of the credentials, create the form response with the credentials and post it. This is doable and actually not very hard. On one project I did this for auto login and respond to many form requests so the user never saw them.
Do not use NSUserDefaults for credentials, it is not secure. Instead use the Keychain, it is secure.