OAUTH est un protocole d’autorisation, il a pour but de fournir un jeton d’accès à une ressource demandée. Il ne faut pas confondre identification qui a pour but d’identifier un utilisateur auprès d’un système, et autorisation qui a pour but, une fois l’identification passée, d’obtenir des droits sur celui-ci.

OAUTH 2.0 est :

• un système d’autorisation
• libre
• utilisable par des navigateurs et des applications

OAUTH 2.0 est un protocole très utilisé dans le domaine des applications sociales :

• Google
• Twitter
• Facebook

Glossaire

Quelques définitions avant de commencer :

• Jeton d’accès (access token): valeur unique, permettant de référencer une identité OAUTH (Client, Client/Utilisateur).
• Serveur d’autorisation (authorization server) c’est auprès de ce serveur que l’on obtient le jeton d’accès.
• Serveur de ressource (resource server) c’est le serveur contenant les ressources protégées. Il est nécessaire de fournir un jeton d’accès pour prouver son droit d’accès à la ressource demandée.
• Code d’autorisation (authorization_code) : code à validité temporaire permettant à un client d’obtenir un jeton d’accès une fois l’accès accordé.
• Client (client): celà qualifie un composant logiciel ayant une identité connu auprès du serveur d’autorisation.
• Utilisateur (user): cela qualifie une identité personnelle.

Flux d’autorisation (Grant Types)

Afin de fournir un jeton d’accès, OAUTH utilise un certains nombre de workflows. Il existe cinq workflows officiels.

Autorisation par code

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.

Autorisation implicite

Ce workflow (implicit) est une variante du précédent, avec un seul point de différence : l’accès est automatiquement confirmé, pas d’interaction utilisateur.

Ce workflow n’est pas conseillé, il est reconnu comme n’étant pas sécurisé puisqu’il y a des actions de validations implicites.

Identification client

Le workflow (client_credentials) est un peu particulier. Il permet d’identifier un client UNIQUEMENT. Très pratique pour autoriser les communications inter-serveurs.

Identification utilisateur via client

Le workflow (password) est un worflow permettant d’obtenir un jeton d’accès utilisateur. Ce jeton est une identification d’un client et d’un utilisateur.

Vous trouverez ce type de workflow dans les applications embarquées (mobiles, applications lourdes).

Assertion

Ce dernier workflow (assertion) est très particulier puisqu’il permet d’utiliser des jetons dans d’autres formats (SAML, JWT).

L’OAUTH 2.0 JWT Token Bearer est une extension du protocole, qui a pour but d’utiliser un jeton d’accès préforgé au format Json Web Token par le client, et validé par le serveur. Ce workflow permet de réduire les échanges puisque le jeton JWT contient toute l’information échangée.

Conclusion

Dans le prochaine article, je partlerai d’une implémentation particulière qui utilise OAUTH pour effectuer des authentifications en milieux distribué UAA.

Autres articles de la série :

• OAuth 2.0, Partie 1
• OAuth 2.0, Authorization Code - Partie 2