Les applications de bureau et mobiles sont intégrées dans l’application pour aider à compléter l’ensemble du processus OAuth 2.0
Le processus est illustré sur la figure
OAuth2.0 web 1) Renvoyer l’authencode au Web redirectUri spécifié (cet URI est configuré par le développeur de l’application) 2) Pour modifier le jeton, vous devez passer l’identifiant client et le clientSecret afin de vérifier l’identité client (obtenue par le service backend de l’application)
En notant les deux points ci-dessus, 1) Parce que l’application web n’est pas invalide : la détection de redirections Uri n’est pas valide 2) Parce qu’il n’existe pas de client de service backend, Secret n’est pas sécurisé Ensuite, l’attaque que nous pourrions rencontrer est la suivante : comme montré dans la figure ci-dessous, il peut y avoir une application malveillante interceptant authCode pour envoyer un message à l’AuthorizationServer afin d’obtenir le jeton, de sorte que le jeton est obtenu sans l’autorisation du client pour l’application mais vers une autre autorisation officielle, atteignant ainsi l’objectif de l’attaque.
Solution :
1. Le client génère une chaîne aléatoire : vérificateur de code et enregistre cette chaîne aléatoire code_challenge = transform(code_verifier, [Plaine| S256]) Si la méthode de transformation est simple, alors le défi de code est équivalent à un vérificateur de code Si la méthode de transformation est S256, alors le défi de code est égal au hachage Sha256 du vérificateur de code 2. Apporter un défi de code à la demande de code d’autorisation et à la manière de générer un défi de code. Ces deux éléments sont liés au code d’autorisation émis par le serveur 3. Après avoir obtenu le code d’autorisation, le client apporte le vérificateur de code initialement généré lors de l’échange du code d’autorisation contre le Jeton d’Accès. Le serveur calcule le vérificateur de code selon la méthode de transformation liée, compare le résultat calculé avec le défi de code lié, et émet un jeton d’accès s’il est cohérent. |