Question

I’m implementing a set of RESTful services for some developments and one of these is an authentication service.

This authentication service authenticates two kinds of identities:

• Applications. AppKey-based authentication so clients must register for a key in order to access to the rest of the services.
• Users. Well-known credentials (user+password)-based user authentication so humans and machines can work with these RESTful services through client applications.

These RESTful services are stateless.

When a client application authenticates against the authentication service, or when a human or machine authenticates as an identity using credentials, both operations generates an AppToken and UserToken respectively.

These tokens are a salted hash so subsequent requests to the RESTful infrastructure will be authenticated without sharing AppKeys and credentials.

Form the point of view of a fully stateless approach, these tokens should be stored no where in the service layer but in some kind of client-side state (f.e., a Web client would store it using HTTP cookies). This is how my current implementations are working right now.

Because re-authenticating each request using these tokens and let the service layer receive the token coming from the client so it can compare what token comes from the client and check if it’s a valid token re-generating it in the service layer and compare with the one owned by the client is too expensive, I’ve implemented a service layer AppToken and UserToken, both having an expiration date and an owner (the application or user for which the token have been created for), in order to check if the token coming from the client exists in the token store.

How does clients interactively unauthenticate? Just dropping client-side security state. If it’s a Web client, it drops the authentication cookie and just refreshing the page, client detects no authentication cookie and user is redirected to the login page.

From the point of view of RESTful services, this is a stateless unauthentication: clients aren’t aware about the trick of having a service layer pseudo-authentication state. It’s just a service implementation detail – a performance optimization -.

I’m not going to list the pros of stateless services because I’m absolutely sure that this approach is the way to go, but I find a problem: stateless authentication/unauthentication means that clients don’t notify server that they close their session, so the security store ends with a lot of useless records.

This isn’t a great problem if service clients are ones that would have limited time sessions (f.e., 1 hour, 3 hours, a day…), but what happens if an user must be authenticated forever (8 months, a year)?. How do you distinguish what’s an an expired token?

There’re some approaches in order to solve this situation:

1. Whenever the service layer receives a request, it updates token expiration date, so an automated process may drop those tokens that have expired defining an arbitrary expiration of tokens (f.e. 24 hours).

2. Compromise stateless nature of the architecture and let clients notify service layer that they don’t want to be authenticated anymore, so service can drop the associated token to the client session (But wait… what happens if client closes a Web client? User will never actively notify service that the token must be dropped… So… Zombie tokens are there yet, so an automated process should drop them, but… what’s a zombie token? I don’t like this approach).

3. Completely stateless authentication, no store, per-request authentication.

This is the question! What’s your suggested approach – even if it’s not 1., 2. or 3. – and why?

Thanks for this long reading – I honestly believe that question’s conclusions are going to be extremely useful to anyone -!

Answer 1

Chosen approach: COMPLETELY STATELESS AUTHENTICATION AND UNAUTHENTICATION

Finally, I got a conclusion and a protocol in order to switch to the whole completely stateless token-based authentication and unauthentication.

How to achieve it?

First of all, this is what you need to have stateless token-based authentication for applications (but user authentication would work in the same way, excluding this inventory):

• An application registration system. An application is an access to your services. It’s “your application accessing some services on the net (intranet, internet, cloud…). This is creating application keys (skip this for user authentication).
• A server certificate so client to service connections are encrypted by using HTTPS/SSL.

This is the flow of authenticating an application:

1. Client sends an authentication request to the authentication service. This request must include the Application Key (AppKey).

2. Authentication service receives the previously sent request.

3. Now authentication service creates an application token (AppToken), which is a self-describing concatenation of the necessary information to track a concrete authenticated client to the services relying on authentication service.

4. AppToken is a compound string (this composition can be an object serialized using JSON) of:

   • An application hash (*a SHA – or other – which is the result of concatenate some application info. This is info will be a service secret + Expiration date (which is part of the token itself). Why Expiration date?. Imagine that a man in the middle or something can break security and modify token’s expiration? When encrypted token gets decrypted in order to authenticate a request, the result of hashing again the expiration date + AppKey will no longer produce the same hash, so token gets invalidated.
   • Issued date. Current UTC Date+Time when creating the token.
   • Expiration date. An UTC DateT+Time on which the token will be no longer valid.

5. Authentication service encrypts step #4 result (the JSON-serialized object). **Use AppKey as the key or password for a symmetric cipher. In my case, I’ll use Rijndael for that.

6. Subsequent request will include this token in order to avoid sending plain text credentials. Those request will always include the AppKey too, so authentication service will be able of identify what application is trying to authenticate the request.

7. After some time, a token becomes expired or invalid, and client requests for a new AppToken. Or the client was closed by the user and there’s no persistent storage that would save security tokens, so next client session will request new ones when needed.

---

Some hints and details about .NET implementation of such authentication method:

• I’ve used System.Security.Cryptography.RijndaelManaged class for symmetric encryption. Both AppKey and AppToken (and in case of token-based user authentication it’s almost the same solution) are generated using RijndaelManaged class.

• Encrypted text is converted to an HEX string. This is sent with the authentication response. In our case (a RESTFul API), the HEX string representing the AppToken will be sent as a response header. Whenever a request includes this HEX string, authentication process will reconvert it to the original encrypted text, and later it’ll get decrypted in order to evaluate if the token is valid.

---

Thanks Henrik for your effort. I’ve taken some of concepts in your own answer and I’ve mixed them with my own conclusions.