#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)