Position du problème
Nous sommes ici au cœur du problème !
La norme OAuth 2.0 n’indique pas comment les serveurs de ressources (RS) qui reçoivent un jeton d’accès doivent procéder pour le valider.
La spécification OAuth 2.0, RFC6749, aborde cette question dans la section 7 :
"Les méthodes utilisées par le serveur de ressource pour valider le jeton d’accès (ainsi que toute réponse d’erreur) dépassent le cadre de cette spécification, mais impliquent généralement une interaction ou une coordination entre le serveur de ressources et le serveur d’autorisation".
Justin Richer traite magistralement ce sujet dans cet article : In OAuth 2.0, how do resource servers assert a token issued by an authorization server ? et se trouve à l’origine de ce document : RFC 7662 : OAuth 2.0 Token Introspection.
Eran Hammer, qui a activement contribué à l’élaboration de la norme, expose ce qui suit : OAuth v2 communication between authentication and resource server.
Deux cas se présentent :
1. Le serveur de ressource (RS) et le serveur d’autorisation (AS) sont colocalisés, ou communiquent par un canal sûr, comme un tunnel SSH. Dans tous les cas, ils appartiennent tous deux à une même organisation.
Le RS peut donc accéder aux informations nécessaires (comme la clé publique d’une paire publique/privée) pour décoder la signature.
La plupart des articles traitant de ce sujet s’appuient sur ce cas de figure pour sauter à pieds joints sur la technique de validation de la signature. Nous estimons que ce cas est trivial : si le RS communique de façon sûre avec l’AS, alors il n’est nullement besoin d’un serveur d’authentification.
2. Le serveur de ressource (RS) n’est pas directement lié au serveur d’autorisation (AS).
Dans ce cas, il existe deux familles de méthodes :
la première consiste à authentifier le jeton d’accès par interrogation du serveur d’autorisation (introspection).
la deuxième consiste à ce que l’application tierce assure localement l’authentification du jeton d’accès.
Ceci est développé dans ce qui suit :
Authentification du jeton d’accès par interrogation du serveur d’autorisation (introspection)
Cette méthode présente un avantage important : elle permet de savoir si le jeton a été révoqué avant la fin de sa période de validité.
Elle a cependant l’inconvénient d’augmenter le trafic avec le SA, ce qui peut être minimisé par une mise en cache des réponses du côté du RS.
OAuth Server by DnC offre des Points d’extrémité d’introspection pour OAuthSD et OpenID Connect auxquels les applications tierces peuvent s’adresser pour effectuer la validation du jeton d’accès.
Identity Server 3 et Word Perfect offrent également un point d’extrémité pour la validation du jeton d’accès.
Authentification du jeton d’accès par le serveur de ressource (RS)
Une approche un peu rapide d’OAuth peut laisser croire qu’il existe une magie permettant de valider localement un jeton d’accès sans que RS et AS ne soient aucunement liés. En fait, il faudra toujours une forme de secret partagé entre le RS et l’AS.
A ce point, il existe (encore) deux voies distinctes ( la très mauvaise et la bonne ) :
le cryptage symétrique du jeton (parfois appelé "jeton auto-décryptable"), qui n’est qu’une forme d’obfuscation si l’on considère la faible durée de vie d’un cryptage symétrique et la difficulté de partager la clé sans la compromettre.
Nous traiterons rapidement de l’obfuscation. Cette voie peut parfois s’avérer utile pour protéger des données peu sensibles contre les curieux et les robots.
Ainsi que le dit Fabio Galloneto dans l’article intitulé "Securing Sensitive Strings" : "Pour résoudre le problème, la première stratégie qui vient à l’esprit est l’obfuscation. ... la "sécurité par l’obscurité" n’est pas la sécurité. Cela vaut la peine de souligner que par définition un système sécurisé est « un système conçu de sorte que si quelqu’un sait tout sur le fonctionnement du système, il est toujours sécurisé » (voir le principe de Kerckhoff) et que l’obfuscation n’ajoute rien à la sécurité dans ce contexte."
la validation à l’aide de cryptage asymétrique (signature).
C’est encore Eran Hammer qui démontre la nécessité de signer les jetons pour authentifier : OAuth 2.0 (sans signature) est mauvais pour le Web :
"OAuth 2.0 supprime les signatures et la cryptographie en faveur des jetons portés, semblables aux cookies. En tant qu’éditeur d’OAuth 2.0, je suis associé au protocole OAuth 2.0 plus que la plupart des autres, et l’hypothèse est que je suis d’accord avec les décisions et les orientations prises par le protocole. Bien que le fait d’être éditeur donne un certain degré de contrôle temporaire sur la spécification, les décisions sont finalement prises par le groupe dans son ensemble (comme il se doit).
Et dans son ensemble, la communauté OAuth a commis une grave erreur (ndlr : en supprimant la signature des jetons) quant à l’orientation future du protocole. Une erreur qui fera d’OAuth 2.0 un agent de changement beaucoup moins important [1] sur le Web."
La recherche de la sécurité nous amène donc à faire valider le jeton (localement ou par introspection) par l’application tierce. C’est ce que permet la signature du jeton JWT (JSON Web Token).
Plusieurs implémentations utilisent un tel jeton :
OpenID Connect
Le protocole OpenID Connect utilise un jeton d’identité (ID Token) fondé sur JWT, signé cryptographiquement (JWS). La norme décrit comment une application cliente doit valider un ID Token reçu en réponse à une demande d’authentification. Un tiers (le serveur de ressource protégé notamment) peut évidemment appliquer la même méthode, à condition d’accéder aux informations nécessaires. La validation est effectuée notamment à l’aide d’une signature faisant appel à un cryptage asymétrique, mettant en œuvre une paire de clé publique-privée, ce qui suppose que l’application cliente accède à la clé publique.
OAuthSD offre toutes les réponses à ces questions :
Validation du jeton d’identité ID Token (JWT signé ou JWS),
OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo,
API OpenID Connect : Découverte.
Vérifier le jeton est une chose. Il est tout aussi important de vérifier que l’application qui le présente le détient légitimement (il peut s’agir d’un jeton volé), voyez :
Vérification de l’origine de la requête reçue par un serveur de ressource.
Différentes plateformes mettent en œuvre la validation du jeton d’identité :
Identity Server
IdentityServer3 : AccessTokenValidation
Google Identity Plateform
Exchange 2013
Exchange 2013 utilise aussi un jeton JWT pour le jeton d’identité, qui est similaire à l’ID Token défini par OpenID Connect. Il est donc intéressant de consulter les documents suivants :
RSS 2.0