Introducing Refresh Tokens with Rotation for a Seamless User Experience

[abdullah-alnahas]

This pull request enhances the user experience by implementing refresh tokens with rotation. With this new approach, users are no longer required to log out and log back in when their login token expires. Instead, the front-end seamlessly handles refreshing the login token using the updated refresh_token API.

Here's an overview of the new authentication workflow:

1. (Front-end) Login request with valid credentials.
2. (Back-end) Login and refresh tokens are returned in the response.
3. (Front-end) Securely stores the refresh token.
4. (After some time, the login token expires)
5. (Front-end) Sends a request to an endpoint requiring authorization.
6. (Back-end) Responds with a 401 Unauthorized status.
7. (Front-end) Sends a POST request to the refresh_token endpoint with a valid refresh token.
8. (Back-end) Generates a new pair of login and refresh tokens, and overrides the old tokens.

Please note that the refresh token is long-lived, allowing users to maintain their sessions without the need to frequently re-authenticate. This new workflow, allows a smoother user experience while maintaining a secure authentication process.

[abdullah-alnahas]

I have a few questions about our current implementation and some potential improvements:

1. For the refresh_token endpoint, should we expect the refresh_token in the authorization header? Currently, it's expected in the POST request body.
2. When accessing critical endpoints, like updating the password while logged in, should we check if the login_token is "fresh"? This is similar to GitHub's pattern, where they ask you to log in again for sensitive actions, like deleting a repo.
3. If a user changes their password, should we revoke all existing tokens?
4. Currently, our implementation doesn't allow login from multiple devices. Should we enable this feature?