🔐 Comprendre la connexion SSO dans les Webviews et les MicroApps

🎯 Objectif

Cet article vise à expliquer le fonctionnement de la connexion Single Sign-On (SSO) dans les Webviews et les MicroApps, en mettant en lumière les différences en termes de persistance de session et de mécanismes d'authentification.

🧭 Définitions clés

Webview

Une Webview est un composant intégré dans une application mobile qui permet d'afficher du contenu web. Elle agit comme un navigateur embarqué, offrant une expérience utilisateur fluide sans quitter l'application.

MicroApp

Une MicroApp est une fonctionnalité autonome intégrée dans une application principale. Elle interagit généralement avec des services backend via des API, sans nécessiter d'interface web.

🔐 Fonctionnement du SSO dans les Webviews

🔄 Partage de session

Dans une application mobile, une seule instance de Webview est généralement utilisée. Cela signifie que :

Les cookies de session sont partagés entre les différentes Webviews.
Une fois l'utilisateur authentifié via SSO dans une Webview, la session reste active pour les autres services accessibles via Webview, tant que la session n'a pas expiré.

Par exemple, si un étudiant se connecte à un service de logement via SSO dans une Webview, il n'aura pas besoin de se reconnecter pour accéder à un autre service utilisant la même instance de Webview.

⚠️ Limitations

Il est important de noter que :

La persistance de la session dépend de la validité des cookies. Si les cookies expirent ou sont supprimés, une nouvelle authentification sera nécessaire.
Les Webviews ne partagent pas les cookies avec les navigateurs externes. Ainsi, une session active dans une Webview n'est pas reconnue dans le navigateur natif de l'appareil, et vice versa.

🤖 Fonctionnement du SSO dans les MicroApps

Les MicroApps ne reposent pas sur des Webviews pour l'authentification. À la place, elles utilisent des mécanismes de Machine-to-Machine (M2M) pour interagir avec les services backend.

🔐 Authentification M2M

Dans ce contexte :

L'application mobile agit en tant que client de confiance, s'authentifiant auprès du service backend via des tokens d'accès obtenus grâce au flux de Client Credentials d'OAuth 2.0.
Aucune interaction utilisateur n'est requise pour l'authentification, car les identifiants sont échangés directement entre machines.

Ce mécanisme est particulièrement adapté pour des services nécessitant une communication sécurisée entre applications, sans intervention humaine.

📊 Comparaison entre Webviews et MicroApps

Caractéristique	Webview	MicroApp
Type d'authentification	SSO via navigateur intégré	Authentification M2M via API
Persistance de session	Dépend des cookies de session	Gérée par des tokens d'accès avec expiration
Interaction utilisateur	Requiert une action de connexion initiale	Aucune, tout est géré en arrière-plan
Partage de session	Possible entre Webviews de la même instance	Non applicable

✅ Bonnes pratiques

Webviews :
- Assurez-vous que les cookies de session sont correctement gérés et persistants pour maintenir la connexion SSO.
- Informez les utilisateurs que la session peut expirer et qu'une reconnexion pourrait être nécessaire.
MicroApps :
- Utilisez des tokens d'accès avec des durées de vie appropriées pour équilibrer sécurité et performance.
- Implémentez des mécanismes de rafraîchissement des tokens si nécessaire.

En comprenant les différences entre les Webviews et les MicroApps en matière de SSO, vous pouvez choisir la solution la plus adaptée à vos besoins, tout en garantissant une expérience utilisateur fluide et sécurisée.

Ressources utiles :

Tout savoir sur les SSO