How to make user token and where to store it (server side)

Question

I'm building an iPhone application and don't want the user to have to sign in every time they open the app, so I want to use user tokens. My question is is there a commonly accepted way to create user tokens? Also do I store the token in the database along side the username/password/email, do I create a new database just to hold the tokens or do I just read the token when the HTTPS request comes in and tell whether it came from me or not? Thanks!

Edit: I plan on using JWT to handle authentication, but thanks for the input!

Answer 1

These user tokens you need sure sound a lot like cookies ;-)

Handling cookies is a hairy issue, and there's several approaches.

A usual one is a simple random string of characters. The user keeps it and you validate it against a hash in your database. Leaking this string would be really bad, be careful.

There's a common variation of this one: instead of a random string encode the user id and other session data and sign it (cryptographically), when the user presents it validate the signature and use the data from the cookie itself. This saves you a trip to the database.

A favorite of mine for native clients: HMAC tokens. You share a secret key with the client. The client uses this key to hash a nonce and a timestamp and sends the hash, the nonce and the timestamp to the server. The server performs the same calculations to validate the value received by the client.

This way the secret is sent over the wire only once, reducing risk of leakage. Well implemented it also reduces risk of replay attacks.

There's others. Perhaps you framework already supports one of them, in that case you might be better of with it.

Evaluate the different alternatives and if you need help deciding ask us.

Answer 2

The magic words you want to look at are OAuth2 and/or OpenID - OpenID is really what you are looking for, as it is authentication (who is this user) focussed, rather than authorization (what can this user do) focussed as OAuth is. Many people use OAuth for authentication (by asking the OAuth provider for an email address, say, and using that). Both work by providing a token back, with appropriate expiry and so forth.

By using a standard, you suddenly have a really good option - why keep track of users, passwords and such yourself? It is HARD to do securely, makes you a target, adds lots of features you need - expiry, lockout, reset. Why not skip all that and just use an OpenID/OAuth provider like Facebook, Twitter or Google? That's all the 'sign in with Facebook' things you see on apps - it makes everyone's life easier. Users don't need to make up another stupid password and you don't have to worry about storing it.

If you don't want to do that (for some reason) you can still leverage the standards - just make your server an OpenID Identity Provider and use their scheme for tokens, etc.