[:fr]
Nous voici dans la deuxième partie de « Que faire en terme de SSO Mobile ». Pour ceux qui auraient manqué la première partie, elle est ici. L’objectif de cette série d’article a pour but d’expliquer et d’apporter un début de réponse à la problématique du SSO Mobile. Le SSO mobile devient un enjeu majeur pour les entreprises qui s’ouvrent de plus en plus à la mobilité et à l’utilisation d’applications mobiles pour tablettes et smartphones.
OpenID Connect
Avant de rentrer dans le cœur du sujet en parlant de NAPPS, il faut parler d’OpenID Connect. En tant que partisan du « simple et efficace », voici la définition qui pourrait être donnée à NAPPS :
NAPPS est un profil d’OpenID Connect
Si vous n’êtes pas familier avec OpenID Connect, cette définition ne vous parle pas forcément. Nous allons donc chercher à comprendre ce qui se cache sous cette définition.
Commençons par parler un peu d’OpenID Connect et voici une nouvelle définition « simple et efficace » :
OpenID Connect est une extension d’OAuth permettant de faire de l’authentification.
On arrive sur OAuth dont on a déjà parlé dans la partie I. Le schéma ci-dessous montre, de façon simplifiée, comment fonctionne OpenID Connect par rapport à OAuth.
Ce qu’il faut noter est qu’OpenID Connect permet à un client (une application) d’authentifier l’utilisateur. Contrairement à OAuth qui sert à autoriser l’accès à une ressource. En d’autres termes, lorsqu’on utilise OpenID Connect, la ressource pour laquelle le client cherche à être autorisé est l’identité de l’utilisateur (le Ressource Owner dans le vocabulaire OAuth).
Maintenant, la problématique du SSO se pose car l’ « access token » et le « token ID » sont générés pour un client (application) donné et ne peuvent être partagés. Cela implique qu’à chaque client (application), l’utilisateur sera amené à s’authentifier pour que les tokens soient fournis au client. C’est cette problématique que va chercher à résoudre NAPPS.
NAPPS
Après la cinématique OpenID Connect, voici la cinématique de NAPPS :
Pour bien comprendre les échanges qui entrent en jeu, voici un descriptif de chaque étape :
1- L’application fait la demande d’un code ACDC (Authorization Cross Domain Code) auprès du Token Agent [TA] (avec un challenge [Décrit dans le standard Proof Key for Code Echange (PKCE)])
2-Le TA souhaite obtenir un ‘authorization code’. L’utilisateur est donc redirigé vers ‘l’autorisation server’ pour s’authentifier
3- L’utilisateur s’authentifie
4-Le TA obtient un ‘authorization code’
5-Le TA demande un ‘refresh token’ [RT]
6-Le TA obtient un RT
7- Le TA utilise le RT pour obtenir un ACDC
8-Le TA fournit l’ACDC à l’application
9-L’application utilise l’ACDC (avec un code de vérification [PKCE])
10-L’application obtient un ‘access token’ [AT] et un RT
11-L’application utilise AT
12-La seconde application demande un ACDC (avec un challenge [PKCE])
13-Le TA utilise le RT obtenu à l’étape 6 pour obtenir un nouvel ACDC
14-L’ACDC est transmis à l’application
15-L’application utilise l’ACDC pour obtenir un AT et un RT (avec un code de vérification [PKCE])
16-L’application utilise AT pour avoir accès à la ressource
Après la présentation de la cinématique, les avantages de NAPPS sont évidents :
- L’utilisateur ne s’authentifie qu’une seule fois pour autoriser le TA
- Toutes les applications utilisent le TA pour obtenir leur AT
- L’utilisateur connait une vraie expérience de SSO.
On s’aperçoit qu’avec NAPPS et la mise en place d’un Token Agent, cela aurait pu chambouler le monde du SSO Mobile. Cependant, cela semble avoir donné envie aux éditeurs d’Android et d’iOS de mettre en place des WebView 2.0 qui permettent de résoudre le problème de la non conservation des sessions entre les WebView. Nous y reviendrons dans le prochain article.
On pourrait se dire que le travail autour de NAPPS a donc été vain mais il est possible de le voir arriver avec l’Internet des Objets (IoT). Et si les travaux autour de NAPPS ont pu influencer l’évolution et la sortie de nouvel WebVeiw, c’est une bonne chose.
Aurélien
Consultant sécurité
[:]
