OpenID Connect OAuth Server dédié

Demande de consentement : différents cas de figure

Dès leur origine, OAuth et OpenID Connect ont été pensés pour protéger les données sensibles appartenant à l’utilisateur final, à qui on demande l’autorisation d’y accéder. Le vocabulaire utilisé et les exemples donnés dans les spécifications sont fortement orientés par cette vision.

Cependant, la réalité des applications ne se limite pas à ce cas de figure : l’utilisateur de l’application peut être distinct du propriétaire des données. Heureusement, OpenID Connect offre un ensemble de techniques qui permettent de s’assurer que l’utilisateur final est bien celui qu’il prétend être et autoriser son accès à des ressources protégées ou des applications qui contiennent des données sensibles, lui appartenant ou non.

Toute la problématique du consentement réside dans la position 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)).

Il faut considérer deux paradigmes pour la mise en oeuvre de l’authentification :

1 - L’utilisateur final est connecté à une application qui travaille sur ses données personnelles.

C’est la situation qui a orienté la description d’OAuth et OpenID dès leur origine et qui imprègne fortement OpenID Connect avec les données UserInfo. Celles-ci sont segmentées par portée (scope) de façon à n’accéder qu’aux données nécessaires à un moment donné. La spécification permet de définir de nouveaux scopes et d’étendre les données personnelles.

Dans ce cas, il convient de présenter à l’utilisateur une demande de consentement pour chaque portée d’autorisation [1].

C’est parce-que ce paradigme soustend la conception d’OIDC que l’authentification de l’application cliente a été négligée, ce qui se manifeste par l’existence des flux implicites et hybrides qui ne permettent pas cette authentification. De ce point de vue en effet, c’est l’utilisateur qui a choisi l’application et qui, de ce fait, a la responsabilité de la déclarer "application de confiance". Ceci dit, ces flux laissent la porte grande ouverte à des malwares opérant du côté de l’user-agent, ce qui échappe au contrôle de l’utilisateur final.

2 - L’utilisateur final est connecté à une application à laquelle il fournit des informations personnelles auxquelles des tiers accéderont ultérieurement.

Il s’agit donc d’une application à laquelle des tiers authentifiés peuvent se connecter avec un rôle déterminé, leur permettant de consulter ou exploiter les données personnelles.

Ce cas peut être traité de la façon suivante :

B1 - Il est présenté à l’utilisateur final propriétaire des données un avertissement au moment où il entre dans l’application, libellé en tenant compte des scopes que l’application est susceptible d’utiliser.

B2 - Il est présenté une demande d’autorisation au moment où l’utilisateur introduit ses données personnelles dans l’application.

Nous pourrions mentionner aussi la solution de facilité qui consiste à :

B0 - faire approuver, avant toute utilisation, des conditions générales qui évoquent de façon plus ou moins détaillée les traitements effectués sur les données personnelles. Parfois, cette façon de faire ne distingue même pas le propriétaire des autres utilisateurs. Elle peut également être utilisée pour s’octroyer la dispense d’appliquer le cas A.

L’idéal serait de demander l’autorisation d’accès au cours de l’utilisation de l’application par un tiers : "Bonjour M. Dupont. M. Tournesol souhaite accéder à vos données scope1, scope2 etc. avec l’application Truc."

On pourrait imaginer :

B3 - un échange d’E-mail, avec toute la difficulté liée aux délai de réponse, voire à la non-réponse. On imagine difficilement faire cela au cours de chaque session. Il serait plus praticable de le faire périodiquement, ou lorsqu’une nouvelle application ou un nouvel agent souhaite accéder aux données.

B4 - Une application dans laquelle les deux parties sont connectées. C’est le cas d’une application à laquelle le propriétaire des données se connecte et échange avec un agent (par exemple un chat avec un conseiller) qui a besoin d’accéder aux données personnelles au cours de la conversation. Les demandes de consentement pourraient être présentées en temps réel à l’utilisateur final. C’est parfaitement possible, mais cela ne semble pas une pratique courante. Une difficulté réside dans le fait que l’on donnerait l’impression à l’utilisateur final que l’on s’interdirait d’accéder aux données personnelles en dehors de cette procédure.

La mise en oeuvre des demandes de consentement par OAuthSD

La plupart des cas de figure ci-dessus devront être traités différemment selon l’application. Tel quel, OpenID Connect offre les moyens de gérer ces situations au prix de nombreux aller-retours entre le serveur et l’application cliente, à laquelle il appartiendra de développer la logique.

Un des objectifs d’OAuthSD est de simplifier l’écriture des applications clientes en intégrant le plus possible de fonctionnalités dans le serveur d’authentification/autorisation.
Le cas A est le cas standard auquel OAuthSD répond conformément aux spécifications. Sans prétendre prendre totalement en charge chacun des autres cas présentés ci-dessus, OAuthSD offre des facilités décrites dans ce qui suit.

La gestion "standard" des consentements

La spécification d’OpenID Connect permet de traiter pleinement le cas A et offre des outils pour les autres cas.

Le paramètre d’URL scope détermine quelles sont les portées d’autorisation demandées par l’application cliente.
Seuls les scopes non-réservés, auxquels s’ajoute le scope offline_access, feront l’objet d’une demande de consentement (les autres ont un caractère technique).

Notes :
 La notion de scope est un fourre-tout décrit ici : Définition des scopes OIDC et généralités sur leur utilisation par les applications.

La présentation de la demande de consentement dépend du paramètre d’URL prompt présent dans la requête passée au contrôleur Authorize [2].
 Si prompt est égal à ’none’ ou ’login’, aucun consentement n’est demandé à l’utilisateur final.
 Si prompt est omis [3], ou est égal à ’consent’ ou ’login consent’, les demandes de consentement sont présentées à l’utilisateur final.

Une bonne pratique de la gestion des consentements consiste à attendre pour les demander que l’application ait besoin d’accéder aux données correspondantes, et non systématiquement dès l’entrée dans l’application. Ceci se fait en appelant le contrôleur Authorize avec le paramètre prompt = ’consent’.
Cependant, si l’utilisateur n’est pas ou plus connecté à ce moment, il y aura un retour d’erreur.