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.
RSS 2.0