[Suggestion] Authentication Flow #2
Description
Hugo Mark Of Approval: 👍
This is my idea for the Authentication Flow for HS Inventory. This need to be discussed in the first HS Inventory meeting.
Fenix Authentication 👍
Obviously, we're going to require everyone to login through Fenix. This ensures that only members of the HS Community can login. A list of authorized users can be managed through the admin console by an admin, by adding/removing their IST ID.
Json Web Tokens (JWT) - Short-lived
JWT tokens can be used as short-lived tokens for faster authorization. They don't need to be checked against a database, which means they're extremely efficient. They work by signing the token with a secret, so their content can't be changed without the signature failing.
We can use these tokens as a short-lived authentication method, that only lasts around 10 to 20 minutes.
These tokens have the downside that they can't be revoked remotely, in case they're compromised. That's why it's important to keep their lifespan as short as possible.
Access Tokens - Long-lived refresh tokens
Along with JWT, a refresh token is sent to the client on login. This can have a longer lifespan (let's say, a month), which would allow the client to ask for a JWT when theirs expires. In contrary to a JWT, this refresh token is stored in the database, which means it's slower to authenticate, but it can be remotely disabled if it's compromised.
Using JWT and refresh tokens together
For a very secure application, we can take advantage of both types of tokens. The authentication/authorization flow would be as follows:
- The user clicks the login button and gets redirected to Fenix to authenticate.
- The user gets back to the HS Inventory website, and the backend authenticates the user with the Fenix API token.
- If successful, a JWT and a refresh token are sent back to the client.
- The client makes whatever requests they make within 10 minutes, that is, before the JWT expires.
The server verifies the signature of the JWT, authorizing the request. - The client wants to make another request, but the JWT has expired. Instead, it sends a request with the refresh token, to which the server replies with a newly generated JWT. The server has to query the database in this request.
- The client can now do requests for another 10 minutes.
- The client can do this for a month (tbd), assuming the refresh token is stored in local storage or cookies.
- After a month, the client is required to login again through the Fenix API, repeating the process.
A cron job should be created to periodically delete expired refresh tokens from the database.
Flowchart: