OAuth2 - Octroi des informations d'identification du mot de passe du propriétaire de la ressource
La spécification OAuth2 décrit le type d'octroi des informations d'identification du mot de passe du propriétaire de la ressource et le flux d'autorisation ici . Je comprends que seules les applications clientes "de confiance" seraient autorisées à utiliser cette subvention, par exemple l'iPhone "officiel" ou Android par API backend).
Ma question est: comment puis-je garantir que les demandes provenant de sources prétendant être cette application client peuvent être approuvées? Par exemple:
J'ai enregistré mon Android sur mon serveur OAuth2 avec l'identifiant client de
Android_appavec accès au type de subventionpassword(c'est-à-dire les informations d'identification du mot de passe du propriétaire de la ressource).Comme l'application Android est une application cliente, j'ai supposé qu'il n'était pas fiable de garder le secret client "secret" et je ne lui en ai donc pas attribué un. La configuration de l'application contient client_id et grant_type ainsi que le point de terminaison d'authentification.
Un utilisateur décompile/décompresse/désobscurcit mon application et trouve le client_id et le point de terminaison
Qu'est-ce qui empêche le client de faire des demandes d'authentification à ce point de terminaison avec l'ID client? J'envisagerais d'attribuer au client un client_secret, mais il semble que cela ne résoudra pas le problème car un utilisateur pourrait simplement le trouver dans l'application.
Ce sont vraiment deux questions.
Comment puis-je garantir que les demandes provenant de sources qui prétendent être cette application client peuvent être approuvées?
Vous ne pouvez pas. Le la spécification dit :
Le type d'attribution des informations d'identification du mot de passe du propriétaire de la ressource convient dans les cas où le propriétaire de la ressource a une relation de confiance avec le client [...]
Le propriétaire de la ressource (alias. Utilisateur) doit décider s'il fait confiance au client, pas au serveur d'autorisation. Si l'utilisateur décide de faire tellement confiance à une application tierce qu'il entre son mot de passe simple, vous ne pouvez pas détecter automatiquement si l'application tierce est fiable.
Qu'est-ce qui empêche le client de faire des demandes d'authentification à ce point de terminaison avec l'ID client? je envisagez d'attribuer au client un client_secret, mais il semble que cela ne résoudra pas le problème car un utilisateur pourrait simplement le trouver dans l'application.
OAuth2 fait la différence entre clients confidentiels et clients publics . Les clients confidentiels sont "capables de maintenir la confidentialité de leurs identifiants", par exemple une application web qui accède à une autre côté serveur.
Les applications natives (comme une application Android Android) sont explicitement mentionnées en tant que clients publics:
Une application native est un client public installé et exécuté sur l'appareil utilisé par le propriétaire de la ressource. Les données de protocole et les informations d'identification sont accessibles au propriétaire de la ressource. Il est supposé que toutes les informations d'authentification client incluses dans l'application peuvent être extraites. [...]
Par conséquent un secret client n'ajoutera pas de sécurité à une application native dans la plupart des cas d'utilisation.
Comment puis-je garantir que les demandes provenant de sources prétendant être cette application client peuvent être approuvées?
Tu ne peux pas.
Pour citer un autre SO answer :
Le fait est que, dans le mobile, l'application est déjà fiable, une fois que l'utilisateur a installé l'application, il a choisi de lui faire confiance [...] En fin de compte, je ne pense pas qu'il soit possible de protéger complètement les utilisateurs d'une application une fois qu'ils ont 'ai décidé de lui faire confiance en l'installant.
Qu'est-ce qui empêche le client de faire des demandes d'authentification à ce point de terminaison avec l'ID client?
Rien.
Vous pouvez uniquement vous concentrer sur la protection du nom d'utilisateur/mot de passe de vos utilisateurs, par exemple:
- ne les stockez pas dans votre application.
- éduquez vos utilisateurs avec des explications claires sur où trouver vos applications officielles et pourquoi ils ne devraient pas faire confiance à une autre application leur demandant leurs informations d'identification.
Une petite explication:
Pour accéder aux ressources, une application doit obtenir un jeton d'accès (et éventuellement un jeton d'actualisation facultatif).
Pour obtenir le jeton d'accès, une première demande comprenant le nom d'utilisateur et le mot de passe doit être envoyée au point de terminaison. Remarque: client_id et client_secret ne sont obligatoires que pour les clients confidentiels ou pour tout client ayant reçu des informations d'identification client.
Ainsi, l'application malveillante ne peut accéder à aucune ressource tant qu'elle n'a pas obtenu le nom d'utilisateur et le mot de passe, sinon elle ne pourra pas obtenir de jeton d'accès. Même s'il utilise l'identité de votre application officielle.
L'exemple fourni est en fait un très mauvais exemple pour la raison exacte que vous avez mentionnée - un attaquant peut simplement extraire le secret du client et se faire passer pour le client.
La sécurité de cette subvention dépend de la façon dont ce secret client peut être protégé. De plus, cela dépend de la façon dont le canal peut être protégé, de sorte qu'un attaquant ne peut pas créer un homme au milieu et extraire le secret de la demande. Si vous pouvez protéger les deux, vous êtes dans une bonne position, mais c'est vraiment difficile à faire pour les applications mobiles.
Pour répondre à votre question: vous ne pouvez vraiment pas. Vous pouvez atténuer certains de ces problèmes en:
- en utilisant des ID client et des secrets uniques pour chaque instance de l'application, mais cela complique sérieusement la gestion
- ou vous pouvez stocker les secrets dans une quincaillerie de confiance, mais le protocole requiert le mot à mot secret
- ou vous pouvez modifier le protocole pour utiliser un identifiant client basé sur un jeton comme l'utilisation d'un jeton JWT ou SAML signé par le secret client, de cette façon une assertion de courte durée signée par le secret est passée à la place du secret, etc.
Ajoutez tous ces éléments ensemble et vous avez un moyen assez solide d'identifier le client, mais ce n'est certainement pas infaillible et il a certainement ses inconvénients: la gérabilité est un PITA, comment faites-vous l'échange secret initial?, Etc.