La séquence d'autorisation 'authorization_code' fait partie des séquences disponibles dans le protocole OAUTH 2.0, et est certainement celui le plus utilisé dans le Web 2.0.
oauth securite authorization code grant types

Previously on ‘OAuth 2.0’

Le workflow d’autorisation par code (authorization_code) permet à un client (logiciel), d’obtenir un jeton d’accès à la ressource demandée en deux temps.

C’est le dispositif le plus utilisé dans les applications web. Vous avez certainement déjà utilisé ce workflow lors d’une authentification sur un site à l’aide Facebook par exemple.

Le principe est d’utiliser une identité hébergée par un site tiers (authorisation server), pour obtenir un code d’autorisation utilisable par le site demandant l’accès. Cette étape est souvent accompagnée d’un écran de confirmation d’accès (authorization code). Ce code est alors récupéré par le site demandeur pour obtenir le jeton d’accès, prouvant l’autorisation d’un utilisateur.

Présentation pratique

Prenons pour exemple Facebook, et Spotify, je souhaite utiliser les informations que peux mettre à disposition Facebook (identité, profile utilisateur) avec l’application ou le site Spotify, en d’autres termes je suhaite transféré l’identité Facebook, à Spotify.

Pour cela il faut dans un premier temps être identifié auprès de Facebook, puis aller sur la page de Spotify, et demander à se connecter en utilisant l’identité Facebook.

Spotify Facebook Connection

Une fenêtre facebook va s’ouvrir en vous demandant si vous souhaitez autoriser l’échange d’information entre Spotify et Facebook.

Facebook Authorization Dialog

Lorsque vous choisissez `se connecter avec Facebook, vous donnez votre approbation à la requête d’autorisation d’accès de Spotify vers vos ressources Facebook.

https://www.facebook.com/dialog/oauth?
	client_id=1234567890
	&redirect_uri=<callback url>
	&response_type=token%2Csigned_request
	&scope=email%2Cpublish_actions%2Cuser_birthday

Voici l’url utilisée pour obtenir un code d’autorisation, j’ai volontairement enlevé les autres paramètres présents dans l’url car ceux-ci sont spécifiques Facebook.

Lorsque vous allez accepter l’autorisation, le token sera transmis à l’url de callback (redirect_uri), ainsi ce token sera utilisé par une liaison entre serveurs Facebook et Spotify pour obtenir le vrai jeton d’accès.

En effet la séquence authorization_code mélange un flux à l’aide du navigateur ou de l’application, avec un flux entre serveurs.

Une fois le jeton d’accès recupéré, Spotify pourra l’utiliser pour se faire passer pour l’utilisateur afin de récupérer les informations démandées (scope), dans le but de créer son profil utilisateur Spotify à l’aide des informations issues du profil Facebook.

Magique, non ?

Protocole

Si vous avez bien compris, l’identification de l’utilisateur Spotify à l’aide de l’identité Facebook n’a rien à voir avec OAuth 2.0, ce n’est pas un protocole d’identification mais bel et bien un protocole d’autorisation.

Au final, nous avons autorisé Spotify à utiliser des informations provenant de Facebook, en l’occurence les informations liées à notre identité sur Facebook. Mais en aucun cas, nous nous sommes identifiés sur Spotify avec l’identité Facebook, c’est en mon sens un abus de language.

OAuth 2.0 Authorization Code Flow

Sur le plan OAuth 2.0 Strict, il est nécessaire d’utiliser 2 ressources différentes :

Code d’autorisation

https://www.dropbox.com/1/oauth2/authorize?
	client_id=<appkey>
	&response_type=code
	&redirect_uri=<redirect URI>
	&state=<CSRF token>

Cet exemple de requête montre comment on obtient un code d’autorisation pour l’Api Dropbox. Il est nécessaire :

La réponse à cette requête HTTP sera une page contenant le formulaire d’approbation de l’autorisation, et vous serez, après validation redirigé vers l’url (redirect_uri).

https://www.example.com/callback?code=<authorization code>&state=<CSRF token>

Cette page recevra donc le code d’autorisation, ainsi que le jeton CSRF utilisé lors de la demande du code (state).

Jeton d’accès

A ce moment, l’application cliente peut donc demander le jeton d’accès correspondant au code d’autorisation, cette demande se fait de serveur à serveur, il n’y a pas de passage par le client.

https://api.dropbox.com/1/oauth2/token?
	code=<authorization code>
	&grant_type=authorization_code
	&redirect_uri=<redirect URI>

Cette requête sera executé par le client, il utilisera son identifiant, et son secret pour s’identifier auprès du serveur d’autorisation.

curl https://api.dropbox.com/1/oauth2/token -d code=<authorization code> -d grant_type=authorization_code -d redirect_uri=<redirect URI> -u <app key>:<app secret>

La réponse contiendra votre jeton d’accès, il aura cette forme :

{"access_token": "<access token>", "token_type": "Bearer", additionals attributes  (expire, etc.)}

Accéder à la ressource protégée

Vous pouvez utiliser ce jeton pour accéder à la ressource souhaitée maintenant, pour cela il suffit de remplacer l’entête HTTP habituelle Authorization par :

curl https://api.dropbox.com/1/account/info -H “Authorization: Bearer <access token>”

Pour revenir à notre exemple entre Spotify et Facebook, c’est à partir de ce moment que le transfert de l’identité entre en jeu. Une fois le jeton d’accès possédé par Spotify, il l’utilise pour accéder aux informations liées au profile référencé par le jeton.

Si l’utilisateur existe dans le référentiel Spotify, l’application continue son déroulement, s’il n’est pas trouvé, il y a certainement une phase de création de l’image de l’identité Facebook dans le système Spotify.

D’où un dernier conseil sécurité, faîtes toujours attention aux autorisations, l’application peut avoir accès à tout Facebook en votre nom (Publication en votre nom, Notification FarmVille hors contrôle, …).

Conclusion

Voilà, je vous ai présenté la séquence d’authentification par code d’autorisation, comme vous avez pu le comprendre le protocole OAuth 2.0 nécessite de nombreux échanges entre le serveur de ressource, le serveur d’autorisation et le client.

Il existe d’autres séquences d’autorisation permettant de diminuer ces échanges, je les présenterai prochainement.

Mais je rappelle et j’insiste OAuth est un protocole d’autorisation, pas d’identification !

Autres articles de la série :

Retours sur expérience sur la réalisation d'une solution de CTI
cyber securite bigdata

Parce qu'il n'est pas nécessaire d'installer en root les binaires produits par les dépendances Node.js.
linux nodejs npm securite

Mise en place d'une blockchain privée en utilisant le protocole Ethereum
securite dev blockchain ethereum