Accueil > OpenID Connect OAuth Serveur dédié > Développer > Portée de l’autorisation (Scope)

Portée de l’autorisation (Scope)

Les Scopes définissent l’étendue des droits (les actions permises sur les données de la ressource protégée) attachés au jeton d’accès qui est transmis par l’application cliente aux applications tierces (Serveurs de ressources). Celles-ci énumèrent les scopes attachés à l’autorisation ; elles ont la responsabilité d’agir en conséquence pour permettre ou non l’accès de l’application cliente aux données protégées.

Il est important de noter que les droits portés par un scope ne dépendent que de la façon dont l’application tierce en tient compte (ou non). Autrement dit, l’application tierce doit être une application de confiance, parfaitement identifiable par l’utilisateur final. De même, l’utilisateur final doit être authentifié. OAuth Server by DnC s’attache à apporter des solutions innovantes pour la qualification des applications et des utilisateurs, ce qui constitue une grande part de sa valeur ajoutée.

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.

Notes

[1C’est souvent beaucoup plus simple que cela : l’application signale les scopes qu’elle demande, et l’utilisateur final termine la procédure si les données réclamées (claims) lui conviennent, ou il abandonne.

[2Ou plus généralement "par l’implémentation". En effet, le concepteur de l’application cliente définit les scopes en fonction de ce qu’elle attend et de ce qu’elle en fait. Mais les scopes autorisés pour une application cliente peuvent être utilisés ou non, assortis éventuellement d’un paramètre, en fonction des droits que l’on veut accorder à l’utilisateur final. Ceci peut aussi bien être déterminé par le serveur d’authentification au moment où l’on crée le jeton, en fonction de conditions extérieures à l’application cliente.