My idea is to use encrypted tokens - where upon authentication (with username and password), backend would encrypt user_id, timestamp and an SHA-256 over those, base 64 encode it and return to the client as an access token. This way I can eliminate the need for a persistent token store.

This is similar to the scheme described in this article (there are some differences though).

The logic I would like to have, is that when token is used constantly (i.e. longest interval between subsequent API calls is no longer than N), user shouldn't be prompted for the reauthentication.

The issue is that encrypted token's validity cannot be extended, since changing the timestamp means the value of the token changes.

I can see the following solutions:

1) Each time token is validated, issue a new token and return in to the client. On every request, client would forget about the previous token, and store the new one instead.

  • + solves the issue
  • + logic on the client is rather straightforward
  • -- for one user, multiple tokens would be valid at the same time

2) Do implement an API endpoint which would accept an expired token, and would issue a new token in return. This endpoint would have some configurable value M, so if token is expired by more than M, new token wouldn't be issued.

  • + solves the issue
  • + for one user, only one token would be valid at the same time
  • -- logic on the client is a bit more complicated - needs to refresh token.

Is there another solution, based on encrypted tokens? (I know we can get around that issue with regular, persisted tokens).

  • 1
    You may want to consider changing the title. You are proposing using a cryptographic hash SHA-256, which is not an encryption algorithm.
    – rook
    Feb 4, 2015 at 17:27
  • In the first sentence I mentioned the whole thing will be encrypted before doing a base 64
    – kamituel
    Feb 4, 2015 at 20:35
  • in the link you provide, the author uses a different process to create the cookie: create a hash of the ID and date, THEN encode it, followed by encoding for web (base 64). I think you created some confusion when you changed the order in your question.
    – schroeder
    Feb 4, 2015 at 21:06
  • I didn't change the order (I mean I didn't edited the question). Anyway, to clarify, what I'm doing is that: AES(user_id + timestamp + SHA-256(user_id + timestamp) )
    – kamituel
    Feb 4, 2015 at 21:58
  • 1
    You may want to look at this question: Generating authentication token from PHP sessions Feb 5, 2015 at 10:22

1 Answer 1


You could encrypt the userid:timestamp:hash, base64 it, and send it as a cookie. On every token validated, recalculate a new one with a new timestamp and send back.

Record every invalid token for a user, and invalidate every token coming for the same user and same IP address for a period. This complicates the life of anyone trying to bruteforce tokens.

You don't have to care too much about a user having more than one valid token, only that you are talking to the same user. If a user opens multiple tabs on your site, multiple valid tokens will happen.

  • Actually, the token is encrypted. So I'd get a user ID, timestamp and a hash, encrypt it and only the base 64 encode it
    – kamituel
    Feb 4, 2015 at 20:34
  • I read it too fast... I edited the answer.
    – ThoriumBR
    Feb 4, 2015 at 20:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .