L’utilisation d’API Webservices se systématisant pour les échanges inter-applicatifs, comme nous l’avons expliqué dans un précédent article intitulé "Les API, c'est quoi ?", de nombreuses questions se posent pour sécuriser l’accès à des données exposées par ces API.
On distingue classiquement plusieurs couches de sécurisation :
- Cryptage des flux
- Authentification des applications
Et des solutions standard peuvent être mises en place, que ce soit SSL/TLS pour la partie cryptage, de l’authentification Basic (login/password) ou par certificat pour la partie identité et autorisation d’accès.
Cependant, dû à la nature des échanges (inter-applicatif) et des données (le plus souvent personnelles et/ou soumises à autorisation d’accès), une question légèrement différente est souvent posée, et concerne l’autorisation ou la délégation d’autorisation.
Le Web moderne nous permet souvent d’autoriser une application tierce à accéder à certaines ressources “en notre nom” et ce (heureusement !), sans partager nos identités numériques complètes avec cette application tierce. Facebook, Google, et beaucoup d’autres permettent cette délégation et pour autant, nos identifiants restent notre propriété et nous pouvons administrer (et répudier) ces autorisations.
C’est cela (entre autres) qu’Oauth2 permet, comme nous allons le détailler dans les paragraphes suivants.
Afin de rester simples et concis, nous n’aborderons que les cas d’autorisation explicites, via code échangé entre 2 applications « serveur » (nous n’aborderons pas le cas des applications Web clientes (Javascript)), légèrement différent.
Attention, OAuth2 ne remplace pas les solutions SSO comme SAML. En effet, OAuth2 reste destiné à sécuriser les échanges par API, là où SAML (par exemple) sécurise les accès via cookie, et donc session web classique, simple dans un navigateur, moins utile coté applicative. Par ailleurs, OAuth2 n’est pas réellement une solution d’authentification, mais d’autorisation (et de delegation d’autorisation). La question n’est pas tellement “qui vous êtes” mais “avez-vous le droit de faire cela”. Subtile comme différence, mais d’importance.
Rôles et jetons d’accès
OAuth2 définit 4 rôles dans un scenario classique de delegation:
- L’utilisateur détenant des données (Resource Owner).
- Le serveur de ressources (Resource Server).
- L’application client (Client Application) souhaitant accéder sur le serveur de ressources aux données de l’utilisateur.
- Le serveur d’autorisation tiers (Authorization Server), délivrant des jetons permettant l’accès aux ressources. Parfois, on confondra les deux serveurs (Resource et Authorization) pour des raisons de simplicité. Cela ne change absolument rien à ce qui va suivre (les deux services restant bien séparés).
Les applications clientes sont également enregistrées (via un mécanisme à définir) coté serveur d’autorisation.
Les jetons sont générés par le serveur d’autorisation lorsque le détenteur de la resource l’y autorise (et que l’application cliente est connue). Deux types de jetons sont prévus:
- Les jetons d’accès (Access Token) permettent d’accéder à la ressource. Ils ont une durée de vie limitée dans le temps (définie au niveau du serveur d’autorisation). Ces jetons définissent généralement la resource cible et le périmètre d’accès à cette ressource (lecture, écriture, suppression,…). En l’absence de définition, c’est le serveur d’autorisation qui porte la liste des ressources et des périmètres, qui définit des valeurs par défaut.
- Les jetons de rafraichissement (Refresh Token), non obligatoires, voire dans certain cas (ressources critiques ou très confidentielles) déconseillés. Ces jetons permettent à l’application client, en cas d’expiration du jeton d’accès, de redemander un nouveau jeton sans que l’utilisateur soit sollicité.
Il est possible, en particulier lors de la mise en place de jetons de rafraîchissement, de verifier et de répudier les accès autorisés par un utilisateur à une application cliente.
Lors de la première demande via l’application cliente, l’utilisateur est donc redirigé vers le serveur d’autorisation, qui va lui demander de s’identifier et d’autoriser ou pas l’application cliente à accéder aux ressources qu’elle souhaite. Si l’utilisateur donne son accord, un code d’autorisation (généralement une longue chaîne aléatoire, mais d’autre protocoles sont possibles) est transmis directement et de façon sécurisée entre le serveur d’autorisation et l’application cliente. Ce jeton est ensuite utilisé dans les headers des requêtes HTTP vers le serveur de ressource.
Lors d’un accès par une application cliente via jeton, il est évidemment de la responsabilité du serveur de ressources de vérifier l’authenticité, la validité et la non-répudiation du jeton fourni (via accès au serveur d’autorisation, ou via d’autres méthodes qui dépassent la spécification Ouath2).
Mot de la fin
OAuth2 est un standard qui permet d'implémenter de nombreuses fonctions, en particulier comme nous l’avons vu la délégation d’autorisation.
Pour une application comme Spark Archives, et plus généralement pour un système d'archivage électronique (SAE), l’intégration de plus en plus forte au sein des systèmes d’information, se fait via des API. Si l’on souhaite envisager de permettre à des applications tierces (une GED par exemple, ou un driver d’impression,…) de verser à la place d’un utilisateur donné, alors OAuth2 va permettre de le faire en simplifiant l’intégration et en limitant les besoins de partage de données d’authentification, ce qui est bien mieux d’un point de vue sécurisation.
Pour des intégrations plus poussées, ou pour des systèmes de versement/téléchargement complètement intégrés ou aucun utilisateur humain n’intervient, alors des solutions plus classiques de sécurisation (TLS et authentification classique par certificat) peuvent être plus pertinentes.
Jérôme Besnard
Responsable R&D Spark Archives
Nous contacter
