Authentication token storage recommendations

I have a case where non-interactive devices have to push data to a server periodically over HTTP. I am thinking of taking an auth token approach to verify the validity of requests from these devices.

First the device wakes up and initiates a ssl connection and submits its credentials to the server; the server verifies the credentials and generates a SHA based token, based on the credentials + some random input, and sends the token back to the device

This token must be present as a header in each http request that the device sends up. The server will use a servlet filter that looks for this header and filters out messages that don't have it.

There is no sensitive information transferred, I just want to make sure that the device talking to the server is a valid one, and not someone trying to mess around with invalid data. (Wannabe hackers, script kiddies etc..)

The token needs to be stored somewhere where multiple 'nodes' can verify that the request is valid - where do you recommend doing this ?

I can think of 3 approaches

1) Have a separate web service that maintains t开发者_如何学Gookens and does the authentication ( I cringe on the performance overhead of this for each request)

2) Maintain a Set of authenticated token in the Session, and let the servlet container take care of it using the built in clustering support (Not sure if this is the most fool proof way )

3) Use a database to store the tokens and verify it (Considering Redis for this)

Also, I think this approach has a vulnerability of allowing man in the middle attacks, but since the client sends data only for a few minutes I am taking a chance, any better approaches would be welcome.

My opinion:

1) Have a separate web service that maintains tokens and does the authentication

If it's about performance and you have to maintain a lot of devices, I agree that this may become a performance bottleneck.

2) Maintain a Set of authenticated token in the Session, and let the servlet container take care of it using the built in clustering support.

Personal opinion: never rely on sessions in a systems integration scenario. Second, in clustered environments you have to replicate session state between members. Although the container takes care of this it will have impact on performance as well in case of in-memory replication.

3) Use a database to store the tokens and verify it (Considering Redis for this)

If a database is already in place, do it here

Alternative: Use a symmetric hashing approach. After the device authenticated itself return a one time token (digest) each server node can verify independently (based on certain criteria, e.g. a password). "Shared nothing".

BTW: no question, the transport has to be secured (TLS/SSL).

I think that the 1st solution will be the most scalable and flexible. Try OpenAM with SAML. This is out-of-the-box solution. It has such a filter and can manage repository with such data. A more bulletproof solution could be based on WebSphere DataPower and SAML. If SAML is too complex you can use lightweight, custom solution, but IMHO the 1st idea will be the best.