Accueil > OpenID Connect OAuth Server par DnC > Développer > Définition des scopes et généralités sur leur utilisation par les (...)

Définition des scopes et généralités sur leur utilisation par les applications

La portée de l’autorisation est définie par les Scopes. C’est sans doute le point le plus ouvert du standard et donc un concept difficile à maîtriser pour le développeur d’une application utilisant OpenID Connect.

La possibilité de moduler les portées d’autorisation en fonction de l’application cliente et de l’utilisateur final est une fonctionnalité exceptionnellement intéressante d’OAuthSD.

On voit souvent en OIDC un simple SSO, mais c’est passer à côté de toute la puissance du dispositif : le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation.

OpenID Connect définit les scopes en de multiples endroits de la documentation d’OAuth 2.0, sans pourtant donner à ce sujet la synthèse qu’il mérite. La bibliothèque OAuth2 Server Library for PHP développée par Brent Shaffer met en oeuvre les scopes sans que l’auteur en présente la philosophie. Cependant, l’analyse du code de cette bibliothèque permet de compléter la spécification, de dégager les principales définitions et de proposer un concept d’utilisation.

Quatre niveaux de définition des scopes

1. Les Scopes pris en charge par le serveur (Supported scopes)

En plus des scopes réservés et non-réservés définis par OpenID Connect, le développeur définit les scopes particuliers utilisés par les applications. Ils sont inscrits dans le fichier de configuration du serveur (variable $supportedScopes).

Le scope ’basic’ est également inscrit dans la configuration en tant que scope par défaut.

Seuls ces scopes peuvent être utilisés, le contrôleur Authorize rejettant toute requête comprenant un scope absent de cette liste.

2. Les Scopes réservés (Reserved Scopes)

Les Scopes réservés jouent un rôle particulier [1]. Ils sont essentiellement utilisés par le serveur pour modifier le comportement des flux.

- openid : ce scope est obligatoire pour que l’application puisse fonctionner avec OpenID Connect. S’il est le seul scope demandé, l’identification de l’utilisateur final se réduira au claim sub.

- offline_access : Les demandes d’accès d’OpenID Connect incluent le jeton d’actualisation uniquement si la portée offline_access a été demandée et accordée.

- sli : ce scope est obligatoire pour que l’application accepte l’identification unique (Single Login Identification, SLI) et la ré-authentification silencieuse (Silent Re-Authentication, SRA) telles que nous les avons implémentées dans OAuthSD.

- kerberos : ce scope autorise la création d’une session SLI d’OAuthSD à partir de l’authentification avec Kerberos.

Notes :
- Les deux premiers scopes sont définis par le standard OAuth 2.0, tandis que les deux derniers sont introduits par OAuthSD.
- Les scopes réservés ne donnent pas lieu à consentement de la part de l’utilisateur final, à l’exception du scope offline_access.

3. Les Scopes disponibles pour une application (Available scopes)

Ces scopes sont définis au moment de l’inscription d’une application sur le serveur. Ils comprennent :
- tout ou partie des scopes réservés,
- des scopes non-réservés (Non Reserved Scopes), qui sont définis par OpenID Connect ou définis à l’initiative du concepteur de l’application [2]

Par la suite, une application ne pourra utiliser d’autres scopes que ceux qui auront été inscrits ainsi. En particulier, le contôleur Authorize vérifie dès le début du processus que les scopes demandés dans la requête figurent bien dans la liste des Scopes disponibles pour l’application (Available scopes).

4. Les portées accordées (Granted scopes)

Une application transmet les scopes dans la demande d’autorisation (appel au point de terminaison Authorize). Ils doivent figurer dans la liste des Scopes disponibles pour une application.

Certains de ces scopes sont des demandes d’autorisation (Requested scopes). Une bonne compréhension du sujet nécessite de distinguer deux positions de l’utilisateur final par rapport au propriétaire des données, comme défini par la norme OAuth 2.0 (voir Portée de l’autorisation (Scope)). En résumé, il faut considérer les scopes selon deux cas de figure [3] :
- soit les données protégées sont la propriété de l’utilisateur, et les scopes doivent être compris comme une demande d’accès de l’application à ces données : l’application devra obtenir l’accord de l’utilisateur pour poursuivre,
- soit l’application (au sens large) "possède" les données protégées, et les scopes doivent être compris comme une portée accordée par l’application.

Dans le deuxième cas (si les données appartiennent à l’application) une application peut moduler les privilèges accordés à l’utilisateur en fonction du profil de ce dernier qui est traduit par les scopes.

Si l’application ne prévoit pas de moduler les privilèges accordés, le concepteur peut utiliser les scopes autorisés ou le scope par défaut.

Une fois l’authentification réalisée (et, si nécessaire, les scopes ayant été acceptés par l’utilisateur final), les scopes deviennent des portées accordées (granted scopes).

OAuthSD : scope "privileges"

Ce scope est particulier à OAuthSD dans le cadre des flux d’OpenID Connect.

Le scope"privileges" comporte les déclarations (claims) "scope" et "profile" [4] qui correspondent aux champs éponymes de la table users.

Il revient à une application tierce de déterminer les valeurs à attribuer au claim "scope". Pour cela, OAuthSD offre deux techniques d’interface :
- Incorporer au jeton JWT des déclarations supplémentaires,
- Utiliser un service HTTP Rest.

Si une application présente le scope "privileges" au contrôleur Authorize, les déclarations "profile" et "scope" seront incorporées aux données UserInfos. Dans cette optique, il s’agit d’une portée accordée (Granted Scope) au même titre que les portées "basic", "email" etc. qui contrôlent l’accès aux données de la table users.

En plus de ce comportement standard, ces déclarations seront incorporées à la charge utile du jeton d’identité.
Ainsi l’identité de l’application, de l’utilisateur final et de ses portées d’autorisation est parfaitement établi par la signature du jeton JWT.

Utilisation du scope "privileges" claim "scope" pour l’attribution de privilèges dans les applications

OAuthSD regroupe les informations sur l’utilisateur final dans la table users. Le champ ’scope’ est du type texte et peut donc accueillir toute sorte de données pour décrire le profil de l’utilisateur ou donner la liste de ses privilèges. Par exemple, on pourra créer un objet de données ’profiler’ et le stocker au format Json.

En complément de cette technique, OAuthSD permet d’Incorporer au jeton JWT des déclarations supplémentaires.

Rappelons que le serveur d’authentification est transparent par rapport aux portées (scopes) non réservées et aux déclarations (claims) "non standard" : c’est à la ressource protégée de définir ce qui doit en être fait en fonction d’une application donnée.

Notes

[1Tellement particulier qu’ils n’ont rien à voir avec une portée d’autorisation, mais nous apparaissent plutôt comme un moyen de paramétrer les flux. Il y a peut-être là un défaut conceptuel d’OpenID Connect ?

[2Jusqu’à quel point étendre la définition des scopes ? Nous discutons la question ici : /web/-OpenID-Connect-UserInfo-.html. Facebook définit une centaine de scopes ! Mais, dans la perspective du contrôle de l’accès aux web-services et aux API, l’utilisation des scopes peut aller beaucoup plus loin que la seule modulation de Userinfo. Google fait un usage étendu des scopes pour autoriser l’accès aux différentes API. GitHub utilise les scopes pour moduler les accès des utilisateurs aux différentes fonctionnalités. Il s’agit là d’applications propriétaire et donc d’une implémentation très particulière d’OpenID Connect qui montre deux choses : OpenID connect est beaucoup plus qu’un SSO ; A l’opposé de l’idée d’un système d’authentification universel (permettant l’accès à des applications quelconque avec un seul identifiant), le contrôle de l’accès aux applications et au données ne peut se faire que dans un système propriétaire.

[3Comme prévu par la norme : voir Portée de l’autorisation (Scope).

[4Notez qu’il faut distinguer le claim "profile" et le scope "profile". La définition des scopes est bien embrouillée !