Définition
L’attribut "scope" est défini dans la section 3.3 de la [RFC6749].
L’attribut "scope" est une liste de valeurs sensibles à la casse, délimitées par des espaces, indiquant la portée requise du jeton d’accès pour accéder à la ressource demandée.
Les valeurs "scope" sont définies par l’implémentation ; il n’y a pas de registre centralisé pour eux ; les valeurs autorisées sont définies par le serveur d’autorisation.
L’ordre des valeurs "scope" n’est pas significatif.
Dans certains cas, la valeur "scope" sera utilisée lors de la demande d’un nouveau jeton d’accès avec une étendue d’accès suffisante pour utiliser la ressource protégée.
L’utilisation de l’attribut "scope" est OPTIONNELLE.
L’attribut "scope" NE DOIT PAS apparaître plus d’une fois.
Deux cas de figure
La norme OAuth 2.0 (RFC 6749) distingue deux cas de figure dans lesquels les scopes seront utilisés différemment :
1. L’utilisateur final est propriétaire des données protégées, et c’est donc lui qui autorise l’accès à ses données par les applications clientes tierces. Pour cela il sélectionne les scopes parmi ceux qui lui sont présentés au moment de la procédure d’autorisation. Le serveur de ressource ne doit permettre l’accès qu’aux ressources autorisées en fonction des scopes sélectionnés. [1].
2. L’application cliente est elle-même propriétaire des données situées sur les serveurs de ressources : elle autorise l’utilisateur final à accéder à ces données en son nom propre. Dans ce cas, les scopes sont définis par l’application cliente [2]. Il est important de considérer que cela donne à l’application cliente le moyen de moduler les autorisations selon le statut ou le profil de l’utilisateur, ce qui est un mécanisme très puissant puisque cette modulation de l’autorisation est propagée aux applications tierces.
Voyez également Identity by DnC qui apporte une solution innovante pour moduler les scopes selon le profil des utilisateurs.
La norme OAuth 2.0 ne donne pas un jeu de scopes prédéfini
OAuth définit les scopes et les mécanismes attachés de façon très générale. Rappelons que OAuth sert de base à différents protocoles qui en font un usage différent selon les applications.
Un jeu de scopes peut être défini à la fois pour segmenter un ensemble de données en sous-ensembles (diviser un profil en identité, adresse postale, données personnelle etc.), ou pour définir les actions (lecture, écriture, suppression etc.) permises sur les données, ou ces deux usages simultanément.
On voit qu’ils dépendent de la nature des ressources et de l’utilisation que pourraient en faire les applications clientes. Les scopes peuvent donc être très variés.
Un serveur OAuth suivant la norme OAuth 2.0 (comme c’est le cas de OAuth Server by DnC) doit donc être totalement transparent à leur définition et à leur usage :
les scopes sont définis par le concepteur du serveur de ressources,
c’est au serveur de ressource d’assurer le respect des autorisations définies par les scopes accompagnant le jeton d’accès au moment de la requête,
les scopes qu’une application cliente peut utiliser sont librement définis au moment de son inscription sur le serveur d’autorisation.
Ceci a des conséquences très importantes :
Soit les scopes ont une définition très générale, et le serveur de ressource peut répondre à des requêtes en provenance d’application clientes qui lui sont totalement étrangères,
Soit les scopes ont une signification plus précise, et les serveurs de ressources comme les applications clientes doivent avoir une connaissance mutuelle. Cela peut se produire dans le cadre d’un protocole particulier, dans un ensemble particulier d’applications ou dans un espace contrôlé par une organisation (corporate realm).
OpenID Connect : une définition ouverte des scopes
OpenID Connect est un protocole d’authentification construit sur OAuth.
Concernant les scopes, OpenID connect définit un jeu de scopes standards, adaptés à la fonction d’authentification de l’utilisateur final, mais permet également l’utilisation de scopes particuliers.
RSS 2.0