Find out how to authenticate to Gitlab with the REST API

[F0urchette]

Description

We need to see how to connect with a Gitlab account without using firebase (which is not available for this forge). To do so, we will have to use the REST API

Hints

• We should be able to use the implicit grant flow to login with OAuth
• It will be necessary to see how to do the same with Github to get rid of firebase (except for the deployment) and to design a general system for the 2 forges
  • The question of the automatic reconnection will have to be solved because firebase is used for this purpose too (session managed by firebase).

[F0urchette]

Here are the observations that led me to the conclusion that personal access tokens should be used for authentication :

• Authentication with implicit grant flow requires registering Git4School on Gitlab. This is not a problem for authentication to gitlab.com but for a hosted forge it is more tricky. Indeed, it would be necessary that Git4School is registered on the hosted Gitlab forge, and the user would have to give the client_id and client_secret necessary for the authentication. However, the client_secret must absolutely be kept secret and therefore cannot be stored anywhere but on a server
• To avoid this problem, I thought of using the credentials for authentication directly, which avoids the use of client_id and client_secret. But this login method is not usable with users with double authentication enabled, and it is instead recommended to use the login method with personal access token. To do this, we just need to tell the user how to create this personal access token, point him to the creation page and ask him for the key. Simply use this key in the requests to the API as an access token.

Finally, the question of the user session comes up. It seems to be a problem to ask the user to enter the personal access token for each connection. It would be necessary to be able to store it somewhere (_on a secured place, therefore a server) to keep the user session alive.

[F0urchette]

So the decision is to store the token in the local storage. Here are the sources :

What are the options to store the token ?

• https://mattwest.design/choosing-the-best-client-side-storage-technology-for-your-project
• https://softwareengineering.stackexchange.com/questions/219953/how-is-localstorage-different-from-indexeddb

Why local storage is unsafe ?

• https://dev.to/rdegges/please-stop-using-local-storage-1i04
• https://snyk.io/blog/is-localstorage-safe-to-use/
• https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
• https://auth0.com/blog/secure-browser-storage-the-facts/

Why it's ok to use local storage even if it's unsafe ?

• https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html

[F0urchette]

Here is the beginning of an open-source alternative to Firebase, especially with the cloud functions that is in progress : https://supabase.io/