Qu'est-ce que l'authentification unique SSO ?

L’authentification unique (SSO) est une méthode d’authentification qui permet aux utilisateurs d’accéder à plusieurs applications ou services avec un seul ensemble d’identifiants de connexion.

Qu'est-ce que l'authentification unique (SSO) ?

L'authentification unique (SSO) est un modèle de fédération d'identités dans lequel un utilisateur s'authentifie une seule fois auprès d'un fournisseur d'identité (IdP) de confiance, puis reçoit des assertions ou des jetons signés cryptographiquement que d'autres applications (appelées fournisseurs de services) acceptent comme preuve d'identité. Après la première connexion, l'IdP émet des identifiants temporaires (par exemple, des assertions SAML ou des jetons d'identification OpenID Connect) que le navigateur ou le client présente à chaque application. Celle-ci vérifie la signature, le destinataire et la date d'expiration avant d'établir sa propre session.

Parce que la confiance est ancrée dans le fournisseur d'identité et véhiculée par des protocoles basés sur des normes, l'authentification unique (SSO) permet à des systèmes indépendants de partager une vision cohérente de l'identité de l'utilisateur, de ses attributs et de la durée de validité de son authentification .

Types d'authentification unique

Vous trouverez ci-dessous les types les plus courants que vous rencontrerez et leur fonction respective.

Fédération SAML 2.0

Le langage SAML (Security Assertion Markup Language) est une norme XML largement utilisée pour l'authentification unique (SSO) via navigateur vers les solutions SaaS d'entreprise . Après l'authentification auprès du fournisseur d'identité (IdP), le navigateur de l'utilisateur reçoit une assertion SAML signée que le fournisseur de services (SP) valide pour établir une session.

SAML est une technologie mature, performante pour la diffusion d'attributs d'entreprise (rôles, groupes) et couramment utilisée pour les migrations SIRH vers SaaS et ADFS vers...cloud intégrations.

Connexion OpenID (OIDC)

OIDC repose sur OAuth 2.0 et utilise des jetons Web JSON (JWT) pour l'authentification. Après s'être authentifié auprès du fournisseur d'identité (IdP), le client obtient un jeton d'identification (qui vous identifie) et souvent un jeton d'accès (qui vous permet d'accéder à Internet).

OIDC est plus léger que SAML, compatible avec les appareils mobiles et les API , et idéal pour les applications web et mobiles modernes, les applications monopages (SPA) et les microservices qui nécessitent des jetons standardisés et compacts.

Authentification Kerberos/Windows intégrée (IWA)

Dans l'authentification unique (SSO) basée sur Kerberos (par exemple, avec Active Directory), le système d'exploitation obtient un ticket auprès d'un centre de distribution de clés et le présente de manière transparente aux services, permettant ainsi une authentification unique « silencieuse » sur les réseaux d'entreprise. Cette solution est rapide, compatible avec l'authentification mutuelle et idéale pour les applications sur site et les intranets, car les configurations modernes font souvent le lien entre les identités Kerberos et les services distants. cloud via la fédération.

Authentification unique (SSO) basée sur OAuth 2.0 (accès par jeton)

OAuth est un framework d'autorisation, et non un protocole d'identité. Cependant, de nombreuses implémentations d'authentification unique (SSO) l'associent à OIDC ou à des points de terminaison d'identité personnalisés pour permettre aux utilisateurs de s'authentifier une seule fois et d'obtenir des jetons d'accès aux API. Il en résulte une authentification unique couvrant les couches web et de services, avec des jetons à durée de vie limitée, des étendues d'accès et des flux d'actualisation adaptés aux architectures « zéro confiance ».

Fédération WS (WS-Fed)

Un protocole de fédération Microsoft plus ancien, orienté SOAP, encore présent dans les environnements ADFS et SharePoint existants. Il permet l'authentification unique (SSO) via navigateur, similaire à SAML, mais est moins courant dans les nouveaux projets. Les organisations migrent donc souvent leurs applications WS-Fed vers OIDC/SAML dans le cadre de leur développement. cloud modernisation.

CAS (Service d'authentification central)

Il s'agit d'un protocole simple d'octroi de tickets, répandu dans l'enseignement supérieur. Les utilisateurs s'authentifient auprès d'un serveur CAS central. serverCAS, qui émet des tickets de service que les applications valident, est simple à utiliser et à étendre, mais ne dispose pas des écosystèmes de revendications et de jetons plus riches de SAML/OIDC.

Authentification par proxy inverse/basée sur l'en-tête

Une passerelle authentifie les utilisateurs (via Kerberos, SAML, OIDC ou MFA) et injecte des en-têtes d'identité (par exemple, X-Remote-User) dans les applications backend qui ne prennent pas en charge les protocoles de fédération. Elle est utile pour moderniser des applications existantes, mais sa sécurité repose sur une confiance absolue accordée uniquement au proxy et sur un renforcement des contrôles d'accès direct aux applications.

Coffre-fort de mots de passe/SSO par remplissage de formulaire

En dernier recours pour les applications ne prenant pas en charge la fédération, une passerelle d'accès stocke de manière sécurisée les identifiants de chaque utilisateur et les connecte par programmation. Elle améliore le confort d'utilisation, mais ne fournit pas une véritable fédération, et des tâches telles que la rotation des identifiants, l'application de l'authentification multifacteur et l'audit deviennent plus complexes qu'avec l'authentification unique (SSO) basée sur des normes.

Comment fonctionne l'authentification unique ?

L'authentification unique (SSO) permet à un utilisateur de s'authentifier une seule fois auprès d'un fournisseur d'identité de confiance et de réutiliser cette preuve pour accéder en toute sécurité à de nombreuses applications (fournisseurs de services). Voici comment cela fonctionne :

1. Initiation et découverte du fournisseur d'identité. L'utilisateur tente d'ouvrir une application. Celle-ci (fournisseur de services) ne détecte aucune session locale et redirige l'utilisateur (souvent via des métadonnées SAML/OIDC) vers le fournisseur d'identité approprié, établissant ainsi le lieu où la confiance et la connexion seront établies.
2. Authentification de l'utilisateur auprès du fournisseur d'identité. Le fournisseur d'identité (IdP) valide l'identité à l'aide de méthodes configurées, telles qu'un mot de passe et l'authentification multifacteur (MFA), des clés d'accès ou des vérifications de la posture de l'appareil, créant ainsi un nouveau contexte d'authentification avec un horodatage précis et un niveau d'assurance.
3. Émission de jetons/d'assertions. En cas de succès, le fournisseur d'identité (IdP) émet une attestation signée et à durée limitée (par exemple, une assertion SAML, un jeton d'identification OIDC et un jeton d'accès) contenant l'identifiant et les revendications/attributs de l'utilisateur.
4. Livraison sécurisée vers l'application. Le navigateur ou le client renvoie au fournisseur de services (SP) en transportant les informations d'identification via une liaison sécurisée (échange de jetons POST/redirection par canal frontal ou dorsal), préservant ainsi l'intégrité et empêchant toute falsification ou relecture.
5. Vérification et création de session. Le SP valide le Signature, l'audience, l'émetteur, le nonce et l'expiration. Si les vérifications sont réussies, une session d'application (cookie ou jeton) est établie et l'autorisation est appliquée en fonction des rôles ou des revendications.
6. Actualisation et mise à niveau du jeton (selon les besoins). À mesure que les sessions vieillissent ou que la sensibilité d'accès augmente, le client utilise des flux d'actualisation ou de réauthentification pour obtenir de nouveaux jetons ou renforcer l'authentification multifacteur, assurant ainsi un accès continu sans avoir à se reconnecter complètement à chaque fois.
7. Déconnexion et révocation. Lorsque l'utilisateur se déconnecte ou qu'un risque est détecté, le fournisseur de services met fin à sa session. En option, la déconnexion unique (SLO) ou la révocation par canal secondaire au niveau du fournisseur d'identité (IdP) propage la déconnexion aux autres applications afin de fermer les sessions restantes.

Qu'est-ce qu'un exemple de SSO ?

Un exemple d'authentification unique (SSO) est celui d'un employé qui consulte Salesforce sans session locale. Salesforce le redirige alors vers Okta (le fournisseur d'identité de l'organisation). L'utilisateur s'authentifie auprès d'Okta et effectue l'authentification multifacteur (MFA). Okta émet ensuite une assertion SAML signée et éphémère contenant l'identifiant et les rôles de l'utilisateur.

Le navigateur renvoie cette assertion à Salesforce, qui vérifie la signature, l'audience et l'expiration, puis crée sa propre session et applique les autorisations de l'utilisateur. Ainsi, aucun mot de passe Salesforce supplémentaire n'est requis. Les connexions ultérieures à d'autres applications connectées (par exemple, ServiceNow, Box) réutilisent la session Okta, offrant un accès fluide entre les applications avec une politique et un audit centralisés.

Quels sont les avantages et les inconvénients de l'authentification unique ?

L'authentification unique simplifie l'accès en permettant aux utilisateurs de s'authentifier une seule fois pour accéder à de nombreuses applications, améliorant ainsi l'expérience utilisateur et centralisant les contrôles de sécurité. Cependant, cette centralisation de l'authentification accroît également les risques et la complexité : en cas de défaillance ou de mauvaise configuration du système d'identité, de nombreuses applications sont affectées simultanément. C'est pourquoi une conception soignée est nécessaire afin de concilier simplicité d'utilisation et robustesse des mesures de sécurité.

Quels sont les avantages de l'authentification unique ?

L'authentification unique (SSO) améliore l'expérience utilisateur et centralise le contrôle en fédérant l'authentification via un fournisseur d'identité de confiance. Voici ses principaux avantages :

• Moins de mots de passe, meilleure expérience utilisateur. Les utilisateurs se connectent une seule fois et accèdent à toutes les applications, ce qui réduit les frictions et la lassitude liées à la connexion.
• Des contrôles de sécurité renforcés. L'authentification multifacteur centralisée, les clés d'accès, les vérifications de l'état des appareils et l'accès conditionnel s'appliquent uniformément à toutes les applications.
• Intégration/désintégration plus rapides. L'octroi ou la révocation d'un accès se fait à partir d'un seul enregistrement d'identité, les modifications se propageant ainsi à tous les services connectés.
• Coûts de support réduits. Moins de réinitialisations de mot de passe et de blocages de compte signifient moins de tickets d'assistance.
• Gouvernance cohérente. Les rôles, les groupes et les politiques basées sur les attributs sont appliqués de la même manière partout, ce qui permet de prendre en charge moindre privilège.
• Meilleure visibilité et audit. Les journaux centralisés et les jetons standardisés simplifient la surveillance. réponse à l'incidentet les rapports de conformité.
• Inégalités phishing risque. Les utilisateurs reconnaissent un flux de connexion IdP unique et sécurisé, ce qui réduit le nombre de mots de passe spécifiques aux applications à voler.
• Préparation aux applications modernes et aux API. Les normes (OIDC/SAML/OAuth) permettent un accès sécurisé aux services web, mobiles et microservices grâce à des jetons à durée de vie limitée.
• Une gestion du changement plus sûre. La durée de vie des jetons, les politiques de session et l'authentification renforcée vous permettent d'accroître la sécurité des actions sensibles sans avoir à créer de nouvelles connexions.
• Productivité améliorée. L'accès fluide entre les applications raccourcit les changements de contexte et accélère les flux de travail.

Quels sont les inconvénients de l'authentification unique ?

La centralisation de l'authentification présente des avantages concrets, mais elle engendre également des risques techniques et opérationnels qu'il convient de gérer. Voici les principaux défis :

• Point de défaillance unique et le rayon de l'explosion. Si le fournisseur d'identité est hors service ou mal configuré, de nombreuses applications deviennent inaccessibles simultanément.
• Risque de mauvaise configuration. Une validation de jeton faible (audience/émetteur/nonce), des expirations longues ou une libération permissive des attributs peuvent ouvrir la porte à l'usurpation d'identité et à l'extension des privilèges.
• Hygiène des séances et des jetons. Trouver le juste équilibre entre commodité et sécurité (comme la gestion des délais d'inactivité et des délais absolus, des jetons d'actualisation et de l'authentification multifacteur renforcée) est délicat, et les sessions trop longues augmentent le risque de prise de contrôle.
• Certificat et gestion des clés. Rotation des clés de signature, manipulation métadonnées Les mises à jour et les décalages d'horloge nécessitent des opérations rigoureuses, sinon les connexions peuvent échouer silencieusement.
• Complexité de la déconnexion. La prise en charge de la déconnexion unique (SLO) est incohérente et les déconnexions partielles laissent des sessions d'application résiduelles.
• Cas existants et cas particuliers. Les applications non fédérées imposent le stockage des mots de passe dans un coffre-fort numérique ou l'injection d'en-têtes, ce qui ajoute de la fragilité et une sécurité plus faible qu'une véritable fédération.
• Liaison et cycle de vie des comptes. La mise en correspondance des identités entre les annuaires et les locataires, le provisionnement juste-à-temps et le déprovisionnement en temps opportun sont sujets aux erreurs sans des données RH claires et IAM sources.
• Prolifération des politiques d'accès. L'accès conditionnel, la configuration des appareils et les exceptions par application peuvent devenir difficiles à appréhender, entraînant des interruptions ou des dysfonctionnements.
• Vendeur et le verrouillage des normes. Les fonctionnalités propriétaires ou les particularités des protocoles rendent les migrations coûteuses et les stratégies multi-IdP plus difficiles.
• Respect de la vie privée et minimisation des données. Le partage excessif d'attributs entre applications augmente l'exposition, il est donc nécessaire de limiter la diffusion aux attributs les plus rares et de mettre en place des contrôles de consentement.
• Concentration sur l'hameçonnage et les abus. Un seul flux de données renforcé est utile, mais si les attaquants s'emparent des identifiants/sessions du fournisseur d'identité, ils héritent d'un accès étendu.

FAQ sur l'authentification unique

Voici les réponses aux questions les plus fréquemment posées sur l'authentification unique.

Quelle est la différence entre SSO et AD ?

Examinons plus en détail les différences entre l'authentification unique et Active Directory (AD) :

L’authentification unique est-elle sécurisée ?

Oui, correctement implémentée, l'authentification unique (SSO) est très sécurisée car elle centralise les contrôles d'accès robustes (authentification multifacteur/mots de passe, accès conditionnel, vérifications de la sécurité des appareils) auprès d'un fournisseur d'identité renforcé et émet des jetons signés à durée de vie limitée, que chaque application vérifie. Les principaux risques proviennent de l'architecture plutôt que de l'authentification unique elle-même. Une panne ou une mauvaise configuration du fournisseur d'identité peut affecter de nombreuses applications, et des jetons à longue durée de vie ou faiblement validés augmentent le risque de prise de contrôle.

L'authentification unique (SSO) doit également être combinée au principe du moindre privilège, à une validation stricte des jetons (émetteur, destinataire, nonce et expiration), à la rotation des clés et à la synchronisation de l'horloge, à une surveillance continue avec détection des anomalies, à une authentification renforcée pour les actions sensibles et à une architecture IdP résiliente (redondance, limitation du débit, protection contre les attaques DDoS ). Grâce à ces mesures de protection, l'authentification unique améliore généralement la sécurité par rapport à une connexion isolée par application.

L'authentification unique (SSO) en vaut-elle la peine ?

Oui, l'authentification unique (SSO) est généralement avantageuse pour la plupart des organisations car elle simplifie l'authentification tout en améliorant la sécurité et la productivité. La connexion centralisée réduit la lassitude liée aux mots de passe, la réutilisation d'identifiants faibles et la charge de travail du service d'assistance liée aux réinitialisations de mots de passe. Elle permet également une application cohérente des politiques telles que l'authentification multifacteurs et l'accès conditionnel sur toutes les applications connectées.

L'effort initial de configuration et la dépendance à un fournisseur d'identité fiable représentent des compromis réels, mais les avantages à long terme sont indéniables. Une sécurité renforcée, des processus d'intégration et de désintégration plus rapides, une meilleure visibilité de la conformité et une expérience utilisateur plus fluide compensent généralement la complexité et le coût de la mise en œuvre.