5 ms·
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming int
by jethroalias97 13y ago
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming into any API server. So in most cases we're not avoiding cookies and sessions just for the sake of it.
- shaydoc 13y agoYou 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.