Reputation: 6122
I'm building my first mobile app in which users can login. My app talks to webservices on my site's backend. Users can login via either Facebook or an email/password combination.
I'm used to ASP.NET forms authentication for my website, but for mobile apps: what is the adviced way of storing the logged in status?
How do apps like Facebook/Uber/Gmail do this?
Validate on every request? Is there a timeout which is kept on the server (e.g. with 60 minutes of inactivity require re-login).
Or is there simply a local cookie in which a flag loggedin=true
is set and the users' username is stored? (possibly again with a timeout)?
Upvotes: 1
Views: 978
Reputation: 3523
I don't think there is a standard way of doing this, but for reference, I had asked a very similar question specifically for Google+ Login, and you can see the answers here:
How to correctly use Google Plus Sign In with multiple activities?
Basically, you can either create a base activity that your other activities extend from, that has the auth check functionality. You can also move this functionality to a fragment or you can implement a service that handles all of this.
I think it depends a lot on your specific use case.
Let's say you really don't care if they are logged in or not all the time, but only when you have to authenticate a valid user right at the begining, that one could work with a Boolean flag, but if your app does something a bit more sensitive for example, you might want to validate that the user is logged in, every time before any user action.
Do you have more details on what exactly do you want to restrict/protect behind your authentication logic?
Upvotes: 1
Reputation: 93542
A 128 bit or more cryptographic strength random token is generated server side and stored in a cookie client side. That token is associated with the user and the IP it was made from.
All requests are encrypted (so the token can't be sniffed). When they make a request, they send you the token. You then check and see what user is associated with that token in the db, and make sure the IPs match. If they do and the token is associated with a user, treat the request as coming from that user. If not, its an invalid request.
A timeout is not necessary, but does provide additional security. Logging out is as simple as removing the token in the db. Additionally, a client making too many invalid requests in a short window should be banned.
Upvotes: 1