Simple token-like authentication

Question

Does the following authentication system seem reasonable:

1. Client calls the login end point with a user name and password to the main server. The main server sends this off to another authentication server (which will receive no further mention), which returns a yes/no if this is valid and a user ID that the main server is aware of. If yes, generate a random token (using some crypto library that spits out random strings), and store the hash of this (using PHP's password_hash()) and an expiry 12 hours from now on the user record. Return the token to the client.

2. Client now adds "Authorization: Token TOKEN+HERE+ABCD1234" to their requests to other endpoints. The server ensures that the hash of the token in the auth header matches the one in the database (using salts through PHP's password_verify()), and that the expiry hasn't been hit. If it doesn't match, or the expiry is exceeded, then send back a 401.

Seems at least as secure as basic HTTP authentication, which just has the base-64 encoded user:password in the header? The reason I'm considering this scheme over basic is that the main server won't store the username/password that the authentication server is using to log in.

What am I forgetting? Is this grossly insecure?

Answer 1

Your scheme is not that different from the standard server-side sessions where SESSION-ID is normally nothing more than a random token and stored on the client side within a cookie, with 2 improvements:

• Instead of a cookie you would use Authorization header to deliver the token. This acts as a CSRF protection.
• You would hash a token on the server-side. This helps against session hijacking in case someone gets access to your token-store on the server-side.

Answer 2

If you see the oAuth process of Google then you will get idea of how Authorization works for them.

They have different servers for Authorization and API calls. User sends authentication details to Authorization server and receive a code. Google is having process of taking user consent to access details but you can skip this process to take consent and just return code on successful details.

This code can be further used to get the Access Token from the API server. So your first request to API server would be to get the Access Token. Google is having facility to refresh your Access Token as well.

And all subsequent request to API server must contain Access Token. So you seems to be missing this Code exchange process to make it more secure.

More info: https://developers.google.com/identity/protocols/OAuth2