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

Définition des scopes OIDC 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.

DnC donne un exemple d’application de la transmission des portées d’autorisation avec DnC SaaS.

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 indique au serveur d’interpréter les requêtes faites aux points d’entrée selon les spécifications d’OpenID Connect.

- 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 les scopes standard définis par OpenID Connect ou définis à l’initiative du concepteur de l’application [2]. Nous proposons de les appeler déclarations privées (private scopes).

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 ces scopes selon deux cas de figure [3] :
- soit les données protégées sont la propriété de l’utilisateur, et ces 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 ces 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).

Incorporer au jeton d’identité des déclarations supplémentaires

Précisons 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 dans le cadre d’une application donnée.

OAuthSD offre trois approches complémentaires pour incorporer des déclarations supplémentaires dans le jeton d’identification :

1. 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 "profil" [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 "profil" 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.

2. 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.

3. Pour les développeurs : une technique pour incorporer par programme des déclarations supplémentaires au jeton JWT
En complément des techniques précédentes, OAuthSD permet d’Incorporer au jeton JWT des déclarations supplémentaires. Bien que nous présentions cette méthode en dernier, c’est sans doute celle qui intéressera le plus les développeurs. DnC applique cette technique pour réaliser DnC SaaS.

DnC SaaS : système de diffusion d’applications en tant que service

DnC SaaS couple un système de vente en ligne à un serveur OIDC ( OAuthSD bien évidemment) afin de louer des services en ligne SaaS - Software as Service.

Le logiciel mis en location est configuré comme application cliente du serveur OIDC.

Au moment de l’authentification de l’utilisateur final, le module d’identification du contrôleur Authorize fait appel au système de vente en ligne pour vérifier que l’utilisateur est à jour de ses paiements.

Cette étape permet également de définir les privilèges de l’utilisateur final sur l’application, par exemple :
- la validation d’éventuelles options de l’application prises avec l’abonnement,
- des droits limités (consultation seule ...) au cours d’un délai de grâce après échéance,
- etc.
Les privilèges sont incorporés dans la charge utile du jeton d’identité (ID Token) sous la forme de déclarations supplémentaires. Les noms des déclarations et les valeurs transmises sont propres à l’application considéré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 sémantique d’OpenID Connect ? Notons qu’IBM désigne cela sous le terme de "client metadata", ce qui parait pertinent.

[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 "profil" et le scope "profile". La définition des scopes est bien embrouillée !