7 étapes pour mettre en place le Single Sign-On dans des applications personnalisées pour les ingénieurs et les chefs de produit

Pour les nouvelles applications web ou mobiles personnalisées, utilisez OpenID Connect avec le flux Authorization Code et PKCE ; réservez SAML aux cas où vous devez interopérer avec des fournisseurs d’identité d’entreprise existants. Avant d’écrire la moindre ligne de code, préparez les éléments suivants : un URI de redirection enregistré, un identifiant client, une URL d’émetteur ou de métadonnées, ainsi qu’un accès au point de terminaison JWKS du fournisseur. Vérifiez que PKCE utilise la méthode S256, que les jetons sont limités à une seule audience et que les paramètres nonce et state sont tous deux validés lors du callback.

En bref :

• Utilisez OpenID Connect avec Authorization Code et PKCE pour les nouvelles applications cloud natives, et réservez SAML aux intégrations d’entreprise existantes.
• Vérifiez la validation complète de PKCE, la restriction de l’audience des jetons, ainsi que la validation des paramètres nonce et state lors de chaque callback afin de garantir la sécurité.
• Prenez en charge les deux protocoles lorsque cela est nécessaire, mais utilisez par défaut OIDC pour les applications modernes, notamment avec les architectures d’API et mobiles, tout en prenant en charge SAML pour les partenaires d’entreprise.
• Enregistrez correctement les applications, validez l’émetteur et les JWKS, puis testez la validité des jetons et la synchronisation des horloges avant le déploiement en production ; maintenez des environnements de staging et de production distincts.
• Mettez en œuvre une validation rigoureuse de la déconnexion, surveillez les erreurs courantes comme les divergences d’URI de redirection et préparez les renouvellements de certificats à l’aide de procédures opérationnelles détaillées.

Sommaire

• Choisir entre OIDC et SAML pour les applications personnalisées
• Mettre en œuvre OpenID Connect étape par étape dans des applications personnalisées
• Intégrer SAML 2.0 pour les fournisseurs d’identité d’entreprise
• Maîtriser Authorization Code et PKCE
• Où stocker les jetons : architectures BFF, SPA et mobiles
• Gérer correctement la déconnexion et la fin de session
• Liste de contrôle des tests et erreurs courantes lors du déploiement du SSO
• Normes de sécurité à consulter lors de toute revue de conception du SSO
• Liste de contrôle opérationnelle issue de projets réalisés
• Obtenir de l’aide pour mettre en œuvre le SSO dans votre application personnalisée
• Sources
• FAQ

Choisir entre OIDC et SAML pour les applications personnalisées

Le choix du protocole dépend généralement du type d’application que vous développez et des interlocuteurs avec lesquels elle doit communiquer. OpenID Connect est recommandé pour les nouvelles applications cloud natives, car il repose sur OAuth 2.0 et s’intègre naturellement aux architectures web et d’API. SAML 2.0 reste courant dans les intégrations B2B d’entreprise, notamment lorsque le fournisseur d’identité date de plusieurs décennies et que l’équipe d’intégration ne prévoit pas de le moderniser.

Les compromis sont pratiques, et non philosophiques. SAML repose sur l’échange de métadonnées XML et une relation de confiance fondée sur des certificats ; le renouvellement des certificats et le mappage des attributs deviennent donc des tâches de maintenance récurrentes. OIDC s’appuie sur des JSON Web Tokens et un document de découverte, que la plupart des bibliothèques actuelles gèrent avec beaucoup moins de code personnalisé.

Voici quelques éléments à prendre en compte avant d’adopter un protocole pour l’ensemble de votre application :

• Architecture de l’application: Les applications monopages, les applications mobiles et les backends axés sur les API s’adaptent plus naturellement au modèle de jetons d’OIDC qu’aux hypothèses de SAML fondées sur les redirections du navigateur.
• Écosystème des IdP partenaires: Si vos clients d’entreprise n’exposent que des points de terminaison SAML, vous devrez le prendre en charge, quelles que soient vos préférences.
• Complexité multitenant: Prévoyez suffisamment tôt la recherche de l’émetteur, la vérification du domaine et la découverte du domaine d’accueil si vous prenez en charge plusieurs IdP clients, car adapter le routage des tenants après le lancement est pénible.

La plupart des équipes finissent par prendre en charge les deux, avec OIDC par défaut et SAML comme solution adaptée à certains comptes d’entreprise.

Mettre en œuvre OpenID Connect étape par étape dans des applications personnalisées

Une fois que vous avez choisi OIDC, la séquence d’implémentation est assez similaire d’un fournisseur à l’autre, que vous utilisiez Okta, Azure AD ou une autre plateforme d’identité.

1. Enregistrez l’application auprès de votre fournisseur d’identité en précisant le type de client (public ou confidentiel), les URI de redirection exactes et les origines autorisées pour CORS.
2. Récupérez le document de découverte depuis le point de terminaison /.well-known/openid-configuration du fournisseur et mettez en cache les URL de l’émetteur et de JWKS.
3. Validez l’émetteur de chaque jeton que vous recevez en le comparant exactement à la valeur indiquée dans le document de découverte.
4. Demandez la openid portée au minimum, en ajoutant profile ou email uniquement si votre application a réellement besoin de ces revendications.
5. Lancez le flux Authorization Code avec PKCE, en générant un vérificateur de code et un défi de code haché avec S256 avant de rediriger l’utilisateur.
6. Validez le id_tokenretourné en vérifiant iss, aud, exp, ainsi que le nonce que vous avez généré au début du flux, comme le recommande le guide OAuth2 de l’OWASP.
7. Gérez correctement les secrets: les clients confidentiels stockent le secret client uniquement côté serveur ; les clients publics s’appuient entièrement sur PKCE.

Quelques détails de déploiement posent problème aux équipes qui ignorent les environnements de préproduction : chez la plupart des fournisseurs, les listes d’autorisation des URI de redirection exigent une correspondance exacte ; une différence de barre oblique finale peut donc échouer silencieusement ou provoquer une erreur cryptique. Un décalage d’horloge entre votre serveur et l’IdP peut entraîner le rejet de jetons valides comme étant expirés. Effectuez des tests sur un locataire IdP de préproduction disposant de son propre enregistrement client avant d’utiliser les identifiants de production.

Conseil pratique : Conservez des enregistrements client distincts pour la préproduction et la production, même si cela implique de doubler le travail de configuration : partager une liste d’autorisation d’URI de redirection entre les environnements est une cause fréquente de surprises du type « cela fonctionnait en préproduction ».

Intégrer SAML 2.0 pour les fournisseurs d’identité d’entreprise

Les intégrations SAML suivent un rythme différent, fondé sur l’échange de métadonnées plutôt que sur des points de terminaison de découverte. La mise en place du SSO SAML nécessite d’enregistrer les URL de redirection et d’ACS, d’échanger des métadonnées ou des certificats et d’aligner les valeurs d’émetteur entre le fournisseur de services et le fournisseur d’identité ; les incohérences à ce niveau sont la cause la plus fréquente des échecs de connexion.

Étapes pratiques pour une intégration propre :

• Échangez rapidement les métadonnées du SP et de l’IdP , notamment l’URL de l’Assertion Consumer Service (ACS) et votre Entity ID, afin que les deux parties s’accordent sur la destination des assertions.
• Gérez les certificats avec méthode: récupérez-les depuis le point de terminaison de métadonnées de l’IdP lorsque c’est possible, plutôt que de coder en dur un certificat qui finira par expirer.
• Mappez les attributs SAML dans le modèle d’autorisation de votre application au moyen d’une liste d’autorisation explicite, puis testez le mappage avec un utilisateur de test dédié par locataire avant le déploiement auprès de comptes réels.

Les échecs propres à SAML se concentrent généralement autour de quelques causes : des assertions non signées ou mal signées, un décalage d’horloge entre l’IdP et votre serveur, ainsi que des incohérences de restriction d’audience lorsque le destinataire prévu de l’assertion ne correspond pas à votre Entity ID.

Conseil pratique : Consignez la réponse SAML brute (à l’exception des valeurs d’attributs sensibles) pendant les tests d’intégration. Les problèmes d’espaces de noms XML sont bien plus faciles à repérer dans une charge utile brute que dans une trace de pile située trois couches après l’assertion réelle.

Bien implémenter le code d’autorisation avec PKCE

PKCE vise à combler une faille précise : sans lui, le code d’autorisation intercepté peut être utilisé par toute personne qui l’a capturé. PKCE lie la demande d’autorisation initiale à l’échange de jetons au moyen d’un vérificateur ; ainsi, même un code volé est inutilisable sans le vérificateur correspondant. Le flux de code d’autorisation avec PKCE constitue désormais la pratique de sécurité de référence pour les clients publics, S256 étant la méthode de défi de code recommandée, plutôt que la méthode « plain », plus faible.

Le fonctionnement est simple dès lors que vous l’avez mis en œuvre une première fois : générez un vérificateur de code aléatoire, hachez-le avec SHA-256 pour produire le défi de code, envoyez ce défi dans la demande d’autorisation, puis présentez le vérificateur d’origine lors de l’échange du code contre des jetons. Les erreurs fréquentes des équipes :

• Ignorer la validation du nonce, ce qui neutralise l’une des principales protections contre les attaques par rejeu au niveau d’OIDC.
• Autoriser la réutilisation du code, alors qu’un code doit être à usage unique et immédiatement invalidé après la première tentative d’échange.
• Stocker le vérificateur de manière non sécurisée, par exemple dans un emplacement accessible à n’importe quel script exécuté sur la page d’une application basée sur un navigateur.

Les clients confidentiels, c’est-à-dire les applications côté serveur capables de conserver un secret en toute sécurité, associent tout de même PKCE à un secret client dans de nombreuses implémentations. Les clients publics, tels que les SPA et les applications mobiles natives, reposent uniquement sur PKCE, puisqu’ils ne peuvent pas garder un secret confidentiel.

Où stocker les jetons : modèles BFF, SPA et mobile

L’emplacement des jetons détermine l’essentiel de l’exposition de votre application au vol de jetons. Le modèle backend-for-frontend conserve les jetons côté serveur et remet à la place au navigateur un cookie de courte durée avec l’attribut HttpOnly ; cette configuration est devenue la recommandation standard pour les applications monopages qui appellent des API privées.

La RFC 9700 décrit les jetons liés cryptographiquement à l’émetteur comme une orientation émergente visant à réduire le risque de rejeu, ce qui indique que les décisions actuelles de conception relatives à la gestion des jetons doivent tenir compte d’éventuelles exigences plus strictes en matière de liaison.

Règles pratiques pour la topologie des jetons :

• Clients confidentiels conservez les secrets côté serveur ; clients publics reposez-vous sur PKCE et sur des jetons d’accès de courte durée plutôt que sur un secret.
• Limitez les jetons d’accès à une seule audience pour chaque API et n’acceptez jamais un jeton d’identité comme s’il s’agissait d’un jeton d’accès à une API.
• Faites tourner les jetons d’actualisation à chaque utilisation et détectez la réutilisation d’un jeton retiré comme un signe possible de vol.

Les applications mobiles suivent généralement le modèle des clients publics et stockent les jetons dans le stockage sécurisé fourni par la plateforme (Keychain sur iOS, Keystore sur Android), plutôt que dans des fichiers ordinaires.

Gérer correctement la déconnexion et la fin de session

La déconnexion unique paraît simple jusqu’à ce que vous vous demandiez qui l’a déclenchée et jusqu’où elle doit se propager. Lors d’une déconnexion initiée par le SP, votre application informe l’IdP que l’utilisateur a terminé ; lors d’une déconnexion initiée par l’IdP, l’IdP demande à chaque application connectée de mettre fin à la session. Dans les deux cas, le message entrant doit être validé.

La déconnexion unique SAML exige une validation rigoureuse des demandes de déconnexion, car les implémentations naïves exposent à des risques de déni de service ou de déconnexion forcée : un attaquant peut envoyer un message de déconnexion non authentifié pour éjecter un utilisateur légitime.

Mettez en place la déconnexion avec les garde-fous suivants :

• Validez chaque demande de déconnexion pour sa signature et id_token_hint avant d’agir en conséquence.
• Considérez la déconnexion globale comme une opération à résultat optimal: nettoyez immédiatement la session locale, puis tentez d’envoyer les notifications en aval au lieu de bloquer en les attendant.
• Pour SAML en particulier, exigez des demandes de déconnexion signées et configurez explicitement le point de terminaison SLO au lieu de supposer l’existence d’une valeur par défaut.

Liste de contrôle des tests et erreurs courantes de déploiement du SSO

Avant le lancement, parcourez une courte liste de vérifications préalables plutôt que de découvrir les problèmes en production.

1. Vérifiez que les URI de redirection correspondent exactement, y compris les barres obliques finales et le protocole.
2. Vérifiez l’émetteur et les métadonnées alignez la configuration de votre application sur ce que le fournisseur d’identité publie réellement.
3. Vérifiez la disponibilité de JWKS et confirmez que votre application peut récupérer et mettre en cache les clés de signature.
4. Synchronisez les horloges des serveurs, car même un décalage de quelques minutes entraîne l’échec de la validation des jetons.
5. Testez avec un locataire IdP de préproduction en utilisant des comptes dédiés avant de toucher aux identifiants de production.

Les erreurs courantes correspondent à des correctifs précis : invalid_redirect_uri signifie presque toujours une non-correspondance exacte dans la liste d’autorisation, et une incompatibilité de l’émetteur signifie généralement que votre application a mis en cache un document de découverte obsolète. Consignez les événements d’authentification, y compris les échecs et les tentatives de réutilisation, sans jamais stocker de jetons bruts dans les journaux.

Normes de sécurité à consulter lors de toute revue de conception SSO

Quelques documents devraient servir de référence à toute conception ou revue de sécurité SSO. La RFC 9700 définit la base de sécurité actuelle d’OAuth 2.0, et la RFC 7636 définit le mécanisme PKCE dont cette base dépend. Les recommandations OAuth et OIDC de l’OWASP ASVS considèrent la couche OAuth et OIDC comme un périmètre de sécurité qui mérite d’être audité séparément.

Contrôles à appliquer lors de chaque revue :

• Restreignez l’audience de chaque jeton et rejetez, côté serveur de ressources, les jetons qui n’ont pas été émis pour celui-ci.
• Privilégiez une authentification client plus robuste telle que private_key_jwt ou TLS mutuel plutôt que des secrets partagés lorsque votre fournisseur les prend en charge.
• Faites tourner les certificats et les jetons d’actualisation selon un calendrier défini, et mettez en œuvre la révocation et la détection des rejouements au lieu de compter uniquement sur l’expiration des jetons.

Conseil de pro : Définissez une alerte dans votre calendrier 30 jours avant l’expiration de tout certificat SAML. L’expiration d’un certificat est une interruption de service évitable, pas une surprise.

Une liste de contrôle opérationnelle issue de projets livrés

Faire fonctionner le SSO dans une démonstration est la partie facile. Le faire résister à un lancement en production, à une rotation de certificat et à une panne de l’IdP six mois plus tard demande un peu plus de rigueur.

• Séparez entièrement la préproduction et la production avec des enregistrements de clients, des comptes utilisateurs de test et des points de terminaison de métadonnées distincts.
• Créez une procédure de rotation des certificats avec des périodes de chevauchement et des alertes 30 jours avant l’expiration, en automatisant l’importation depuis les points de terminaison de métadonnées lorsque le fournisseur le permet.
• Transmettez une documentation réellement exploitable, notamment une procédure de révocation des jetons, des tableaux de bord de surveillance des échecs d’authentification et des scripts de tests d’acceptation que l’équipe du client pourra réexécuter après toute modification.

Les équipes qui négligent la documentation de transfert ont tendance à redécouvrir ces enseignements pendant un incident plutôt que lors d’un mardi après-midi tranquille.

Obtenez de l’aide pour implémenter le SSO dans votre application personnalisée

Si votre équipe a déjà défini la conception, mais a besoin d’aide pour la construire, Ridiculous Engineering prend en charge l’ensemble du projet : revue de l’architecture, implémentation d’OIDC ou de SAML, tests avec des locataires IdP de préproduction, ainsi que la mise en place de la procédure et de la surveillance nécessaires pour assurer son fonctionnement après le lancement. Nous travaillons sur des projets de développement logiciel sur mesure dimensionnés selon le problème à résoudre, et non selon un modèle fixe ; nous préférons expliquer honnêtement un compromis plutôt que survendre un raccourci. Si vous vous demandez s’il vaut mieux développer cela en interne ou faire appel à une équipe qui a déjà surmonté les difficultés liées à la rotation des certificats et aux incompatibilités d’URL de rappel, contactez-nous via notre page de contact et nous examinerons ensemble les besoins réels de votre application.

Sources

• RFC 9700 : OAuth 2.0 Security Best Current Practice
• Authentification unique (SSO) Microsoft Entra
• OAuth2 – Série de fiches pratiques de l’OWASP

FAQ

Comment créer mon propre SSO ?

Vous mettez en œuvre le SSO en intégrant votre application à un fournisseur d’identité au moyen d’OpenID Connect ou de SAML, plutôt qu’en développant l’authentification à partir de zéro. Pour les nouvelles applications, OpenID Connect avec le flux Authorization Code et PKCE constitue le point de départ standard, généralement pris en charge par des SDK de fournisseurs comme ceux d’Okta ou d’Azure AD.

Le SSO est-il risqué ?

Le SSO n’est pas intrinsèquement plus risqué que les connexions propres à chaque application et il réduit généralement les risques en centralisant l’authentification auprès d’un fournisseur disposant de contrôles de sécurité plus robustes que la plupart des applications individuelles ne pourraient en développer seules. Le risque réel réside dans les erreurs d’implémentation, comme l’omission de PKCE, l’absence de validation de l’audience du jeton ou une mauvaise gestion de la déconnexion, autant de points traités directement par les recommandations OAuth2 de l’OWASP.

Peut-on utiliser le SSO avec une application mobile ?

Oui, les applications mobiles mettent couramment en œuvre le SSO comme des clients publics OAuth 2.0 utilisant le flux Authorization Code avec PKCE, puisqu’elles ne peuvent pas conserver un secret client de manière sécurisée. Les jetons sont généralement stockés dans le stockage sécurisé natif de la plateforme plutôt que dans de simples fichiers de l’application.

Quels sont les principaux fournisseurs de SSO ?

Parmi les fournisseurs d’identité couramment utilisés pour les intégrations SSO figurent Okta et Azure AD de Microsoft (qui fait désormais partie de Microsoft Entra), entre autres. Le bon choix dépend des protocoles que votre application doit prendre en charge et des fournisseurs que vos clients professionnels utilisent déjà.

Comment fonctionne la déconnexion unique entre les applications ?

La déconnexion unique peut être initiée par votre application (SP-initiated) ou par le fournisseur d’identité (IdP-initiated), et les deux cas nécessitent de valider le message de déconnexion avant d’agir. Des implémentations SAML de la déconnexion trop naïves peuvent exposer à des risques de déni de service ou de déconnexion forcée. C’est pourquoi la plupart des équipes considèrent la déconnexion globale comme une mesure appliquée au mieux, plutôt que comme un coupe-circuit instantané garanti pour chaque application connectée.

Recommandé

• Frameworks d’ingénierie accélérée par l’IA
• Qu’est-ce qui rend une application vraiment attrayante ? Voici notre recette secrète !
• Chef de projet, Product Owner et analyste métier dans le e-commerce et le développement d’applications : lequel vous faut-il ?