Comment utiliser SAML pour les applications Single Page (SPA) et les applications mobiles ?
Pour faire court, si vous souhaitez utiliser SAML pour des SPA ou des applications mobiles sans avoir recours à un serveur backend, ce n’est pas possible. Ne partez pas tout de suite ! Il existe des moyens de contourner cette limitation. Dans cet article, nous explorerons comment utiliser SAML pour une application publique telle qu’une SPA ou une application mobile et nous fournirons les meilleures pratiques pour sécuriser votre application.
Limitations de SAML pour les applications publiques
SAML est un protocole qui nécessite une relation de confiance entre le fournisseur d’identité (IdP) et le fournisseur de services (SP). Cette relation de confiance est établie grâce à des clés de signature et de chiffrement partagées entre l’IdP et le SP. Le SP utilise ces clés pour vérifier l’authenticité de la réponse SAML et pour déchiffrer les assertions contenues dans la réponse.
Dans une application web traditionnelle, le SP est responsable de la validation de la réponse SAML et du déchiffrement des assertions. Cela se fait généralement côté serveur, où le SP a accès aux clés nécessaires et peut valider la réponse en toute sécurité. Mais dans une application publique comme une SPA ou une application mobile, le SP ne peut pas stocker de manière sécurisée les clés nécessaires pour valider la réponse SAML. Cela rend difficile l’implémentation de SAML dans ce type d’applications.
Solutions de contournement pour l’utilisation de SAML dans les applications publiques
Utiliser un serveur backend
Une façon de contourner cette limitation est d’utiliser un serveur backend pour gérer le flux d’authentification SAML. Le serveur backend peut stocker en toute sécurité les clés nécessaires pour valider la réponse SAML et peut gérer le déchiffrement et la validation de celle-ci. La SPA ou l’application mobile peut ensuite communiquer avec le serveur backend pour authentifier l’utilisateur et récupérer les informations nécessaires. Vous pouvez voir cela comme un proxy avec gestion de session ou un composant implémentant le pattern “Backend for Frontend” (BFF) incluant l’authentification et l’autorisation.
Arrêter d’utiliser SAML et passer à OAuth2/OpenID Connect
Une autre option consiste à abandonner SAML au profit d’OAuth2/OpenID Connect. Le fait est que SAML est assez ancien et a été conçu à une époque où le web était différent. Les applications publiques comme les SPA et les applications mobiles n’existaient pas à ce moment-là. OAuth2/OpenID Connect est plus moderne et est conçu pour fonctionner avec ce type d’applications. Il offre une meilleure expérience utilisateur et est plus facile à implémenter dans les applications publiques.
Pour ce faire, vous pouvez utiliser le flux “Authorization Code Flow” d’OpenID Connect avec PKCE. Ce flux est conçu pour les applications publiques et offre un moyen sécurisé d’authentifier les utilisateurs sans avoir besoin d’un serveur backend.
Si vous devez absolument utiliser SAML, vous pouvez utiliser OAuth2/OpenID Connect comme pont entre votre application publique et l’IdP SAML. L’application publique peut authentifier l’utilisateur via OAuth2/OpenID Connect, puis utiliser le jeton OAuth2 pour demander une assertion SAML auprès de l’IdP. Cette assertion peut ensuite être utilisée pour authentifier l’utilisateur auprès du SP.
