4 ms·
You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key. When the server receives the request it can
by shaydoc 13y ago
You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key.
When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext
- gizzlon 13y agoDoesn't this open you up to replay attacks though? Since you can't store that a token was already used..
- TylerE 13y agoSure you can. Just include a timestamp, and expire the token, at, say, time + 90 seconds, or whatever makes sense for the application.
- gizzlon 13y agoI get that you can expire it, and that helps, but it's not the same as use-once. Of course, just using a timeout is probably fine in many cases, especially if it's used with SSL. But replay attacks are still possible since there's a windows where it can be re-used.
- shaydoc 13y agoReplay attacks are always gonna be possible unless you use a one time token or signature, thems the break's..., unless you wish to get into the something you have and something you know model. How can you do a use once token making concurrent requests without a strong authentication mechanism client side such as issuing private keys to clients....and all the PKI admin overhead. I think its safe to say, that a restful api should be stateless, and bottlenecks such as session state are not necessary.
- gizzlon 13y agoI'll take that as a "yes" ;) AFAIK, neither signatures or "something you have, know" alone fixes replay attacks. Since this is a well known problem in cryptography, many solutions exists. All of which are probably overkill for this use.
- shaydoc 13y agoAt least with the use of a digital signature and nonce you can guarantee that the request hasn't been tampered with!
- shaydoc 13y agoI failed to say that your token context should have a "time based expiration", in that a new token is reissued periodically as defined by you and your needs. I would refer to the ASP.NET Forms Auth mechanism with its sliding expiration.