Cette suite d’article s’adresse aux personnes qui sont à la recherche d’un remède pour les mobiles en terme de SSO et qui souhaitent comprendre les solutions que l’on trouve sur le marché.

Effectivement, on voit de plus en plus d’entreprises développer la mobilité et l’utilisation de « device » mobiles tels que les tablettes et les smartphones. Dans le même temps, et logiquement, de plus en plus d’applications mobiles sont utilisées dans le cadre professionnel. Cependant ce n’est pas parce que nous sommes dans de nouveaux usages qu’il faut oublier la sécurité et permettre une expérience utilisateur agréable.

Ce qu’on voit le plus mis en place pour sécuriser l’accès aux applications mobiles est l’utilisation d’un login mot de passe. Malheureusement, sur ces nouveaux « devices » nous faisons face à de nouvelles épidémies (certaines que l’on connait depuis bien longtemps et de nouvelles) :

• La prolifération de mots de passe (déjà bien connue dans le cadre des applications web ou autres) même si dans le cas des applications mobiles on peut imaginer mettre en place du CSO (Common Sign-On, un mot de passe unique pour accéder aux différentes applications)
• Les « gros pouces », maladie déjà bien connue des joueurs de jeux vidéo mais qui dans le cadre des applications mobiles revient à devoir renseigner plusieurs fois ses login/mots de passe sur un clavier où l’erreur est vite arrivée.

Maintenant que la problématique est exposée, regardons ce que l’on trouve aujourd’hui, ce que l’on peut imaginer et comment ça se passe.

Aujourd’hui (SAML+OAuth)

SAML

La fédération des identités (via SAMLv2) est déjà bien implantée dans le monde du SSO et utilisée par de nombreuses entreprises. Voici un rappel rapide de ce qu’il s’agit :

L’objectif est clair, il est de pouvoir authentifier l’utilisateur de façon centralisée et de lui permettre l’accès à des applications  aussi bien dans le domaine de l’entreprise,  des partenaires ainsi que sur des applications SaaS.

OAuth

Passons à une présentation simplifiée du protocole OAuth qui nous rapproche du monde mobile (même si OAuth n’est pas propre au mobile).

Ce qu’il faut noter sur OAuth, c’est qu’il s’agit d’autorisation. Effectivement, l’objectif est d’autoriser un client (une application mobile par exemple) à avoir accès à une ressource via l’approbation de l’utilisateur. Il faut aussi voir qu’une fois que l’utilisateur a donné son approbation et que le client a obtenu un token il sera à même de l’utiliser durant sa durée de vie.

Le mixte 

Maintenant regardons ce que ça donne en terme de SSO de mélanger les deux protocoles.

Description du schéma :

1- Le client (l’application mobile) souhaite accéder à une ressource

2- L’application n’ayant pas les autorisations nécessaires, fait en sorte que l’utilisateur aille approuver les autorisations qui lui sont nécessaires. Pour se faire, l’application redirige l’utilisateur vers l’ « authorization server » via un browser system.

3- L’authorization server (ici considéré comme SP) redirige l’utilisateur vers l’IdP pour que l’utilisateur soit authentifié

4- L’utilisateur s’authentifie

5- L’utilisateur est redirigé vers l’authorization server pour approuver les autorisations demandées, souhaitées par l’application

6- Une fois cette phase effectuée, l’application récupère un « authorization code »

7- L’application utilise cet « authorization code » pour récupérer un « access token »

8- Une fois l’access token récupéré, l’application peut l’utiliser pour avoir accès à la ressource.

D’un point de vue OAuth, ici nous décrivons le flux Oauth appelé « Authorization code ».

Maintenant, si l’utilisateur souhaite utiliser une nouvelle application, lorsque cette nouvelle application souhaitera récupérer un token, il suffira qu’elle redirige l’utilisateur vers l’authorization server via le navigateur système. Lors de la redirection vers l’IdP, l’authentification précédemment effectuée pourra être récupérée et de ce fait, l’utilisateur n’aura pas besoin d’entrer à nouveau son login/mot de passe.

La problématique dans ce cas d’usage vient principalement de l’utilisation du navigateur système qui n’est pas forcément évidente. Pourquoi jusqu’à présent, je n’ai pas mentionné l’utilisation de web view ? Tout simplement car dans ce cas d’usage, il faut proscrire l’utilisation de web view pour deux raisons :

• Il n’y a pas de partage de session entre les web view donc impossible d’avoir de SSO
• Au niveau de la sécurité, il est déconseillé d’utiliser des web view car l’application peut intercepter tout ce qui y sera fait. Dans le cas présenté, la saisie du login mot de passe.

Dans la prochaine partie,  OpenId Connect et NAPPS seront présentés pour montrer ce qu’ils apportent pour répondre à la problématique du SSO mobile.