🎯 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 :