Dans ce tutoriel je vous propose de découvrir une partie du fonctionnement du protocole Oauth 2.0 à travers la mise en place d'un système de connexion via Google SignIn
L'objectif du protocole l'OAuth 2.0
Le protocole Oauth est un protocole d'autorisation qui permet aux utilisateur de donner à un site l'accès aux données hébergées sur un autre site. Ce mécanisme est utilisé par des sociétés comme Google, Facebook, Twitter et autre afin de permettre aux utilisateurs de partager leurs informations avec des applications tierces. On le retrouve très souvent utilisé pour mettre en place un système de "Connexion via X".
Etape 1 : Obtention de l'autorisation
La première étape consiste à demander à l'utilisateur les permissions d'accès nécessaires afin de pouvoir accéder aux données / actions qui nous intérèssent.
Pour cela on dirige l'utilisateur vers l'url d'autorisation accompagnée de paramètres spécifiques.
<URL_AUTORISATION>?
scope=email&
access_type=online&
redirect_uri=<URL_REDIRECTION>&
response_type=code&
client_id=<CLIENT_ID>- L'URL d'autorisation peut être obtenu en consultant la documentation ou en interrogeant un fichier de découverte, comme c'est le cas pour Google par exemple).
- Le
CLIENT_IDs'obtient en créant une application auprès du service concerné. La création de l'application permet aussi de personnaliser l'apparence de l'écran d'autorisation qui sera présenté à l'utilisateur. - Le
scopeva dépendre des services et permet de définir les informations que l'on souhaite obtenir ou les actions que l'on souhaite auprès de l'utilisateur. - Le
redirect_uripermet de définir l'URL vers laquelle l'utilisateur sera redirigé lorsqu'il aura accepté les permissions. C'est cette URL qui sera responsable du traitement des informations liées à l'autorisation. - Le
access_typepermet de définir le type de token que l'on souhaite obtenir. "offline" permettra d'obtenir un refresh_token qui pourra être utilisé pour regénérer un access_token plus tard et ainsi accéder à l'API bien après la phase d'acceptation de l'utilisateur.
Etape 2 : L'utilisateur accepte les permissions
Si l'utilisateur accepte les permissions, il est automatiquement redirigé vers le chemin défini en paramètre avec un code d'autorisation.
Ce code d'autorisation n'est valable que pour une courte durée et permet d'obtenir un token d'accès auprès du service concerné.
curl --request POST \
--url <TOKEN_ENDPOINT> \
--header 'content-type: application/x-www-form-urlencoded' \
--data client_id=<CLIENT_ID> \
--data client_secret=<CLIENT_SECRET> \
--data code=<CODE>\
--data redirect_uri=<REDIRECT_URI> \
--data grant_type=authorization_codeEn échange de cette requête on obtiendra le code d'accès qui nous permettra ensuite d'accéder aux différentes API du service tiers.
{
"access_token": "yaz/eaze.azrjpazroijznfazkvhjzabvkjzbfk",
"expires_in": 3600,
"refresh_token": "az/Ezjo.123I21H3INaoeaze123", // si access_type=offline",
"token_type": "Bearer",
}Etape 3 : On utilise le token d'accès
Maintenant que l'on a le token d'accès il est possible de le joindre dans l'en-tête Authorization de nos requêtes afin de pouvoir accéder à certains points d'entrées de l'API.
Par exemple pour récupérer les informations personnelles de l'utilisateurs :
curl --request GET \
--url <userinfo_endpoint> \
--header 'authorization: Bearer <ACCESS_TOKEN>'Etape 4 (dans le cas offline) : Rafraichir le token
Si, lors de l'autorisation, vous avez demandé un token d'accès offline vous pourrez regénérer un nouveau token d'accès lorsque vous le souhaitez (Il faudra pour cela utiliser le refresh_token obtenu lors de l'étape 2).
curl --request POST \
--url <TOKEN_ENDPOINT> \
--header 'content-type: application/x-www-form-urlencoded' \
--data client_id=<CLIENT_ID> \
--data client_secret=<CLIENT_SECRET> \
--data refresh_token=<REFRESH_SECRET> \
--data grant_type=refresh_tokenCela vous permet d'obtenir un nouveau token d'accès sans avoir a demander à nouveau l'autorisation de l'utilisateur.
