In restful application, for some reqirements,e.g. On client side,for the same user can using only one access token at the same time and user can get new access token via login successfully.if logined twice,the user will got two different access token say it's access token A and B.In the backend,when user still use token A to talk with server, it should be invalid and the latter B should be valid!How to implement this without using cache framework or db? Additionally in the backend, i don't want store any access token, the access token contains simple user info and timestamp etc, which is a string encrypted with aes and encoded with Base64.
2 Answers
Unfortunately, you won't be able to do what you want without persisting the tokens.
I answered a question related to token based authentication before. Maybe you can get some inspiration from there.
Different types of tokens
Basically, a token can be opaque (which reveals no details other than the value itself, like a random string) or can be self-contained (like JSON Web Token).
Random String: A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web Token (JWT): Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords on it) in a payload, which is a JSON encoded as Base64. The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server. You won't need to persist JWT tokens if you don't need to track them. Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To find some great resources to work with JWT, have a look at http://jwt.io.
Persisting tokens
There are many databases where you can persist your tokens. Depending on your requirements, you can explore different solutions such as relational databases, key-value stores or document stores.
Just remember to remove old tokens in order to prevent your database from growing indefinitely ;-)

- 1
- 1

- 124,154
- 35
- 280
- 359
-
A few days later,it seems no better solution..Do i have to accept your answer? +_+ Before the question i have tried to know jwt, but it seems a little complicated.. – qfrank Dec 11 '15 at 06:38
-
@user2262920 I hope my answer is useful for you. If it answers you question, you can consider accepting it :) – cassiomolin Dec 11 '15 at 06:42
The access token must be send in every request in Authorization header. For every user you store his access token. So access token arrives, you check its value and find which user it is. If you do not find access token, user is not authorized.
So basically when you generate new token, you replace the old access token for given user, when old access token comes you are not able to recognize it (it is not stored anywhere), therefore it is invalided.

- 22,239
- 9
- 44
- 87
-
thanks for reply!i edited my question again, i don't want store any token in the backend.. – qfrank Dec 07 '15 at 08:45
-
@user2262920 - If you do not store any token or information about users, you cant authenticate them. – libik Dec 07 '15 at 08:49
-
@user2262920 - well ok, you can bundle info inside the access token with RSA for example, but you do not have any control over it (if it comes, it comes, the invalidation etc. is not possible) – libik Dec 07 '15 at 08:53