Le jeton au format JWT présente les avantages suivants :
C’est une spécification connue, largement adopté, et des bibliothèques client disponibles dans de nombreux langages (voyez Adaptation des applications).
Il facilite la signature et la vérification à l’aide de bibliothèques cryptographiques validées.
Puisqu’il peut être décodé au format JSON, cela permet d’inclure des métadonnées et des informations sur le jeton, ainsi que des données complémentaires pour l’application à laquelle il est adressé.
Tant que le serveur d’autorisations et le serveur de ressources s’accordent sur la signification du jeton, le contenu n’a aucune importance. Ce qui signifie que soit on colle au standard OpenID Connect, et alors le serveur de ressource est limité à UserInfo, soit on est dans un espace propriétaire (corporate realm) où l’on fait ce que l’on veut.
Avant d’aborder les utilisations possibles, il faut bien considérer que :
Le jeton d’identité doit être vérifié dès réception par l’application cliente ou la ressource protégée, avant toute utilisation.
Il existe deux méthodes : la validation locale du JWS ou l’introspection.
Ceci étant acquis, on peut citer les applications suivantes :
Passage d’identité à des tiers - Le jeton ID peut être transmis à d’autres composants d’application ou à des services d’arrière-plan lorsque la connaissance de l’identité de l’utilisateur (end-user) est requise, par exemple pour identifier les enregistrements d’un historique.
Il est également possible à une application de passer le jeton pour obtenir l’accès à une ressource protégée, à charge pour celle-ci de le valider en mentionnant l’IP de l’appelant.
Il est possible de moduler la réponse de la ressource en fonction des privilèges de l’utilisateur en adaptant les scopes transmis à cet usage. Ceci est largement développé dans cet article : Définition des scopes OIDC et généralités sur leur utilisation par les applications et dans les articles connexes.
SaaS - Software as Service - Une des possibilités les plus intéressantes offertes par OAuthSD consiste à ajouter des déclarations dans le jeton d’identité. On peut ainsi coupler un système de vente en ligne à un serveur OIDC afin de louer des services en ligne. Le logiciel mis en location est configuré comme application cliente du serveur OIDC.
Au moment de l’authentification de l’utilisateur final, le module d’identification du contrôleur Authorize fait appel au système de vente en ligne pour vérifier que l’utilisateur est à jour de ses paiements.
Cette étape permet également de définir les privilèges de l’utilisateur final sur l’application, par exemple :
la validation d’éventuelles options de l’application prises avec l’abonnement,
des droits limités (consultation seule ...) au cours d’un délai de grâce après échéance,
etc.
Les privilèges sont incorporés dans la charge utile du jeton d’identité (ID Token) sous la forme de déclarations supplémentaires. Les noms des déclarations et les valeurs transmises sont propres à l’application considérée.
DnC a développé le système DnC SaaS qui a très largement contribué à la mise au point du serveur OAuthSD.
Sessions sans état - Le jeton d’identification peut être implémenté dans un cookie de navigateur. Cela supprime la nécessité de stocker des sessions côté serveur (en mémoire ou sur disque), ce qui peut être un fardeau pour la gestion et la montée en échelle. La session est vérifiée en validant localement le jeton d’identification. Lorsque le jeton atteint sa limite de validité (exp), l’application peut simplement en demander un nouveau à l’OP via une ré-authentification silencieuse prompt = none.
Cette utilisation du jeton est souvent associée à la gestion de session des applications à page unique (Single Page Application, SPA) [1].
Notes :
ll s’agit bien de JWT stockés en cookie. Pas d’utiliser le JWT comme moyen d’assurer la rétention de session en passant le JWT dans l’URL, ce qui serait une aberration de sécurité.
Le stockage des JWT par HTML5 Storage, ou toute autre méthode nécessitant JavaScript pour relire le jeton ouvre la porte à des attaques de type CSRF.
Voici un exemple qui montre comment utiliser le jeton pour simuler une session en chaînant les pages avec l’id de l’utilisateur final (user_id) :
PHP
- ...
- // Tenter de récupérer l'user_id depuis le JWT du cookie
- $GLOBALS['user_id'] = null;
- $prompt = 'login';
- // Le JWT du cookie est valide et nous donne l'user_id
- $GLOBALS['user_id'] = $decoded_jwt['sub'];
- } else {
- // Demander un nouveau jeton sans réauthentification (prompt=none)
- $prompt = 'none';
- }
- }
- // sinon, il faut demander un jeton avec authentification de l'utilisateur
- ...
DnC a développé des applications de ce type. Par exemple, photos.dnc.global est une application sans base de données, dont les sessions sont fondées sur le JWT en cookie. On comprend l’intérêt pour la montée en échelle : une telle application peut être répartie sur de nombreux serveurs sans que le développeur ait à se soucier de réplication des données.
Echange de jetons - Le jeton ID peut être échangé contre un jeton d’accès au point de terminaison Token d’un serveur d’autorisations OAuth 2.0 ( cf. Draft IETF : Token Exchange ). Il existe des scénarios réels où un document d’identité est requis pour obtenir l’accès, par exemple lorsque vous vous enregistrez dans un hôtel pour obtenir la clé de votre chambre. L’échange de jetons a des utilisations dans les applications distribuées et d’entreprise.
RSS 2.0