Research the best way to perform authentication

[jbargu]

While accessing the API endpoints, every call has to be authenticated. Research:

• the best way to perform authentication (e.g. JWT tokens),
• React implementation of the above approach: how to use it throughout the app with every call,
• backend implications for the above approach, e.g. "Backend should check 'Authorization': Bearer TOKEN header before every call to authorize the user",
• any other assumptions.

[ZiyedB]

the best way to perform authentication (e.g. JWT tokens),

For this I'd suggest as well a JWT Tokens ( probably the safest and easiest. Or we could customize it ).

• However we should define how long should the token live and be valid ? Hours ? days ?
• What information goes inside the token )
• Is there different permissions ( levels ) ? Can all users access the same thing once logged in ?

React implementation of the above approach: how to use it throughout the app with every call,

I think we want to need two approach.

1. Through the app, FE would handle the logic within routes ( you can't access certain routes if you aren't logged in ). Should be easy to do at the parent level. As well adding some redirect if you try to access a route.
   This is can be done I believe something like that :

<Route path="/login" component={Login} />
<ProtectedRoute path="/home"  component={Home}/>

Where ProtectedRoute would just check if user is logged in or not <Route render = userLoggedIn ? <component> : <redirectto>

2. Second approach would be to always pass the authorization token ( for api calls needed, signup / login wouldn't need such thing )
   To do that, let's just use an interceptor. It seems in react this is supported by the module axios
   axios.interceptors.request.use(response=> { ( we could also add some request timeout in there etc. )

backend implications for the above approach, e.g. "Backend should check 'Authorization': Bearer TOKEN header before every call to authorize the user",

Secure the apis that needs to. ( Is there some API endpoint doc, like a swagger ? That would be handy actually )

any other assumptions.

• Refresh of the token -> If you land on site with a previous token, should we just refresh the current one.
  Ex: I come on the 1st ( expire 30 days ), come back on the 20th ( should I ask for a new one using the previous, and this way extends 30 days more )
• Invalidation of the token -> if users change password, the token should be invalidated. This probably means that part of the token hash should contain the user password hash.

[jbargu]

However we should define how long should the token live and be valid ? Hours ? days ?

Let's go for a couple of hours first. We can update it later with shorter time span and refresh token endpoints.

What information goes inside the token

This will be provided by the backend: user_id and exp with timestamp expiration. For FE you would probably need username as well to show it to the user. This will be an email address.

Is there different permissions ( levels ) ? Can all users access the same thing once logged in ?

Yes, there will be only one user at any given time (signup will support only one user). Therefore permission system is not needed and user will be able to access everything. Currently this is only in place to protect the endpoints from being unauthenticated.

To do that, let's just use an interceptor. It seems in react this is supported by the module axios

This seems reasonable and probably the best.

Secure the apis that needs to. ( Is there some API endpoint doc, like a swagger ? That would be handy actually )

Not right now, we will make endpoints on the go as we figure out what we need. For JWT token you can expect:

• /api/auth for authentication (username + hashed password),
• /api/auth/verify whether JWT token is still valid,
• /api/auth/me information about the currently authenticated user,

Refresh of the token -> If you land on site with a previous token, should we just refresh the current one.
Ex: I come on the 1st ( expire 30 days ), come back on the 20th ( should I ask for a new one using the previous, and this way extends 30 days more )

I would not complicate with refresh_token functionality at the moment. If access_token is expired just redirect to login screen again. User will not use the UI that often.

Invalidation of the token -> if users change password, the token should be invalidated. This probably means that part of the token hash should contain the user password hash.

The 'Change password functionality' will not be available at the moment. If we decide to implement it, we can sign the token with user password hash and it should fail the next time.

Right now, we need a simple login screen with no extra bloat. We can reiterate later.