Connexion universelle centralisée par rapport à la Connexion intégrée
Lorsque vous concevez l’expérience d’authentification pour votre application, vous devez choisir si le flux de connexion utilisera la connexion universelle ou intégrée.
Avec la Connexion universelle, lorsque les utilisateurs essaient de se connecter, ils sont redirigés vers un domaine central, par lequel l’authentification est effectuée, puis ils sont redirigés vers l’application. Exemple : G Suite. Peu importe le service auquel vous essayez d’accéder (Gmail, Google calendar, Google docs, etc.) si vous n’êtes pas connecté, vous êtes redirigé vers
https://accounts.google.comet une fois que vous vous connectez avec succès, vous êtes redirigé vers l’application appelante.D’autre part, un flux de connexion intégrée ne redirige pas l’utilisateur vers un emplacement central. Le gadget logiciel de connexion est servi à partir de la même page sans rediriger l’utilisateur vers un autre domaine. Les identifiants sont ensuite envoyés au fournisseur d’authentification pour l’authentification. Dans une application Web, il s’agit d’une requête cross-origin.
Avantages et inconvénients
| Fonctionnalité | Centralisé | Intégré |
|---|---|---|
| Authentification unique | Si vous travaillez avec des applications mobiles, vous ne pouvez pas avoir de SSO à moins d’utiliser la Connexion universelle. Avec les applications web, vous pouvez, bien que le moyen le plus sûr soit d’utiliser un service central pour que les témoins proviennent de la même origine. | Avec la connexion intégrée, vous devez collecter les identifiants utilisateur dans une application servie à partir d’une origine et ensuite les envoyer à une autre origine, ce qui peut présenter certaines vulnérabilités de sécurité, y compris la possibilité d’une attaque par hameçonnage. |
| Cohérence et entretien | Votre serveur d’autorisation (le domaine qui connecte les utilisateurs) possède toutes les pages de connexion, ce qui facilite la gestion et rend les pages plus cohérentes et sécurisées. Vous pouvez également utiliser une seule page de connexion parmi vos applications, un processus qui donne l’impression que les utilisateurs se connectent à un système centralisé plutôt qu’à une application individuelle. | Si vous avez plus d’une application, vous devez mettre en œuvre plusieurs pages de connexion. Vous devrez également maintenir et gérer ces pages. En plus de l’effort supplémentaire, il peut également introduire des incohérences qui se traduisent par un mauvais UX. De plus, avec la connexion intégrée, vous auriez à gérer les dangers des vecteurs d’attaques inter-origines. |
| Gestion des fonctionnalités | Vous pouvez activer et désactiver des fonctionnalités comme le MFA, dans toutes vos applications, à l’aide du Dashboard. | Doit être fait pour chaque application individuellement. |
| Expérience utilisateur | Redirigé vers un autre sous-domaine pour se connecter. | Non redirigé vers un autre sous-domaine pour se connecter. |
| Applications mobiles et sécurité | Selon la Meilleure pratique actuelle pour OAuth 2.0 pour les applications natives - Demande de commentaires, seuls les agents utilisateurs externes (comme le navigateur) doivent être utilisés par les applications natives pour les flux d’authentification. L’utilisation du navigateur pour effectuer des demandes d’autorisation d’applications natives améliore la sécurité et donne aux utilisateurs la confiance qu’ils entrent les informations d’identification dans le bon domaine. Il permet également l’utilisation de l’état d’authentification actuel de l’utilisateur, ce qui rend possible l’authentification unique (SSO). | Les agents utilisateur intégrés sont considérés comme dangereux pour des tiers et ne doivent pas être mis en œuvre. Avec la connexion native, une application malveillante pourrait tenter de pirater les utilisateurs pour obtenir un identifiant/mot de passe ou des jetons. De plus, si vos applications mobiles utilisent une connexion native, vos utilisateurs doivent entrer leurs identifiants pour chacune de vos applications, donc l’authentification unique n’est pas possible. |
Risques de sécurité
La Connexion universelle est plus sûre que la connexion intégrée. L'authentification s'effectue sur le même domaine, ce qui élimine les demandes inter-origines. L'authentification inter-origines est intrinsèquement plus dangereuse. La collecte des identifiants de l'utilisateur dans une application mono-origine et leur envoi à une autre origine peuvent présenter certaines vulnérabilités en matière de sécurité. Les attaques par hameçonnage sont plus probables, de même que les attaques par interception. La Connexion universelle n'envoie pas d'informations entre les origines, ce qui élimine les problèmes liés aux origines multiples. Pour en savoir plus, consulter Prévenir les attaques de cybersécurité courantes.
Les agents utilisateurs intégrés ne sont pas sûrs pour les tiers, y compris le serveur d’autorisations lui-même. Si une connexion intégrée est utilisée, l’application a accès à la fois à l’autorisation et aux identifiants de l’utilisateur. Par conséquent, ces données risquent d’être détournées. Même si l’application est fiable, il n’est pas nécessaire de lui permettre d’accéder à l’autorisation ainsi qu’aux identifiants complets de l’utilisateur. Cela viole le principe du moindre privilège et augmente le risque d’attaques.
Google ne prend plus en charge l’approche intégrée lors de l’implémentation d’OAuth. En outre, selon l’Internet Engineering Task Force (IETF), les demandes d’autorisation des applications natives ne devraient être effectuées que par l’intermédiaire d’agents utilisateurs externes, principalement le navigateur de l’utilisateur. L’utilisation d’un navigateur pour les demandes d’autorisation des applications natives permet d’améliorer la sécurité. Lorsque des agents intégrés sont utilisés, l’application a accès à l’autorisation OAuth ainsi qu’aux identifiants de l’utilisateur, ce qui l’expose à être enregistrée ou utilisée à des fins malveillantes.
Une autre ressource utile est la Modernisation des interactions OAuth dans les applications natives pour une meilleure utilisabilité et une meilleure sécurité sur https://developers.googleblog.com.
Connexion universelle avec Auth0
Dans la plupart des cas, nous recommandons d’utiliser une stratégie de connexion universelle, dans laquelle Auth0 affichera une page de connexion si l’authentification est requise. Vous pouvez personnaliser votre page de connexion à l’aide du Dashboard.
Vous pouvez utiliser les domaines personnalisés d’Auth0 pour conserver le même domaine sur la page de connexion et l’application. La redirection vers la page de connexion sera transparente pour vos utilisateurs car le domaine ne changera pas. Pour en savoir plus, veuillez consulter Domaines personnalisés.
Lorsque votre application déclenche une demande d’authentification, l’utilisateur est redirigé vers la page de connexion afin de s’authentifier. Cela créera un témoin. Lors des demandes d’authentification suivantes, Auth0 vérifiera la présence de ce témoin, et s’il est présent, l’utilisateur ne sera pas redirigé vers la page de connexion. Il ne verra la page que lorsqu’il devra se connecter. C’est la façon la plus simple d’implémenter la connexion unique (SSO).
Notez que si la demande d’authentification entrante utilise un fournisseur d’identités externe (par exemple, Facebook), la page de connexion ne sera pas affichée. Au lieu de cela, Auth0 dirigera l’utilisateur vers la page de connexion du fournisseur d’identités.
Vous pouvez déployer votre page de connexion personnalisée à partir d’un référentiel externe, comme GitHub, Bitbucket, GitLab ou Microsoft Entra ID.
Nous recommandons la Connexion universelle lorsque vous utilisez Auth0. Il s’agit de la solution la plus sécurisée. L'utilisation de la connexion universelle Auth0 au lieu d'intégrer la connexion dans votre application offre une protection transparente contre la falsification de requête intersite. Cela permet d’éviter l’usurpation d’identité d’un tiers ou le détournement de sessions.
Connexion intégrée avec Auth0
Les connexions intégrées dans les applications web avec Auth0 utilisent l’authentification inter-origines. (Pour en savoir plus, consulter Authentification inter-origines). Ce système utilise des témoins tiers pour permettre des transactions d’authentification sécurisées entre différentes origines. Cela ne s’applique pas aux applications natives puisqu’elles utilisent le point de terminaison OAuth 2.0 /token. Pour en savoir plus sur les témoins tiers, consulter suivi et confidentialité : Témoins tiers sur https://developer.mozilla.org.
Auth0 ne recommande pas l’utilisation de l’authentification cross-origin; faites-le uniquement lorsque vous vous authentifiez auprès d’un répertoire à l’aide d’un identifiant et d’un mot de passe. Les fournisseurs d’identités sociaux et la fédération d’entreprise utilisent un mécanisme différent, redirigeant via des protocoles standard comme OpenID Connect (OIDC) et SAML. En outre, l’authentification cross-origin ne s’applique qu’aux connexions intégrées sur le Web (à l’aide de Lock ou auth0.js). Les applications natives utilisant la connexion intégrée utilisent le point de terminaison standard OAuth 2.0 Token (Jeton 2.0).
En outre, si vous n’avez pas activé les domaines personnalisés, l’utilisateur final doit disposer d’un navigateur qui prend en charge les témoins tiers. Sinon, dans certains navigateurs, l’authentification cross-origin échouera. Cette limitation s’applique aux connexions traditionnelles de base de données avec identifiant/mot de passe ainsi qu’aux connexions de base de données sans mot de passe.