Simple similar authentication
Is the following authentication system sane:
-
The client calls the endpoint login with username and password to the core server. The main server sends this to another authentication server (which will not be mentioned anymore), which returns yes / no if it is valid, and the user id that the main server knows about. If so, generate a random token (using some crypto library that spits out random strings) and store a hash of that (using PHP password_hash ()) and expire after 12 hours in the user's entry. Return the token to the client.
-
The client now adds "Authorization: TOKEN + HERE + ABCD1234" to its requests to other endpoints. The server makes sure that the hash of the token in the auth header matches that in the database (using salts via PHP password_verify ()) and that the expiration date has not been successful. If it doesn't match or the expiration date is exceeded, send back a 401.
At least it's as secure as basic HTTP authentication, which only has a base-64 encoded user password: password in the header? The reason I am considering this scheme versus the basic one is that the main server will not store the username / password that the authentication server uses to log in.
What am I forgetting? Is it really unsafe?
source to share
Your schema is no different from standard server-side sessions, where the SESSION-ID is usually nothing more than a random token and is stored on the client side in a cookie with two enhancements:
- Instead of cookie, you must use the authorization header to deliver the token. This acts as a CSRF protection.
- You will have a server side hash token. This helps to avoid hijacking the session if someone gains access to your server-side token store.
source to share
If you see the oAuth process on Google, you will get an idea of how authorization works for them.
They have different servers for authorization and API calls. The user sends authorization data to the authorization server and receives a code. Google has the right to obtain user consent to access the data, but you can skip this process to obtain consent and simply return the code for successful information.
This code can additionally be used to obtain an access token from the API server. So your first request to the API server should have gotten an access token. Google has the ability to renew your access token.
And all subsequent requests to the API server must contain an access token. So you feel like this code sharing process is missing to make it more secure.
More information: https://developers.google.com/identity/protocols/OAuth2
source to share