I'm currently designing a REST-API with the following properties:
- Backend for a single page application (Later Apps)
- Integrated user database for each instance
- HTTPS/TLS only
- Authentication with a username / password combination
My current approach for the authentication process is the following:
- (Client) POST Username&Password to
/api/users/action/auth
- (Server) Authenticate User, Generate token, Send token to client
- (Client) Use Authorization-Header with token for subsequent request
- (Client) DELETE
/api/users/action/auth
to invalidate the token
The token will expire after some idle time.
I've chosen this design because I don't like the idea of storing the plain authentication data on the clients device.
Reading a lot of other questions and articles on this topics I don't think this approach is the best. The following questions arose:
- Does the token generation and usage for subsequent requests violate the stateless-principle of REST?
- Is this procedure secure? (XSRF?)
- Is there a better design approach? I thought OAuth may be an overkill
EDIT:
Regarding 'secure':
The application will contain a lot of sensitive information so security is quite important. Assuming the secure usage of HTTPS (only TLS, strong DH-Group, No export mods etc.) are there any easy to exploit security flaws in this approach?
Regarding 'better':
I choose this model because it's easy to implement on both sides. I put a thought into using HMAC(token, 'POST' || '/api/resource' || timeInterval)
as token for each request, my conclusion was that this would add unnecessary complexity without improving security. (Already using TLS)