oauth 2.0

OAuth 2.0

OAuth 2.0 est un framework d'autorisation largement utilisé qui permet à une application (client) d'obtenir un accès limité à des ressources protégées pour le compte d'un utilisateur ou de l'application elle-même.

Qu’est-ce que OAuth 2.0 ?

OAuth 2.0 est le standard de facto pour l’autorisation et est largement utilisé sur le web. Il permet à une application d’obtenir de manière sécurisée un accès limité à des ressources protégées sur une autre application, telles que le profil ou les données d’un utilisateur, sans exposer des informations confidentielles comme les mots de passe.

Voyons un exemple concret pour mieux comprendre. Vous avez une application web MyApp qui souhaite accéder au Google Drive de l’utilisateur. Au lieu de demander à l’utilisateur de partager ses informations d’identification Google Drive, MyApp peut utiliser OAuth 2.0 pour demander l’accès à Google Drive pour le compte de l’utilisateur. Voici un flux simplifié :

Dans ce flux, MyApp ne voit jamais les informations d’identification du Google Drive de l’utilisateur. À la place, il reçoit un Jeton d'accès (Access token) de Google qui lui permet d’accéder à Google Drive pour le compte de l’utilisateur.

Composants clés de OAuth 2.0

Pour l’exemple ci-dessus, MyApp est le Client , Google est à la fois le Serveur d'autorisation (Authorization server) et le Serveur de ressources (Resource server) , et l’utilisateur est le Propriétaire de ressource (Resource owner) . Le flux implique tous les composants clés de OAuth 2.0 :

Client : L’application qui souhaite accéder aux ressources protégées. “Client” et “application” sont souvent utilisés de manière interchangeable.
Resource owner : L’utilisateur qui possède les ressources protégées. Le resource owner peut accorder (autoriser) ou refuser l’accès au client.
Authorization server : Le serveur qui effectue l’autorisation (généralement avec authentification) et émet les access tokens au client.
Resource server : Le serveur qui héberge les ressources protégées. Il vérifie l’access token et sert les ressources protégées au client.

Grants (flux) OAuth 2.0

Grant constitue la base de OAuth 2.0 et définit comment le client peut obtenir un access token depuis le authorization server. La spécification de base de OAuth 2.0 définit quatre types de grants :

Sans entrer dans les détails de chaque type de grant, nous pouvons les classer en deux catégories :

Authorization grants : Utilisés lorsque le client doit accéder à des ressources pour le compte d’un utilisateur, c’est-à-dire qu’une autorisation de l’utilisateur est requise.
Client credentials grant : Utilisé lorsque le client doit accéder à des ressources en son propre nom. Ce type de grant est approprié pour la communication Machine-to-machine .

Authorization grants

Quel que soit le type de grant, les authorization grants comportent les étapes communes suivantes :

Le client initie une Demande d'autorisation (Authorization request) vers le authorization server.
Le authorization server authentifie l’utilisateur (resource owner) et demande la permission d’accéder aux ressources.
L’utilisateur accorde la permission au client.
Le authorization server émet un access token au client.
Le client utilise l’access token pour accéder aux ressources protégées sur le Serveur de ressources (Resource server) .

Notez que les étapes exactes et les paramètres peuvent varier selon le type de grant. Par exemple, le authorization code grant implique davantage d’étapes comme la génération et l’échange de code.

Client credentials grant

Le client credentials grant est beaucoup plus simple et n’implique pas d’autorisation utilisateur. Voici un flux simplifié :

Le client envoie une Demande de jeton (Token request) au authorization server.
Le authorization server authentifie le client et émet un access token.
Le client utilise l’access token pour accéder aux ressources protégées sur le Serveur de ressources (Resource server) .

Pour des discussions approfondies sur les grants de OAuth 2.0, voir Octroi d'autorisation OAuth 2.0 (OAuth 2.0 grant) et les articles spécifiques à chaque type de grant.

Access control avec OAuth 2.0

OAuth 2.0 définit le paramètre Portée (Scope) pour spécifier les permissions demandées par le client. Le authorization server peut ignorer totalement ou partiellement les scopes demandés et accorder l’accès selon ses propres politiques d’access control.

Cependant, OAuth 2.0 laisse au authorization server sa propre discrétion sur la manière de faire respecter l’ Contrôle d'accès . Cela signifie que le authorization server peut décider quelles ressources le sujet (utilisateur ou client) peut accéder et quelles actions ils peuvent effectuer sur ces ressources.

Utilisons encore l’exemple de Google Drive. MyApp peut initier une requête d’autorisation pour accéder au Google Drive d’un autre utilisateur par erreur. Dans ce cas, le authorization server de Google devrait rejeter la requête car l’utilisateur n’a pas les permissions nécessaires pour accéder au Google Drive d’un autre utilisateur.

Un autre cas est lorsque MyApp reçoit un access token de Google qui lui permet de lire des fichiers depuis le Google Drive de l’utilisateur. Cependant, MyApp tente de supprimer un fichier au lieu de le lire. Le resource server (Google) devrait refuser la requête.

Ces deux cas démontrent pourquoi l’ Contrôle d'accès est nécessaire lors de l’implémentation de OAuth 2.0. Le Serveur d'autorisation (Authorization server) et le Serveur de ressources (Resource server) doivent travailler ensemble pour faire respecter les politiques d’access control et protéger les ressources.

Modèles d’access control

Pour gérer correctement l’access control, il est recommandé d’utiliser les modèles standards d’access control tels que Contrôle d'accès basé sur les rôles (Role-based access control, RBAC) et Contrôle d'accès basé sur les attributs (Atrribute-based access control, ABAC) . Ces modèles ont prouvé leur efficacité dans l’industrie et offrent l’évolutivité pour les futurs besoins.

OAuth 2.1

OAuth 2.1 est une mise à jour proposée pour la spécification OAuth 2.0 qui vise à améliorer la sécurité et l’utilisabilité selon l’expérience de l’industrie au fil des ans. Bien que OAuth 2.1 ne soit pas encore finalisé, nous pouvons tout de même apprendre sur les changements proposés et comprendre comment ils peuvent affecter les implémentations actuelles de OAuth 2.0. OAuth 2.1 peut être considéré comme une formalisation des meilleures pratiques et recommandations de sécurité qui ont été largement adoptées dans l’industrie.

OAuth 2.0 et OpenID Connect (OIDC)

OAuth 2.0 définit uniquement le processus d’autorisation et ne couvre pas l’authentication ou l’identité de l’utilisateur. Pour cette raison, OpenID Connect (OIDC) a été introduit comme couche d’identité au-dessus de OAuth 2.0. OIDC étend OAuth 2.0 pour fournir l’authentication de l’utilisateur et des informations d’identité sous forme de Jeton ID (ID token) .

OpenID Connect étend deux grants de OAuth 2.0 (authorization code et implicit) pour inclure des ID tokens, et introduit un nouveau grant appelé hybrid flow qui combine les deux.

Cela signifie que toutes vos connaissances et pratiques sur OAuth 2.0 peuvent être directement appliquées à OIDC ; toutes les extensions de OAuth 2.0 telles que Clé de preuve pour l'échange de code (Proof Key for Code Exchange, PKCE) et Indicateur de ressource (Resource indicator) peuvent également être utilisées dans OIDC.