L'authentification avec des appareils partagés comporte un ensemble unique de défis. Certains scénarios sont propres à l'effectif d'une organisation, tandis que certains cas d'utilisation sont spécifiques aux consommateurs. Dans cet article, je me concentrerai sur les scénarios de consommateurs et j'explorerai les défis et les options possibles pour traiter l'authentification des appareils partagés en toute sécurité.
Les défis liés à l'authentification des appareils partagés
De nombreuses organisations et services utilisent des bornes et des appareils partagés afin d'améliorer l'expérience client, l'efficacité opérationnelle grâce au libre-service et l'évolutivité avec la croissance de la clientèle. Parmi les exemples notables, citons les bornes déployées dans les systèmes de point de vente (POS) au détail, les centres de divertissement et d'événements, les hôtels, les aéroports, les bibliothèques et les cliniques médicales.
Dans le scénario du consommateur, les principaux défis sont les suivants :
- L'utilisateur doit fournir ses informations d'identification sur un appareil public. Cela augmente le risque d'exposition des informations d'identification et peut nuire à l'adoption par les consommateurs.
- La session utilisateur peut rester active après que l'utilisateur s'est éloigné du système sans se déconnecter explicitement, ce qui entraîne un risque de prise de contrôle de la session.
- L'application de l'authentification biométrique résistante au phishing, comme les passkeys, n'est pas réalisable.
Les applications gèrent souvent l'authentification des appareils partagés de manière assez exclusive, par exemple en utilisant des lecteurs RFID, des documents officiels ou des lecteurs de cartes de paiement. De plus, de nombreux systèmes demandent une authentification traditionnelle par identifiant d'utilisateur et mot de passe, comme les ordinateurs dans une bibliothèque.
Authentification découplée avec l’appareil partagé
Une meilleure façon de faire pourrait être de dissocier l’authentification de l’application exécutée sur l’appareil partagé. Si l’authentification peut être effectuée à l’aide d’un appareil de confiance, souvent un téléphone intelligent ou une tablette en possession de l’utilisateur, certains des problèmes peuvent être résolus de façon transparente. Voici des exemples de ces défis :
- L'utilisateur n'a jamais besoin de fournir des informations d'identification ou d'identification à l'application s'exécutant sur les appareils partagés.
- L'authentification biométrique à l'épreuve du phishing peut être facilement utilisée, car l'utilisateur s'authentifie à partir d'un appareil personnel.
Examinons une norme d'authentification découplée prometteuse : OAuth 2.0 Device Authorization Grant
Présentation du flux d'autorisation des appareils
Le flux d'autorisation de l'appareil a été initialement conçu pour fournir une authentification découplée aux appareils à contraintes d'entrée tels que les téléviseurs intelligents. Souvent, ces appareils ne sont pas livrés avec un navigateur à usage général pour permettre à un utilisateur de s'authentifier à l'aide d'un flux fédéré sécurisé, ou rendent fastidieux la saisie de leurs informations d'identification. Le cadre d'autorisation de l'appareil offre un moyen de permettre à un consommateur d'utiliser son appareil personnel (ordinateur portable, mobile ou tablette) pour effectuer l'authentification à la place.
Argumenter en faveur du flux d'autorisation de l'appareil
Device authorization flow fournit une solution élégante dans le scénario d'authentification des appareils partagés. L'idée est la suivante :
- L'application crée une URL de connexion aléatoire et un code d'utilisateur. Elle peut également intégrer l'URL et le code d'utilisateur dans un code QR. L'application affiche ensuite les informations à l'utilisateur.
- L'utilisateur peut scanner le code QR ou taper manuellement le lien de connexion sur le navigateur de son appareil.
- Ils compléteraient ensuite le flux d'authentification sur leur appareil en fournissant leurs informations d'identification. Pour les applications sensibles, le processus d'authentification peut inclure des facteurs résistants au phishing tels que les passkeys.
- Enfin, ils saisissent le code utilisateur.
- Une fois le processus d'autorisation terminé, l'application de l'appareil partagé se poursuivra avec le jeton d'authentification reçu.
L'utilisateur n'a jamais besoin de fournir d'informations d'authentification sur l'appareil partagé. Au lieu de consentir à un défi d'autorisation (comme avec CIBA), elle effectue l'authentification de bout en bout sur l'appareil de confiance.
Le flux d'autorisation de l'appareil a été initialement conçu pour les appareils à saisie limitée tels que les téléviseurs ou les interfaces de ligne de commande (CLI). Cependant, dans les appareils partagés, les informations d'identification de l'utilisateur ne sont pas sécurisées, ce qui fait du flux un candidat idéal pour l'authentification des appareils partagés.
Voici comment fonctionne le flux d'autorisation de périphérique OAuth 2.0 :
Gestion de session et déconnexion
Même si le flux d'autorisation de l'appareil est adapté à l'authentification de première ligne sur les appareils partagés, l'application ou le système doit toujours gérer les sessions et les jetons.
Les jetons doivent avoir une faible durée d'expiration et ne jamais être stockés dans un stockage persistant, contrairement à ceux des téléviseurs ou des appareils intelligents, où les jetons à longue durée de vie sont généralement justifiés.
L'application doit également réinitialiser la session et effacer le jeton d'accès et le code de l'appareil immédiatement après la fermeture du navigateur ou de l'application.
L'application ou l'appareil doit suivre l'inactivité de l'utilisateur et expirer dans un court délai. En cas de délai d'attente, il doit rapidement réinitialiser la session utilisateur et effacer les jetons.
Option de repli
Que se passe-t-il si l'utilisateur ne transporte pas d'appareil personnel adapté à l'authentification ? L'application doit également disposer d'une option de connexion de secours appropriée, telle que SMS ou e-mail, et d'une authentification sans mot de passe basée sur OTP. Pour être complet, l'application peut également autoriser la connexion traditionnelle basée sur mot de passe, mais avec prudence et des messages pédagogiques affichés à l'utilisateur.
Okta prend en charge le flux d'autorisation de périphérique
Okta continue de dominer l'espace de la gestion des identités et des accès en offrant une prise en charge du flux d'autorisation de l'appareil Grant, une spécification OAuth 2.0 (RFC 8628).
Grâce à la capacité d'Okta à prendre en charge diverses autres méthodes d'authentification avec et sans mot de passe, vous pouvez facilement implémenter un système d'authentification fiable pour les applications exécutées sur un appareil partagé. Le flux d'autorisation de l'appareil permet d'améliorer l'expérience utilisateur et d'améliorer considérablement la sécurité en découplant l'authentification de l'appareil partagé lui-même. En offrant un processus d'intégration simplifié via des API et des SDK, Okta facilite l'utilisation de ce protocole moderne. Alors que les entreprises s'appuient de plus en plus sur des appareils sans surveillance pour les interactions avec les clients, l'approche novatrice d'Okta garantit une expérience d'authentification fluide et sécurisée pour les consommateurs.
Le flux d'autorisation de périphérique, bien que conçu à l'origine pour traiter l'authentification des périphériques à entrée limitée, est un excellent outil pour gérer l'authentification des consommateurs à partir de périphériques partagés. Okta facilite la mise en œuvre sécurisée de l'authentification des appareils partagés grâce à la prise en charge prête à l'emploi du flux d'autorisation des appareils.
Lectures complémentaires
Qu'est-ce que le flux d'autorisation des appareils
Spécification d'autorisation d'appareil OAuth 2.0
