Gestion des réclamations
Puis, nous devons réfléchir attentivement aux réclamations. Une réclamation est simplement la paire nom/valeur intégrée à nos jetons d’accès et d’identification. Par exemple, vous pourriez avoir une réclamation user_id ou email afin que les applications en aval puissent les utiliser pour créer des profils ou prendre des décisions. Ce qui est déroutant, c’est que la spécification OAuth Core n’introduit pas le concept de réclamation, ni même le mot réclamation. C’est utile car nous pouvons définir ce que nous voulons. Malheureusement, le problème est que les gens vont les définir comme ils le souhaitent. La spécification JWT (RFC 7519) introduit le concept et définit une structure de base mais ne fixe toujours pas de conventions pour les noms, les structures, etc.
L’utilisation d’OpenID Connect nous protège assez bien. Il définit un ensemble simple de réclamations pour les détails de l’utilisateur tels que le nom, l’adresse et similaires. Si nous n’utilisons que celles-ci et limitons l’accès en fonction des scopes appropriés, l’utilisateur sait quelles informations il partage et les applications savent comment les utiliser.
Alternativement, à mesure que nous ajoutons des revendications supplémentaires, le désir naturel est d’avoir un identifiant unique pour l’utilisateur. Si nous sommes réfléchis, nous utilisons une clé primaire obfusquée qui n’a aucune signification en dehors de notre système. Si nous ne sommes pas prudents, il peut s’agir d’un identifiant client, d’un numéro d’employé ou même d’un numéro de sécurité sociale. C’est dans cette même situation que Facebook se débat avec les implications du partage de trop d’informations sur le réseau d’un utilisateur via son API.
Nous devons être réfléchis et envisager les conséquences des informations que nous mettons dans nos tokens. Nous ne devrions jamais inclure des données « juste au cas où » et attendre plutôt des cas d’utilisation spécifiques que nous choisissons de soutenir. Tout le reste est au mieux risqué et au pire irresponsable.
Types d’octroi – Quand et pourquoi
Alors que j’ai sauté directement dans les portées et les revendications, l’autre erreur la plus courante est liée aux types ou flux d’octroi OAuth spécifiques. Les quatre types d’octroi – Code d’autorisation, Implicite, Mot de passe du propriétaire de la ressource et Créance du client – définissent comment une application peut récupérer les jetons de votre serveur OAuth et sont utilisés dans différents cas d’utilisation.
Code d’autorisation
Le flux Code d’autorisation est le plus puissant et le plus sécurisé par défaut. Lorsque l’application redirige l’utilisateur vers le fournisseur d’identité pour s’authentifier, l’IdP lui renvoie un code d’autorisation à usage unique et de courte durée. L’application utilise le code d’autorisation pour récupérer le jeton d’accès.
La partie importante est double : Premièrement, au moment où l’utilisateur voit le code d’autorisation, celui-ci a déjà été consommé et ne peut donc pas être utilisé à nouveau. Deuxièmement, le jeton d’accès est conservé par l’application dans le backend. En supposant que l’application est construite de manière sécurisée, un utilisateur malveillant doit trouver un autre moyen de l’attaquer.
Malheureusement, cela ne fonctionne pas pour les applications côté client, comme de nombreuses applications Javascript ou la plupart des applications mobiles, car l’application elle-même peut être attaquée ou décompilée pour obtenir des informations sensibles. Par conséquent, nous avons besoin d’une approche différente.
Implicit
Le flux Implicit est conçu spécifiquement pour les apps mobiles ou les apps Javascript côté client où les informations d’identification intégrées pourraient être compromises. La mécanique est simple en ce sens que l’application redirige l’utilisateur vers le fournisseur d’identité pour s’authentifier, l’IdP renvoie le(s) jeton(s) et l’application l’utilise en fonction des scopes dont elle dispose.
Puisqu’il est fort probable que l’utilisateur puisse interagir avec le(s) jeton(s), il est important que nos cas d’utilisation reflètent cela. Si nous avons une application bancaire, autoriser le scope send_wire_transfers_to_russia peut être une mauvaise idée, à moins que nous ayons des facteurs supplémentaires intégrés dans notre processus d’authentification pour valider que le bon utilisateur l’utilise. La prochaine fois que vous perdrez votre téléphone, vous apprécierez cela.
En conséquence, ceci est souvent utilisé pour les scénarios OpenID Connect où un utilisateur veut fournir des informations de profil de confiance à un tiers, mais pas nécessairement un accès ou des autorisations à d’autres systèmes. Comme les concepts sous-jacents sont les mêmes et que la mise en œuvre semble très similaire, c’est la plupart des avantages pour le même effort.
Mot de passe du propriétaire de la ressource
Par rapport aux types d’octroi précédents, le mot de passe du propriétaire de la ressource me rend nerveux. Avec les flux Code d’autorisation et Implicite, l’application redirige l’utilisateur vers le fournisseur d’identité pour soumettre son nom d’utilisateur et son mot de passe. Par conséquent, l’application ne voit jamais ses informations d’identification. Avec le flux Resource Owner Password, l’application accepte elle-même les informations d’identification et les soumet au nom de l’utilisateur.
Si l’application est malveillante ou même simplement mal développée, elle pourrait stocker ces informations d’identification et compromettre les informations de l’utilisateur. Par conséquent, vous ne devriez l’utiliser que si vous construisez des applications pour que vos utilisateurs puissent interagir avec vos systèmes existants. Par exemple, une banque peut le mettre en œuvre pour un portail interne destiné aux employés.
Mais n’oubliez pas : Fondamentalement, vous formez les utilisateurs à mettre leurs informations d’identification dans des applications auxquelles ils ne font peut-être pas confiance, ce qui est une mauvaise habitude au mieux et un risque de sécurité en tout temps.
Client Credential
Le type d’octroi Client Credential est conçu exclusivement pour les opérations de serveur à serveur backend. Pensez-y comme le nom d’utilisateur et le mot de passe d’un serveur. Conceptuellement, ce n’est pas loin de la façon dont votre application se connecte à d’autres systèmes backend tels que votre base de données ou Twilio. L’avantage est que votre fournisseur OAuth peut renvoyer des informations de configuration ou d’autres détails dans le jeton lui-même.
Enfin, comme il n’y a pas d’utilisateur impliqué, il ne prend pas en charge OpenID Connect.
En conclusion
Bien que tout ce post ait porté sur OAuth, vous avez probablement remarqué que je n’ai pas inclus de code. La raison en est simple : Les décisions de conception sont encore plus importantes.
Si vos champs d’application sont trop larges ou si vos demandes incluent des informations sensibles ou si vous mettez en œuvre le mauvais flux pour l’environnement, les meilleures bibliothèques du monde ne vous protégeront pas. Les informations de vos utilisateurs seront compromises, vos applications seront vulnérables et votre entreprise en subira les conséquences. Alternativement, si vous comprenez les cas d’utilisation de votre logiciel et ce que vos utilisateurs essaient d’accomplir, votre logiciel sera meilleur, plus sécurisé, et vous pourrez limiter les e-mails « Nous sommes désolés… » à vos clients.
Pour plus de lecture
À partir de là, nous pouvons continuer à aller dans les protocoles, les bibliothèques individuelles ou les grands livres sur le sujet. Si vous voulez comprendre comment les RFC individuelles s’assemblent, consultez le livre OAuth2.0 Simplified d’Aaron Parecki et la carte des spécifications OAuth 2.0 qui l’accompagne. C’est mon aide-mémoire sur les liens vers les principales spécifications et sur ce qu’elles couvrent. Tout ce qui précède a inspiré mon guide des pratiques recommandées pour la gestion de l’accès aux API, qui détaille les bons principes de conception et de développement pour les clients OAuth, les serveurs d’autorisation, les passerelles API et vos applications.
.