Dans l’écosystème Internet d’applications de plus en plus étroitement liées, lorsqu’une application veut effectuer une action sur une autre application au nom d’un utilisateur, il est nécessaire de savoir comment le faire sans partager le mot de passe d’une application à une autre. Un exemple courant de ceci est la connecte avec Facebook par des applications qui veulent poster quelque chose sur votre journal ou qui veulent accéder à votre Google Drive. Si vous partagez votre mot de passe Facebook avec ces applications pour qu’elles puissent accéder à votre journal et qu’une violation de données se produise avec ces applications, vos informations d’identification Facebook sont également menacées. En outre, en partageant votre mot de passe, vous donnez à ces applications le plein contrôle de votre compte Facebook au lieu d’un accès limité. Pour résoudre ce défi, un protocole, appelé OAuth, a été défini.
Oauth
OAuth est un protocole/cadre d’autorisation standard ouvert qui permet aux applications d’accéder limité aux comptes utilisateur d’une autre application sans partager de mot de passe. Ces applications reçoivent un jeton d’autorisation qui peut être utilisé pour utiliser les services d’une autre application en votre nom sans compromettre votre mot de passe. OAuth peut être utilisé pour autoriser des applications, des API, des périphériques et des serveurs.
À un niveau élevé, il s’agit d’un processus d’autorisation délégué sécurisé et d’un accès limité sur HTTP plutôt que d’utiliser vos informations d’identification qui minimise le risque de sécurité. En cas d’atteinte à la sécurité et que vos données sont volées dans l’application qui a accès à votre Facebook, votre mot de passe Facebook est sécurisé. Pas de soucis.
OAuth a deux versions – OAuth 1.0a et OAuth 2.0. Les deux versions diffèrent complètement les unes des autres en termes de spécifications et ne sont pas compatibles pour être utilisées ensemble. Mais oAuth version 2.0 est utilisé le plus largement et nous allons nous concentrer sur celui-ci seulement tout en se référant à OAuth sauf indication explicite.
Acteurs et flux
Il y a quatre acteurs, aussi appelés rôles, dans un flux oauth.
- Propriétaire de ressources (utilisateur) – le propriétaire des données respectives qui réside sur le serveur de ressources. Le propriétaire de la ressource autorise l’accès au compte qui se limite à la portée de l’autorisation accordée.
- Serveur de ressources (API) – C’est là que le compte/ressources utilisateur est hébergé dans un environnement protégé.
- Client (Application) – l’application qui demande l’accès au compte utilisateur.
- Serveur d’autorisation (API) – Le serveur d’autorisation effectue la vérification d’identité afin d’émettre le jeton d’accès.
Ces acteurs interagissent les uns avec les autres sur la base du protocole OAuth. Veuillez noter que le protocole OAuth est une question d’autorisation et non d’authentification. Le flux général d’un protocole OAuth est le suivant :
- Le client veut accéder au serveur de ressources et demande la permission de l’utilisateur.
- L’utilisateur autorise ou nie la demande.
- En cas d’autorisation, le client obtient une subvention d’autorisation.
- Le client présente donc cette subvention d’autorisation et son identité au serveur d’autorisation et demande un jeton d’accès.
- Si le client a à la fois une identité valide et une subvention d’autorisation, le serveur d’autorisation lui fournit un jeton d’accès.
- Le client se rend donc sur le serveur de ressources et demande l’accès à la ressource en lui présentant le jeton d’accès.
- Le serveur de ressources ne fournit l’accès limité autorisé au client que si le jeton est valide.
Défis dans le suivi des applications activées par OAuth
La mise en œuvre d’OAuth permet à votre application d’accéder aux ressources du serveur sur d’autres applications avec une protection de la vie privée et une grande expérience utilisateur. Mais dans le même temps, OAuth pose quelques défis dans le suivi de votre application. Examinons ces défis.
Gestion des jetons – La mise en œuvre d’OAuth nécessite la gestion des jetons avec la direction de l’État. Cela signifie que ces jetons sont rafraîchis et tournés. Si une erreur d’autorisation se produit, il devient difficile de déterminer quel acteur du protocole OAuth est fautif. Cela devient un cauchemar débougeant.
OAuth demande / réponse dépendance – Que se passe-t-il si votre fournisseur oauth a changé quelque chose dans son mécanisme ? Même le moindre changement dans les params de demande/réponse peut briser l’ensemble de votre application. Il peut prendre un certain temps avant de le comprendre si vos développeurs ne prêtent pas attention aux nouvelles versions par votre fournisseur OAuth.
Rappels – Selon la mise en œuvre, il peut prendre plus d’un appel api entre tous les acteurs pour une transaction OAuth réussie. Dans la plupart des cas, la méthode des rappels est utilisée pour y parvenir, ce qui peut être suffisamment complexe pour être suivi si quelque chose se brise entre les deux. Les outils de surveillance traditionnels ne suffisent pas à repérer les erreurs de rappel, à augmenter le temps de débogage et donc à augmenter vos temps d’arrêt.
Configuration – Ceci est important pour faciliter la vie de votre équipe DevOps. Si vous utilisez un outil de surveillance qui ne se spécialise pas dans les tâches HTTP(S) hautement configurables, vous aurez du mal à surveiller les flux OAuth impliquant l’expiration/renouvellement de jetons et plusieurs appels API sur HTTP(s).
La solution pour surveiller les applications activées par OAuth
La surveillance synthétique est un excellent choix lorsque nous traitons avec des dépendances tierce, HTTP(S), DES API REST, des chemins d’utilisateurs complexes, et le mécanisme de connexion personnalisé comme OAuth, etc.
La surveillance synthétique fonctionne en simulant les comportements des utilisateurs finaux avec des scripts personnalisés, dans un environnement hautement configurable pour prendre en charge la flexibilité de l’architecture, puis en surveillant le trafic et le flux de manière proactive. Cela permet de détecter et de résoudre les problèmes avant que les utilisateurs réels ne les affrontent. La plate-forme Dotcom-Monitor utilise un outil de script point and click, appelé EveryStep Web Recorder, pour créer des scripts qui peuvent simuler des chemins d’utilisateur, ainsi que pour vérifier le contenu qui est retourné en réponse à des actions spécifiques. Pour relever les défis de suivi posés par la mise en œuvre d’OAuth, vous devrez utiliser des outils de surveillance synthétique spécialisés avec les capacités must-have suivantes :
Surveillance des transactions Web en plusieurs étapes – Comme nous l’avons brièvement mentionné, une transaction oauth réussie est un processus en plusieurs étapes entre ses acteurs. La surveillance synthétique vous donne la possibilité de configurer une surveillance en plusieurs étapes pour les transactions OAuth et de les surveiller en permanence pour la disponibilité et les performances. La surveillance multitâle vous indiquera exactement quelle étape est responsable du flux cassé afin que vous soyez en mesure de le réparer rapidement.
Scripts personnalisés avec tâches HTTP/S – La mise en œuvre réelle d’OAuth diffère d’une application à l’autre en fonction des stratégies d’architecture et de sécurité.
L’outil synthétique de surveillance des services Web vous permet d’écrire des tâches HTTP (s) hautement configurables et des scripts personnalisés pour des chemins d’utilisateurs complexes. Cela vous aidera à surveiller le flux de bout en bout de la transaction OAuth de votre application et la santé globale des API et des rappels. En outre, si vous devez vérifier les données, telles que les noms d’utilisateur, qui sont retournées en réponse, vous pouvez configurer les scripts avec l’enregistreur Web EveryStep pour vérifier ces mots clés spécifiques.
En plus de ces capacités, les outils de surveillance synthétiques sont un atout précieux pour surveiller les dépendances de tiers, les services Web et les protocoles (PROTOCOLES SOAP, REST, TCP et ICMP), et l’infrastructure. Dotcom-Monitor vous permet de configurer une transaction en plusieurs étapes pour l’API Web basée sur OAuth à l’aide de la tâche HTTP (s) et de vérifier en permanence la disponibilité, les performances et les fonctionnalités 24 heures sur 24, 7 jours sur 7.
Essayez la plate-forme Dotcom-Monitor gratuite pendant 30 jours.
