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).