Scopes Standards OpenID Connect et OAuth2
OpenID Connect et OAuth 2.0 définissent un ensemble de scopes standards qui peuvent être utilisés pour contrôler le niveau d’accès aux ressources.
Qu’est-ce que les Scopes ?
Les scopes (ou portées) sont un moyen de définir le niveau d’accès qu’une application cliente possède sur les ressources d’un utilisateur. Ils permettent à l’application cliente de demander des permissions spécifiques à l’utilisateur, telles que l’accès en lecture au profil d’un utilisateur ou l’accès en écriture à son calendrier. Les scopes sont définis par le serveur d’autorisation et peuvent être utilisés pour contrôler le niveau d’accès qu’une application cliente a aux ressources d’un utilisateur.
Pendant le processus d’autorisation, l’application cliente demande des scopes spécifiques à l’utilisateur. L’utilisateur accorde ou refuse ensuite ces scopes, selon ses préférences. Si l’utilisateur accorde les scopes, le serveur d’autorisation émet un jeton d’accès (access token) à l’application cliente, qui peut être utilisé pour accéder aux ressources demandées.
Scopes OpenID Connect
OpenID Connect définit un ensemble de scopes standards qui peuvent être utilisés pour contrôler le niveau d’accès qu’une application cliente a aux ressources d’un utilisateur. Ces scopes sont utilisés pour demander des permissions spécifiques à l’utilisateur et sont définis dans la spécification OpenID Connect.
Certains des scopes standards définis par OpenID Connect incluent :
- openid : Ce scope est utilisé pour indiquer que l’application cliente demande une authentification et des informations d’identité sur l’utilisateur.
- profile : Ce scope est utilisé pour demander l’accès aux informations de profil de l’utilisateur, telles que son nom, son adresse e-mail et sa photo de profil.
- email : Ce scope est utilisé pour demander l’accès à l’adresse e-mail de l’utilisateur.
- address : Ce scope est utilisé pour demander l’accès aux informations d’adresse de l’utilisateur.
- phone : Ce scope est utilisé pour demander l’accès au numéro de téléphone de l’utilisateur.
- offline_access (ou offline) : Ce scope est utilisé pour demander l’accès aux jetons de rafraîchissement (refresh tokens), qui peuvent être utilisés pour obtenir de nouveaux jetons d’accès sans nécessiter que l’utilisateur se réauthentifie.
Comment nommer les scopes ?
L’un des plus grands défis en tant que développeur est de nommer les choses, n’est-ce pas ? Les scopes ne font pas exception. La spécification OAuth2 ne fournit pas de directives strictes sur la façon de nommer les scopes. Cependant, il est recommandé d’utiliser un nom clair et descriptif qui reflète l’objectif du scope. Par exemple, si vous demandez un accès en lecture à une ressource de livre dans votre application, vous pourriez nommer le scope read_books.
Lors de la nomination des scopes, il est important de prendre en compte les éléments suivants :
- Clarté : Le nom du scope doit indiquer clairement l’objectif du scope et le niveau d’accès qu’il fournit.
- Cohérence : Utilisez des conventions de nommage cohérentes pour l’ensemble des scopes afin de faciliter leur gestion et leur compréhension.
- Descriptivité : Utilisez des noms descriptifs qui transmettent clairement l’objectif du scope aux développeurs et aux utilisateurs.
Voici un mauvais exemple de la façon dont les scopes peuvent être nommés :
{ "scopes": { "r": "Read access", "w": "Write access", "rp": "Read profile", "wp": "Write profile" }}Tout comme pour le nommage des variables, des fonctions ou des classes, les scopes doivent être nommés de manière à ce qu’il soit facile de comprendre leur but et leur utilisation.
Voici un meilleur exemple de la façon dont les scopes devraient être nommés :
{ "scopes": { "read_books": "Read access to book resources", "write_books": "Write access to book resources", "read_profile": "Read access to user profile information", "write_profile": "Write access to user profile information" }}Stratégie de Nommage des Scopes de Google
Google possède l’un des ensembles d’API les plus largement utilisés et les plus vastes. La stratégie de nommage des scopes chez Google doit être cohérente et claire pour les développeurs, tout en étant fiable, évolutive et pérenne. Pour répondre à ce besoin, Google définit le nommage des scopes en incluant le domaine de l’API, le service, la ressource et l’action. Par exemple, https://www.googleapis.com/auth/drive.file signifie que l’application cliente demande l’accès aux fichiers Google Drive de l’utilisateur.
Voici des documentations sur les scopes de certains services Google :
Stratégie de Nommage des Scopes d’Ory
Dans cette section, nous examinerons l’exemple de la stratégie de nommage des scopes d’Ory. Fosite, une bibliothèque Go développée par Ory qui fournit un SDK OpenID Connect, donne un exemple de stratégie hiérarchique de nommage des scopes. Cette stratégie de nommage tend à être plus explicite et suffisamment flexible pour être utilisée dans divers contextes.
Cet exemple commence par la partie la plus générale du scope pour aller vers la partie la plus spécifique. Par exemple, photos.read signifie que l’application cliente demande un accès en lecture aux photos de l’utilisateur. Si vous devez demander un accès en lecture pour un type de photos spécifique par exemple, vous pouvez utiliser photos.read.albums pour demander un accès en lecture aux albums photos de l’utilisateur.