[Suggestion] Authentication Flow

[diogotcorreia]

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:

1. The user clicks the login button and gets redirected to Fenix to authenticate.
2. The user gets back to the HS Inventory website, and the backend authenticates the user with the Fenix API token.
3. If successful, a JWT and a refresh token are sent back to the client.
4. 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.
5. 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.
6. The client can now do requests for another 10 minutes.
7. The client can do this for a month (tbd), assuming the refresh token is stored in local storage or cookies.
8. 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:

[Hugo-Marques-work]

For less experiencied readers:
Authentication: Who can access the application
Authorization: What a user can do in the application

[Hugo-Marques-work]

I agree with the general idea, but depending on what we're using this could automatically be done. We should decide wether we want to have full control here before deciding manual/automatic

[Hugo-Marques-work]

I sugest using a diagram (can be a simple drawing) illustrating the flow ( i get it, but others might not)

[Hugo-Marques-work]

If we decide to use this flow:

If we kicked a person, and the refresh token is not expired, would the person be able to access the application?

[Hugo-Marques-work]

Fenix authentication: Should be doable inside the application, having to go to a console is kinda garbage

[diogotcorreia]

@Hugo-Marques-work

If we kicked a person, and the refresh token is not expired, would the person be able to access the application?

No, if we delete the refresh token from the database, the user would lose access within 10 minutes (until the JWT expires).

Fenix authentication: Should be doable inside the application, having to go to a console is kinda garbage

Yes, Fenix authentication would be done in the UI. It shouldn't be hard to login.

I suggest using a diagram (can be a simple drawing) illustrating the flow ( i get it, but others might not)

I'll work on that for the meeting :)

[Hugo-Marques-work]

Yes, Fenix authentication would be done in the UI. It shouldn't be hard to login.

My bad, i was reffering to

A list of authorized users can be managed through the admin console by an admin, by adding/removing their IST ID

[diogotcorreia]

@Hugo-Marques-work Ah, yeah. I was referring to the admin dashboard as 'admin console'. It is supposed to be a UI.