#web #code #user-experience

OAuth 2.0 (Open Authorization) est un standard web permettant a une application donnée (le client) d’accéder à des informations sur une autre application, le “resource server” (le serveur qui détient les ressources, c’est à dire les informations en question). L’utilisateur s’appelle le “ressources owner”.

Le OAuth flow se déroule en quelques étapes : 1. Le resource owner (l’utilisateur) veut permette au client d’accéder à des informations qui se trouvent sur un autre service (ex: je veux autoriser Supabase à accéder à mes repositories Github) 2. Le client redirige vers l’autorization server, avec client_id, redirect_url, response_type et scopes 3. L’autorization serveur affiche une page pour demander le consentement de l’utilisateur pour le partage des données. 4. Si accepté, l’utilisateur est rédigé sur e client (grace au redirect_url), avec un authorization_code. 5. Le client recontacte directement l’autorization serveur, avec l'autorization_code et un client_secret, mis en place au préalable. 6. L’autorization serveur renvoie un access_token, qui pourra désormais être utilisé par le client pour demander la ressource (dans le scope).

OpenId Connect est un surcouche d’OAuth permettant d’accéder en particulier à la ressource “identité de l’utilisateur”. Dans ce cas, le resource server est appelé un “identity provider”. C’est ce qui est utilisé pour les boutons Facebook ou Google sign in.

Note: Ne pas confondre OAuth (standard) et Auth0 (solution commerciale d’authentification)