Implementing a token authentication

Question

Which are the steps must I follow to implement a token authentication in my web page?

Any summary or links will be appreciated.

I want to implement similar to Facebook or Google, first time client loggin and receive token and then use it in next actions. I read also about OAuth but I don't want to give access to my application from 3rd party.

---

Thanks for the long response and it seems clear to me I need to read more about this.

What I want is to know the "steps" to implement a basic web application that uses token authentication. That is user logging once and then can make some actions: add content, edit, etc.

I know what I'm saying is similar to a session, where server adds a SESSION_ID on the HTML header and later request are identified and associated with that session. I read sessions way isn't good to scale so I want to implement a similar system like gmail or facebook before they go to OAuth. Probably I'm talking about something similar to oauth (i don't read in much depth) but witj two-legged instead three-legged.

Answer 1

You should think about your requirements, pick an appropriate protocol and some decent piece of software that implements it.

It's really hard to say more without more details:

• are you talking about authentication for one or for multiple web applications? do you need single sign on between different web applications?
• should all user data be stored on your server or should user be able to login e.g. with the google account?
• should the token contain informations about the user?
• on what platform are your applications developed?
• what authentication method should be used?
• do you want to realize a portal?

There is a really wide range of protocols and tools which might or might not fit to your requirements:

http://en.wikipedia.org/wiki/Category:Authentication_methods

http://en.wikipedia.org/wiki/Category:Identity_management_systems

I personally like CAS ( http://www.jasig.org/cas) for token-base SSO between multiple web applications. It's Java based but also has some support for PHP and .Net.

OpenID is fine, if you want to allow users to login with their Google, Yahoo, whatever account (configurable...) and don't want to store user information by yourself.

Kerberos/SPNEGO is the way to go if you want to haven integrated windows-sso for your corporate intranet applications.

For university applications SAML/Shibboleth probably is best. Outside universities it's somewhat less popular, probably cause it's a fairly complex protocol.

Oh and I almost forget: Most of the web frameworks/standards have there own version of plain-old "form based authentication". Where a user goes to a login form enters its username and password. Both are with or without SSL transported to the web/application server. The server validates it against some kind of database and gives a cookie to the user, which is transmitted and validated every time the user sends a request. But beside all this shiny protocols this seems to be pretty boring :-)

And before doing anything with web authentication, you might think for a moment about web security in general ( http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf) and what you can do to not make it even worse on your site ( http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf).

Answer 2

see your point.

On the protocol level a very simplistic token approach is HTTP Basic Authentication. But this often doesn't fit, as there is no logout function etc.

A custom, simple cookie based approach can for example look like this:

• The server generates some kind of secret (a value that is hard to guess)
• When a user tries to access a protected resource, he is redirected to a login form
• after successful authentication he gets a cookie. This cookie contains three values: username, timestamp and a hash of {username server-secret timestamp}.
• with every user request the server recalculates the hash values and compares it to the value which the client sends in its cookie

(needs more consideration of: httponly and secure flag, transport layer security, replay attacks etc)

Amazon S3 stores its authentication token in an HTTP Header and uses HMAC for calculating it. It's described here: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (Not necessarily recommended for using with a browser based web application)

If there is a book about REST anywhere near you, you may look if it has a chapter about authentication. Probably things are much nicer explained there than here :-)

There are some frameworks which are capable of doing this kind of authentication. For security reasons it would make sense to check them first before implementing your own stuff.