问题
This is an existing system with a login screen, now I expose some services as REST service. I build an authentication-token login system for this Rest(jersey) service. User sends username-password then server returns a token calculated as;
sha1(username+password+currenttime(or any random number))
User will use this token to login the app for further requests. And server keeps a copy of the token in the database with a time stamp and user id, and logins that user if timestamp is valid.
Considering HTTPS will be used, a few questions;
Does everything looks ok in my design? (generation of hash and the way I save in DB) Looks to me the weakest point is I need to send plain username and password over POST request, but since it is HTTPS I guess it will not be a problem.
another thing, for the first request, since it is an existing system I dont have the user passwords in my DB but keep a salted hashed version of them. Which I guess not safe to give all the clients this salted algorithm to send me a hash of their passwords so I compare hashs but not the passwords. does this make sense=
回答1:
1/2- I'd suggest POSTing the username/password to the server, which can then return the token in the body. Makes most sense to me: you're not actually storing much on the server, so PUT would be wrong, and a query parameter doesn't make sense at all. Headers are supposed to be somewhat consistent across requests, so they don't make sense either. When actually communicating using the token, feel free to use a query parameter or header. Doesn't really matter.
3- I'd pick a slightly longer hashing algorithm (sha256?)
回答2:
I would typically pass the token in an HTTP header.
Whether you use POST or PUT shouldn't matter.
Something else I would suggest to help prevent replay type attacks would be to include a nonce (ever increasing value) with each POST request. The server would then track the last used nonce and prevent any requests that use a previously used nonce from executing.
来源：https://stackoverflow.com/questions/14041496/rest-token-authentication-with-http-header