Qu'est‑ce que le SSO (authentification unique) ? Comment fonctionne le SSO ?

On le fait tous, et on sait qu'on ne devrait pas. Il y a ce fichier dans notre téléphone ou ce bout de papier dans notre portefeuille, ou pire, un Post‑it collé derrière le clavier, avec la liste de nos identifiants et mots de passe. Et puis il y a l'habitude d'utiliser le nom du chien assorti de quelques chiffres et d'un peu de ponctuation.

Dans le monde numérique actuel, nous devons gérer des dizaines d'identifiants et de mots de passe. À moins d'avoir une mémoire exceptionnelle, ils ne seront pas tous différents. Le plus souvent, ils sont simples, anciens et, si quelqu'un s'y met vraiment, faciles à deviner. C'est un cadeau pour les cybercriminels en puissance et c'est 100 % évitable.

Qu'est‑ce que le SSO (authentification unique) ?

La technologie d'authentification unique (SSO) est une solution partielle au problème des mots de passe qui nous touche autant au travail que dans la vie personnelle. Elle permet de se connecter une seule fois à un serveur d'authentification, qui émet ensuite en notre nom des certificats servant d'identifiants vérifiés pour les applications participantes.

Il y a de fortes chances que vous ayez déjà utilisé un tel système. Si vous avez choisi « Se connecter avec Apple », Google ou un autre grand fournisseur de gestion d'identité plutôt que de créer un nouveau mot de passe pour une application Web, vous utilisez le SSO. De plus en plus, le SSO est aussi utilisé en entreprise, souvent combiné à d'autres technologies d'autorisation pour sécuriser les systèmes et rendre la gestion des mots de passe tenable à l'échelle de dizaines, voire de centaines d'applications et de services.

Points à retenir

• Le SSO allège la charge de mémoriser de multiples combinaisons identifiant/mot de passe.
• Le SSO simplifie la vie des équipes IT en offrant un seul système d'authentification à gérer pour toute l'organisation.
• Le SSO permet aussi aux applications d'authentifier les utilisateurs auprès des services nécessaires à leur fonctionnement, par exemple pour gérer les connexions réseau ou vérifier les mises à jour logicielles.

Le SSO expliqué

Le principe du single sign‑on est simple : au lieu de fournir un identifiant et un mot de passe, ou de vous identifier séparément auprès de chaque application, vous fournissez ces informations une seule fois à un serveur d'authentification. Une fois cela fait, le serveur d'authentification envoie des certificats d'identification en votre nom lorsque vous accédez à toute application participant au système de SSO.

Le SSO réduit le nombre d'identifiants et de mots de passe à connaître. Cela peut aussi réduire considérablement le nombre de demandes d'identification, facilitant l'usage d'un large éventail d'applications et augmentant la probabilité que vous créiez des mots de passe plus robustes. Du point de vue des responsables IT, le SSO leur permet de faire évoluer les procédures de sécurité et de déployer des mécanismes d'authentification plus avancés au niveau du serveur d'authentification, afin que toutes les applications participantes bénéficient d'une authentification plus sûre sans modification.

Dans votre vie personnelle, utiliser le système d'authentification d'un grand fournisseur plutôt que de créer manuellement un nouvel identifiant et mot de passe pour chaque application présente plusieurs avantages. L'un des principaux atouts est que les grands fournisseurs de services de gestion d'identité fédérée protègent efficacement les mots de passe et autres données personnelles qui leur sont confiés. Un nouveau fournisseur avec une application récente ne protégera peut‑être pas aussi bien les identifiants que vous fournissez.

Comment fonctionne le SSO ?

Le SSO consiste à demander aux utilisateurs de s'authentifier auprès d'un serveur de SSO plutôt qu'auprès de chaque application. Une fois le processus d'authentification terminé, le serveur de SSO fournit des certificats aux applications que l'utilisateur authentifié souhaite utiliser. Les certificats servent à vérifier l'identité de l'utilisateur.

Les certificats sont en général valables pendant une durée limitée et sont souvent liés au système depuis lequel les utilisateurs se sont authentifiés. Pour participer, les applications doivent être conçues de manière à pouvoir utiliser le service de SSO. En entreprise, les responsables IT choisissent en général un modèle de SSO et exigent que les applications l'utilisent pour vérifier l'identité des employés. Cela peut poser problème pour les applications monolithiques plus anciennes qui gèrent leurs propres référentiels d'identifiants ou ne prennent pas en charge les architectures de SSO courantes.

Types de configuration SSO courants

Les composants et concepts SSO partagent plusieurs caractéristiques : gestion centralisée des identités, standardisation et mesures de sécurité robustes. L'interopérabilité est clé : ces systèmes doivent fonctionner ensemble pour garantir un processus d'authentification fluide et simple d'usage sur de multiples applications. Une fois cet objectif atteint, les équipes IT peuvent imposer des mots de passe plus sécurisés et l'authentification à deux facteurs (MFA) avec un minimum de résistance.

• SAML. Security Assertion Markup Language (SAML) est une spécification technique décrivant la structure d'un document servant à authentifier les utilisateurs auprès des applications. SAML s'appuie sur le standard XML largement adopté pour définir la structure du document que les serveurs d'identité, également appelés fournisseurs d'identité, créent et envoient aux applications. Dans le langage du SSO, ces applications sont souvent appelées « fournisseurs de services ». Tout fournisseur d'identité utilisant SAML crée des informations d'authentification utilisables par toute application compatible SAML, ce qui en fait un bon choix pour les applications internet.

  SAML ne fournit pas de mécanisme garantissant que les informations d'authentification reçues par une application n'ont pas été altérées. Cela est pris en charge par d'autres technologies.

• Kerberos. Créé au MIT à la fin des années 1980 dans le cadre du projet Athena, Kerberos est une architecture complète d'authentification et d'autorisation. Le projet Athena visait à créer un réseau de ressources informatiques accessibles à tous les étudiants du MIT sur l'ensemble du campus. Kerberos utilisait à l'origine le Data Encryption Standard (DES) pour chiffrer les messages échangés entre serveurs d'authentification et applications. Il utilisait des clés symétriques de 48 bits, c'est‑à‑dire la même clé pour chiffrer et déchiffrer les messages. À l'époque, le DES était la forme de chiffrement standard la plus sécurisée, maintenue par le National Institute of Standards and Technology (NIST).

  Aujourd'hui, Kerberos utilise l'Advanced Encryption Standard (AES), qui a supplanté le DES dans les standards de chiffrement du NIST. L'AES propose des clés plus longues, jusqu'à 256 bits, et autorise plusieurs tours de chiffrement, rendant le système très difficile à compromettre.

  Comme Kerberos repose sur un chiffrement à clé symétrique, il nécessite un tiers de confiance pour gérer les clés, ce qui le rend particulièrement adapté aux applications d'entreprise où le domaine d'usage est bien défini, généralement limité aux LAN et VPN de l'entreprise. Bien que Kerberos puisse être utilisé sur internet sans domaine établi en amorçant le processus via un autre standard d'authentification, le chiffrement à clé publique, cette approche reste rare. Kerberos peut utiliser son propre format d'identifiants ou être configuré pour utiliser SAML. Kerberos reste populaire, notamment chez Microsoft, qui le privilégie par défaut plutôt que son système d'authentification NTLM, moins sécurisé, pour les réseaux d'entreprise.

• OAuth. Cadre d'autorisation open source qui n'inclut pas de cadre d'authentification, OAuth est le système par défaut lorsqu'une application internet doit accéder, au nom d'un utilisateur, aux ressources d'un service protégé. La plupart des fournisseurs cloud, dont Oracle avec Oracle Cloud Infrastructure (OCI), utilisent OAuth pour gérer l'accès à leurs ressources cloud. Oracle propose également des bibliothèques et des services qui facilitent la création d'applications tirant parti d'OAuth.

  Voici les composants essentiels d'un système OAuth :

  • Le client, généralement une application utilisée par un utilisateur final souhaitant accéder aux ressources de divers services disponibles sur internet.
  • Le serveur d'autorisation, qui reçoit les demandes de jetons permettant au client d'accéder à des services protégés. Le serveur d'autorisation reçoit les demandes de jetons accompagnées du certificat d'authentification du client. Il émet des jetons d'accès autorisés par le propriétaire de la ressource.
  • Le serveur de ressources, qui détient l'information ou fournit le service que le client souhaite utiliser. Il fournit des données ou des services lorsqu'il reçoit des jetons d'accès valides de la part du client.

  Un jeton d'accès peut spécifier différents types d'autorisations d'accès. Les types d'autorisations varient selon le niveau de confiance requis et la nature du terminal client. Par exemple, un téléviseur connecté pourra recevoir une autorisation différente de celle d'un ordinateur portable.

• OpenID Connect (OIDC). OpenID Connect est le système de gestion d'identité conçu pour fonctionner avec OAuth. Ensemble, OIDC et OAuth offrent un environnement SSO complet pour les applications Web et les systèmes natifs internet, comme les applications mobiles. Au lieu d'utiliser SAML pour renvoyer les informations d'identification, OIDC s'appuie sur un document JSON appelé JSON Web Token (JWT), décrit ci‑dessous, et sur des protocoles REST ; les deux sont natifs d'internet et simples à utiliser pour les développeurs.

  Plutôt que le chiffrement à clé symétrique utilisé par Kerberos, OIDC recourt au chiffrement à clé publique, mieux adapté aux réseaux sans domaine comme internet.

• Authentification par carte à puce. Des systèmes comme OIDC utilisent le chiffrement à clé publique pour garantir que seuls les destinataires autorisés peuvent voir les données échangées avec un fournisseur de gestion d'identité pendant et après l'authentification. Le chiffrement à clé publique est asymétrique et implique une clé publique, utilisée pour chiffrer les messages destinés à un client ou à un serveur, et une clé privée, secrète, nécessaire pour les déchiffrer.

  En général, les clés privées sont stockées sur l'appareil de l'utilisateur. La plupart des ordinateurs portables intègrent une puce inviolable basée sur la technologie Trusted Platform Module (TPM) pour déchiffrer les messages destinés au système. Les téléphones Apple et Android utilisent des systèmes différents, mais similaires. Chez Apple, il s'appelle Secure Enclave ; sous Android, Android Knox. Ces technologies permettent à l'appareil de fournir sa clé publique à tout système qui la demande correctement et d'utiliser sa clé privée, jamais divulguée, pour déchiffrer les messages reçus.

  L'avantage de ces systèmes est que l'utilisateur n'a rien à savoir sur la façon dont le chiffrement est géré sur son appareil. L'inconvénient est que chaque appareil détenu par l'utilisateur possède sa propre paire de clés publique/privée ; les appareils sont donc identifiés individuellement dans le processus de chiffrement. Si un ordinateur portable ou un téléphone est perdu ou volé, son système de chiffrement n'empêchera pas l'accès si le voleur connaît le mot de passe du propriétaire.

  L'utilisation d'une carte à puce, similaire à celles des cartes bancaires, permet d'authentifier les utilisateurs avec un seul jeu de clés, quel que soit l'appareil utilisé. La puce de la carte est un microprocesseur ; elle doit être insérée dans un lecteur ou activée et alimentée via une technologie RFID, comme la communication en champ proche (NFC). La sécurité des cartes à puce est comparable à celle offerte par les puces TPM.

• SSO d'entreprise (eSSO). Les grandes organisations dotées d'infrastructures applicatives complexes peuvent mettre en place un SSO d'entreprise (eSSO) limité au périmètre de leurs réseaux. Les employés apprécieront de n'avoir qu'un ou deux couples identifiant/mot de passe pour accéder aux applications nécessaires, et l'organisation bénéficiera d'une sécurité des systèmes et des données plus robuste et plus facile à administrer. Ces systèmes eSSO peuvent privilégier le chiffrement à clé symétrique, plus simple à révoquer, et SAML pour son format bien connu ; ils recourent souvent à différentes formes d'authentification multifacteur (MFA) pour mieux sécuriser les endpoints.

  À mesure que les applications SaaS se généralisent, les entreprises peuvent soit évoluer vers un système comme OAuth, plus courant sur internet, soit imposer l'intégration des applications SaaS dans le cadre eSSO choisi par l'entreprise. SAML peut être utilisé au sein du réseau d'entreprise comme sur internet. De nombreuses applications SaaS prennent en charge les deux cadres pour l'authentification des utilisateurs.

• SSO Web. Les applications Web fonctionnent mieux, ou se limitent, avec OAuth pour autoriser les actions des utilisateurs et OpenID Connect (OIDC) pour l'authentification. Comme le transport supposé est internet, les composants d'un SSO Web sont définis par des standards IETF et fonctionnent comme les développeurs Web s'y attendent. De plus, l'authentification est étroitement couplée à l'autorisation et recourt à des méthodes d'accès comme les protocoles REST et à des standards d'information basés sur JSON, pour un système complet et extensible. Les systèmes de SSO Web sont également conçus pour fonctionner entre domaines et à grande échelle.

• LDAP. Le protocole Lightweight Directory Access Protocol (LDAP) a été introduit dans les années 1990 pour permettre aux utilisateurs de trouver des ressources sur un réseau local, comme des serveurs ou des imprimantes. Il repose sur un serveur faisant autorité, connaissant l'ensemble des ressources d'un domaine. De ce fait, il n'est pas adapté à un usage sur internet.

  LDAP étant utilisé pour accorder l'accès aux ressources réseau, il inclut un système d'authentification stockant les identifiants des utilisateurs sur le serveur LDAP. Ses mécanismes d'authentification ne sont pas robustes ; par exemple, il envoie parfois les mots de passe en clair sur le réseau. Le chiffrement peut être assuré par un autre protocole, comme SSL/TLS.

  LDAP a l'avantage d'être flexible et extensible ; les entreprises peuvent y stocker des informations additionnelles sur les employés, comme les rôles, les appartenances à des groupes, l'emplacement du bureau ou le numéro de téléphone. Cependant, en entreprise, des privilèges d'accès plus granulaires sont souvent nécessaires, par exemple, savoir qui peut accéder à quelles données, et LDAP les gère difficilement.

• JWT. Les JSON Web Tokens sont des documents compacts permettant de transmettre des informations de manière structurée et sécurisée entre différentes parties. Ils répondent au même besoin que les documents SAML, mais dans un format plus concis, adapté à l'inclusion dans des URL. Les JWT sont signés cryptographiquement à l'aide de techniques de chiffrement à clé publique pour garantir leur authenticité. Dans OAuth (Open Authorization), une fois l'utilisateur authentifié, le serveur d'identité renvoie un jeton d'identification au format JSON.

  Les demandes d'autorisation d'accès à des ressources protégées renvoient ensuite un jeton d'accès JSON, qui doit être inclus dans chaque requête vers le serveur de ressources. Ces transactions transmettent l'état du client, ici authentifié et autorisé, dans chaque requête, ce qui en fait des échanges dits RESTful. REST (« representational state transfer ») est avantageux, car les serveurs de ressources n'ont pas à établir et maintenir des sessions avec chaque client souhaitant utiliser leurs ressources.

  Les JWT sont des documents en clair ; ils doivent donc être utilisés sur des connexions chiffrées HTTPS. Les jetons sont généralement conçus pour ne pas contenir de données sensibles, comme des informations personnellement identifiables. Chaque jeton étant signé conformément à X.509, le standard international de formatage des certificats à clé publique, cette signature est validée par les serveurs de ressources pour garantir l'intégrité du jeton. Les JWT sont des composants d'un système d'authentification et d'autorisation OAuth/OpenID. Ils sont conçus pour les applications Web, passent à l'échelle et sont destinés à fonctionner entre domaines.

Avantages du SSO

Les professionnels IT et sécurité plébiscitent le SSO : ils savent que cela centralise l'authentification des utilisateurs, protège des informations potentiellement sensibles et facilite l'intégration avec les systèmes et applications d'entreprise. Ils sont généralement prêts à prendre en charge la formation des utilisateurs, ainsi que la supervision et la maintenance continues. C'est la conséquence directe de plusieurs bénéfices majeurs apportés par la technologie.

• Accès centralisés. Les systèmes de SSO simplifient la gestion des comptes et des accès aux nombreuses applications utilisées par les entreprises et les fournisseurs cloud. Les droits d'accès des utilisateurs à toutes les applications peuvent être accordés et révoqués en un seul endroit. Ainsi, si un collaborateur quitte l'entreprise, les administrateurs n'ont pas à supprimer ses identifiants application par application. Les équipes sécurité peuvent aussi faire évoluer les systèmes d'authentification en un point unique, sans modifier chaque application.
• Une sécurité améliorée. Le SSO réduit fortement le nombre de couples identifiant/mot de passe que les employés doivent mémoriser. Ce fardeau allégé, il devient pertinent, surtout en entreprise, de renforcer la sécurité des échanges d'authentification via l'authentification multifacteur (MFA) et des politiques de mots de passe renforcées.
• Augmenter la productivité des collaborateurs. Avec le SSO, les employés peinent moins à se souvenir de leurs identifiants et mots de passe. Une fois authentifiés, les utilisateurs accèdent généralement aux applications sans se réauthentifier. Le SSO permet donc aux collaborateurs d'accéder plus rapidement à leurs tâches. Selon l'implémentation, une authentification dans certaines applications peut subsister, mais au moins il suffit de retenir les identifiants SSO.
• Moins de fatigue liée aux mots de passe. Soyons honnêtes : personne ne veut gérer des dizaines de couples identifiant/mot de passe. La difficulté de mémoriser des mots de passe complexes, surtout s'ils doivent être changés souvent, engendre de la frustration et pousse à utiliser des mots de passe faciles à deviner, à les réutiliser ou à recourir aux Post‑it. Le SSO allège cette charge.
• Conformité réglementaire. Le SSO peut faciliter la conformité réglementaire grâce aux bénéfices de la gestion centralisée des accès. L'audit et la remédiation sont simplifiés puisqu'il n'y a qu'un seul cadre SSO à contrôler.
• Intégration simplifiée . Une entreprise type gère des pétaoctets (Po) de données répartis sur de nombreuses instances de bases de données. On imagine aisément une base de données pour la production, une autre pour la supply chain, et d'autres pour la finance, le marketing, les ventes, etc. On comprend aussi l'utilité pour les commerciaux d'accéder, par exemple, aux données de stock. Un CRM pourrait accéder à ces données, mais chaque commercial doit être reconnu à la fois par la base de données de gestion des stocks et par le CRM. Le SSO fournit l'identité vérifiée du demandeur et les jetons d'accès permettent de déterminer quelles données chaque rôle est autorisé à voir. Sans SSO, l'intégration entre CRM et système de stock serait bien plus complexe à créer et à gérer, impliquerait une authentification supplémentaire pour les utilisateurs ou affaiblirait potentiellement la sécurité des données de stock.
• Expérience utilisateur rationalisée. Réduire la nécessité de s'authentifier dans les applications d'entreprise et Web améliore généralement l'expérience utilisateur. Et comme beaucoup sont habitués au SSO via leurs usages personnels, la formation requise est souvent minimale.

SSO et sécurité : le SSO est‑il sécurisé ?

Tout d'abord, la sécurité absolue n'existe pas ; il n'y a que des degrés de sécurité. Cela dit, tout cadre SSO disponible sur le marché est hautement sécurisé, c'est tout l'intérêt de la technologie. En général, le SSO seul n'est pas une solution de sécurité exhaustive. C'est plutôt un composant essentiel d'un environnement sécurisé. Son rôle de système à la fois d'authentification des utilisateurs et de fourniture d'identifiants d'authentification aux applications et aux systèmes de ressources est un pilier de la stratégie de sécurité globale.

SSO et confidentialité

Le SSO favorise une meilleure confidentialité, mais celle‑ci varie selon l'implémentation. Par exemple, les réponses SAML et JWT contiennent a minima une assertion d'authentification. Elles peuvent aussi inclure des informations telles que les groupes et rôles de l'utilisateur, ainsi que d'autres données choisies par les implémenteurs.

Dans le retail en ligne ou les réseaux sociaux, connaître l'âge, la localisation et d'autres informations personnelles peut être utile à l'application. En général, si vous fournissez de telles informations personnelles à Facebook, supposez qu'elles pourront être partagées, sauf si la politique de confidentialité s'y oppose ou si l'application vous permet d'interdire explicitement certains partages.

En entreprise, les systèmes SSO doivent renvoyer des assertions d'authentification assorties des rôles pertinents de l'utilisateur dans l'organisation. Il peut aussi être utile de fournir le site de rattachement et le numéro de téléphone professionnel. Les autres informations devraient être plus difficiles à obtenir. Ce qui est fourni par défaut est généralement dicté par les politiques RH.

Cas d'usage du SSO

Le SSO est conçu pour offrir un accès fluide à de multiples applications et systèmes avec un seul jeu d'identifiants. Même si des exigences strictes de conformité peuvent imposer des mesures de sécurité supplémentaires, les cas d'usage du SSO sont nombreux. Citons notamment :

• Applications d’entreprise. Une entreprise gère généralement des dizaines, voire des centaines d'applications, chacune nécessitant l'authentification des utilisateurs. Créer et maintenir un système de gestion des identités par application n'est pratique ni pour les utilisateurs ni pour les équipes IT. Le SSO permet d'authentifier une fois les collaborateurs puis de gérer leurs autorisations d'accès aux ressources à partir de cette authentification unique.

  Les assertions d'authentification sont généralement valables pour une durée limitée et sur un seul système. Des informations plus granulaires sur les rôles de chaque collaborateur peuvent être conservées par le système SSO et utilisées par les applications ou systèmes d'autorisation pour limiter les accès aux applications, données et autres ressources.

• Applications cloud. Pour les usages professionnels comme grand public, les systèmes cloud présentent des besoins d'identification et d'autorisation différents de ceux des SSO d'entreprise. Pour les consommateurs, la praticité peut imposer qu'une fois authentifiés, ils puissent utiliser le service de façon durable depuis le même appareil. Une fois connecté à Gmail, par exemple, vous pouvez utiliser ce service et d'autres applications Google (Docs, Sheets…) sans vous réauthentifier. Côté entreprises, les fournisseurs cloud proposant des applications SaaS ou des plateformes et infrastructures en service autorisent aussi un large accès une fois l'identité confirmée. L'authentification est la première étape d'un schéma d'autorisation plus large qui permet de se connecter une fois et d'utiliser un large éventail de services. L'accès aux services dépend des rôles de l'utilisateur pour chaque application, administrateur sur l'une, développeur sur une autre, simple utilisateur sur une troisième. L'accès dépend aussi des offres souscrites par l'organisation.

Mise en œuvre du SSO

Ne laissez pas un manque d'expertise sécurité en interne vous dissuader d'adopter le SSO. Les fournisseurs de services de sécurité managés et les équipes d'implémentation des éditeurs SSO sont là pour vous aider. De nombreuses entreprises choisissent des services SSO proposés par des prestataires tiers. L'entreprise bénéficie d'expertise, de fonctionnalités de sécurité avancées et de montée en charge, tandis que les équipes IT se concentrent sur la croissance en laissant la gestion du SSO aux experts.

À haut niveau, la mise en œuvre repose sur trois éléments majeurs.

1. Choisir et déployer les systèmes d'authentification côté client qui collectent en toute sécurité les informations de connexion (identifiant, mot de passe). Même en entreprise, ces systèmes sont souvent servis via des pages Web, ce qui facilite l'uniformité des processus d'authentification sur tous les appareils. En général, en entreprise, l'utilisateur doit être sur le réseau de l'organisation ou y accéder via un VPN. Cette exigence permet de mettre en place un système de gestion des identités unique et faisant autorité.
2. Mettre en place un gestionnaire d'identités chargé d'authentifier les utilisateurs et d'émettre des certificats au nom de l'organisation. Dans la plupart des environnements, le gestionnaire d'identités fait partie d'un système qui fournit aussi des jetons d'autorisation indiquant aux applications ce que chaque utilisateur est autorisé à faire, ou il est étroitement lié au serveur d'autorisation.
3. Configurer ou modifier les applications pour qu'elles utilisent les certificats et jetons des systèmes de SSO et d'autorisation, plutôt que de conserver leur propre système d'identifiants.

Bonnes pratiques pour le SSO

Que vous implémentiez en interne, avec un tiers ou en mode service, certaines clés conditionnent la réussite. En voici les principales :

1. Imposer l'authentification multifacteur (MFA). De même que le SSO permet d'appliquer des politiques de mots de passe de manière centralisée, il facilite le déploiement de mécanismes d'identification renforcés regroupés sous l'appellation MFA. Ces facteurs peuvent inclure cartes à puce, applications mobiles, différentes formes d'authentification biométrique, etc.
2. Utiliser le contrôle d'accès basé sur les rôles (RBAC). L'authentification ne résout qu'une partie de la gestion des accès aux ressources. L'autre enjeu est de restreindre l'accès des utilisateurs aux seules ressources autorisées. En définissant des groupes, marketing, finance, production, ventes, et des rôles par groupe, on obtient un contrôle d'accès fin et centralisé, plus simple à administrer.
3. Auditer et mettre à jour les standards. Centraliser l'authentification dans un cadre unique simplifie grandement l'audit et les mises à jour nécessaires pour suivre les nouveaux standards.
4. Mettre en place la gestion des rôles et permissions. Le SSO se prête à une philosophie de zero trust. Les utilisateurs n'accèdent qu'aux ressources explicitement requises par leurs rôles et ne voient que les données autorisées.
5. Respecter les lois sur la confidentialité des données. Un cadre SSO n'assure pas à lui seul la conformité aux lois de confidentialité, mais il en facilite grandement l'atteinte et la démonstration.

Contrôlez les accès simplement et en toute sécurité avec Oracle

Besoin de gérer identités et accès pour Oracle Cloud Infrastructure (OCI) et vos applications cloud et on‑premises ? Pour une stratégie de sécurité zero trust, Oracle Cloud Infrastructure Identity and Access Management (IAM) fournit les outils de gestion et d'intégration nécessaires.

Vous souhaitez déployer un authentificateur universel avec support MFA ? Oracle Access Management offre un système flexible, exécutable on‑premises ou dans le cloud. Les organisations peuvent faire « suivre » ces politiques à l'utilisateur, quels que soient l'appareil et l'emplacement, afin de sécuriser l'accès aux données partout, à tout moment, depuis n'importe quel dispositif. Avec la MFA, le portefeuille IAM d'Oracle prend en charge le SSO sur appareil de confiance et le SSO applicatif, indispensables pour concrétiser les principes et exigences d'une architecture zero trust.

À mesure que les entreprises multiplient les applications, elles‑mêmes tributaires de services et sources de données, l'authentification et l'autorisation deviennent plus complexes à gérer. Les cadres SSO simplifient la vie des utilisateurs et des architectes applicatifs en rationalisant l'authentification et l'autorisation.

FAQ sur le SSO

Que signifie SSO ?

SSO signifie authentification unique.

Qu'est‑ce que mon compte SSO ?

Votre compte SSO est un service d'authentification centralisé qui vous permet d'accéder à de multiples applications et systèmes avec un seul jeu d'identifiants. Vous n'avez ainsi qu'un identifiant et un mot de passe à mémoriser pour accéder à tous les services et ressources de votre organisation. Les comptes SSO fluidifient la connexion, améliorent la sécurité et facilitent l'accès aux informations et outils nécessaires.

Un exemple de SSO ?

Dans le monde grand public, des acteurs comme Amazon, Google, Meta ou Microsoft servent de fournisseurs d'identités pour d'autres applications. Si une boîte de dialogue vous propose de saisir vos identifiants ou de vous connecter via l'un de ces services, vous utilisez le SSO.