Developer thoughts: Building the authentication mechanism

[gene]

One important part of our game database will be:
Every registered user has to authenticate against our server. This way the user can edit his profile, his collection etc. And he can add or edit game information from our database.

During the next weeks and months I want to implement the authentication mechanism for Oregami. As we are going to use a REST based architecture, a session based approach cannot be used. Instead of this we are going to implement a token based authentication meachanism.

A nice overview of the advantages of a token based approach can be read here, let me quote a few things:

• Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX calls to any server, on any domain because you use an HTTP header to transmit the user information.
• Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contanined entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.
• Decoupling: you are not tied to a particular authentication scheme. The token might be generated anywhere, hence your API can be called from anywhere with a single way of authenticating those calls.
• Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a secure API (you have to deal with cookie containers). Adopting a token-based approach simplifies this a lot.
• CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to <iframe> your site, generate a POST request and re-use the existing authentication cookie because there will be none).
• Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database) is likely to take more time than calculating an HMACSHA256 to validate a token and parsing its contents.
• Standard-based: your API could accepts a standard JSON Web Token (JWT). This is a standard and there are multiple backend libraries (.NET, Ruby, Java, Python, PHP) and companies backing their infrastructure (e.g. Firebase, Google, Microsoft). As an example, Firebase allows their customers to use any authentication mechanism, as long as you generate a JWT with certain pre-defined properties, and signed with the shared secret to call their API.

Doesn't that sound great?

So I am going to create a solution based on JSON Web Token. I already have my local server application that creates such a token with the help of this library. I also found the project dropwizard-auth-jwt which gives interesting insights in the integration of JSON Web Tokens in a Dropwizard application.

[gene]

The first iteration was successful! Not yet in the Oregami server application, but in the ToDo server app. But that will only be "copy work".

When you call this adress:
http://dropwizard-guice-jpa-seed.oregam ... rate-token
the server generates a JSON Web Token like this:

Code: Select all

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE0MTY1MjAxMzUsInByaW5jaXBhbCI6Imdvb2QtZ3V5In0.H8rGtx2fnwMMAYZwweoOPgE4f58ipOrPC_UkWIU8oilnMmBLIoRzNSivh-vRhzpO-7fGsoLW8dHHXPPeYKpLYw

Copy and paste it here and you see what's in it!

Of course in "reality" (this means later when it's done completely) the token will only be generated, if the given credentials (username + password) are valid. Then the browser will store this token in its localStorage or sessionStorage and send it through the HTTP authentication header with every request. The server checks (with the help of the secret key) if the token is valid (this works without database access!) and either returns "ok" or "error".

That's the plan for the Oregami authentication. I will continue to work on this during the next weeks!

[gene]

I managed to implement a first prototypical authentication for the ToDo app.

On the server side, it's a RESET POST call against http://dropwizard-guice-jpa-seed.oregami.org/jwt/login. If the values for the parameters "username" and "password" match, the server returns a JSON Web Token.
On the client side, there is a login page where you can enter the username and password. Working exmples are "user1/password1" or "user2/password2". These create JSON Web Tokens on the server, other inputs create an HTTP 400 ("Bad request"). After a valid sumbission the client stores the token in the browser's local Storage. ToDo: The client must send this token automatically with every request, so that secured resources on the server can only be read/written when you are authenticated.

Please note that without the use of encrypted connection (SSL) this is absolutely not secure. Later we will of course use secure SSL connections so that nobody can spy on your password and the tokens.

And the same procedure as every post: I will try to transfer these mechanisms to the Oregami client & server apps as soon as possible