La popularité des applications mobiles continue de croître. Il en va de même pour le protocole OAuth 2.0 sur les applications mobiles. Il ne suffit pas d'implémenter la norme comme c'est de sécuriser le protocole OAuth 2.0 là-bas. Il faut considérer les spécificités des applications mobiles et appliquer des mécanismes de sécurité supplémentaires.

Dans cet article, je souhaite partager les concepts d'attaques mobiles OAuth 2.0 et les mécanismes de sécurité utilisés pour éviter de tels problèmes. Les concepts décrits ne sont pas nouveaux mais il y a un manque d'informations structurées sur ce sujet. L'objectif principal de l'article est de combler cette lacune.

Nature et objectif d'OAuth 2.0

OAuth 2.0 est un protocole d' autorisation qui décrit un moyen pour un service client d'obtenir un accès sécurisé aux ressources de l'utilisateur sur un fournisseur de services. Grâce à OAuth 2.0, l'utilisateur n'a pas besoin de saisir son mot de passe en dehors du prestataire: l'ensemble du processus se réduit à cliquer sur le bouton "J'accepte de donner accès à ...".

Un fournisseur est un service qui détient les données utilisateur et, avec l'autorisation de l'utilisateur, fournit des services tiers (clients) avec un accès sécurisé à ces données. Un client est une application qui souhaite obtenir les données utilisateur stockées par le fournisseur.

Peu de temps après la publication du protocole OAuth 2.0, il a été adapté pour l' authentification , même s'il n'était pas destiné à cela. L'utilisation d'OAuth 2.0 pour l'authentification déplace un vecteur d'attaque des données stockées chez le fournisseur de services vers les comptes d'utilisateurs du service client.

Mais l'authentification n'était qu'un début. À l'époque des applications mobiles et de la glorification des conversions, accéder à une application avec un seul bouton semblait agréable. Les développeurs ont adapté OAuth 2.0 pour une utilisation mobile. Bien sûr, peu de gens se sont inquiétés de la sécurité et des spécificités des applications mobiles: zappez et dans la production, ils sont allés! Là encore, OAuth 2.0 ne fonctionne pas bien en dehors des applications Web: il y a les mêmes problèmes dans les applications mobiles et de bureau.

Voyons donc comment sécuriser OAuth 2.0 mobile.

Comment ça marche?

Il existe deux principaux problèmes de sécurité pour OAuth 2.0 mobile:

Client non fiable. Certaines applications mobiles n'ont pas de backend pour OAuth 2.0, donc la partie client du flux de protocole va sur l'appareil mobile.
Les redirections d'un navigateur vers une application mobile se comportent différemment selon les paramètres du système, l'ordre dans lequel les applications sont installées et d'autres éléments magiques.

Examinons en profondeur ces problèmes.

L'application mobile est un client public

Pour comprendre les racines et les conséquences du premier problème, voyons comment OAuth 2.0 fonctionne en cas d'interaction de serveur à serveur, puis comparons-le avec OAuth 2.0 en cas d'interaction client-serveur.

Dans les deux cas, tout commence par les registres du service client sur le service fournisseur et reçoit client_id et , dans certains cas , client_secret. client_id , client_secret. client_id est une valeur publique, et elle est requise pour l'identification du service client par opposition à la valeur client_secret , qui est privée. Vous pouvez en savoir plus sur le processus d'enregistrement dans la RFC 7591 .

Le schéma ci-dessous montre le fonctionnement d'OAuth 2.0 en cas d'interaction de serveur à serveur.

Origine de l'image: https://tools.ietf.org/html/rfc6749#section-1.2

Le protocole OAuth 2.0 peut être divisé en trois étapes principales:

[étapes AC] Recevez un code authorization_code (ci-après, code ).
[étapes DE] Échangez le code pour access_token .
Obtenez la ressource via access_token .

Développons le processus d'obtention de code valeur du code :

[Étape A] Le client redirige l'utilisateur vers le fournisseur de services.
[Étape B] Le fournisseur de services demande l'autorisation à l'utilisateur de fournir les données au client (flèche B vers le haut). L'utilisateur fournit un accès aux données (flèche B à droite).
[Étape C] Le fournisseur de services renvoie le code au navigateur de l'utilisateur qui redirige le code vers le client.

Parlons davantage du processus d'obtention de access_token :

[Étape D] Le serveur client envoie une demande d' access_token . Code , client_secret et redirect_uri sont inclus dans la demande.
[Étape E] En cas de code valide, client_secret et redirect_uri , access_token est fourni.

La demande d' access_token se fait selon le schéma de serveur à serveur: par conséquent, en général, l'attaquant doit pirater le serveur de service client ou le serveur du fournisseur de services afin de voler access_token .

Examinons maintenant le schéma OAuth 2.0 mobile sans backend (interaction client-serveur).

Origine de l'image: https://tools.ietf.org/html/rfc8252#section-4.1

Le schéma principal est divisé en les mêmes étapes principales:

[étapes 1-4 dans l'image] Obtenez le code .
[étapes 5-6 dans l'image] code échange pour access_token
Accédez aux ressources via access_token

Cependant, dans ce cas, l'application mobile a également les fonctions de serveur; par conséquent, client_secret serait intégré à l'application. Par conséquent, client_secret ne peut pas être caché aux attaquants sur les appareils mobiles. Le client_secret intégré peut être extrait de deux manières: en analysant le trafic d'application vers serveur ou par rétro-ingénierie. Les deux peuvent être facilement implémentés, et c'est pourquoi client_secret est inutile sur les appareils mobiles.

Vous pourriez vous demander: "Pourquoi ne recevons-nous pas access_token ?" Vous pourriez penser que cette étape supplémentaire n'est pas nécessaire. De plus, il existe un schéma de subvention implicite qui permet à un client de recevoir access_token . Même si elle peut être utilisée dans certains cas, la subvention implicite ne fonctionnerait pas pour OAuth 2.0 mobile sécurisé.

Redirection sur les appareils mobiles

En général, le mécanisme d' URI personnalisé et les mécanismes AppLink sont utilisés pour la redirection du navigateur vers l'application. Aucun de ces mécanismes ne peut être aussi sûr que le navigateur redirige seul.

Le schéma d'URI personnalisé (ou lien profond) est utilisé de la manière suivante: un développeur détermine un schéma d'application avant le déploiement. Le schéma peut être n'importe lequel et un appareil peut avoir plusieurs applications avec le même schéma.

Cela facilite les choses lorsque chaque schéma d'un appareil correspond à une application. Mais que se passe-t-il si deux applications enregistrent le même schéma sur un seul appareil? Comment le système d'exploitation décide-t-il quelle application ouvrir lorsqu'il est contacté via un schéma d'URI personnalisé? Android affichera une fenêtre avec le choix d'une application et un lien à suivre. iOS n'a pas de procédure pour cela et, par conséquent, l'une ou l'autre application peut être ouverte. Quoi qu'il en soit, l'attaquant a la possibilité d'intercepter du code ou access_token .

Contrairement au schéma d'URI personnalisé, AppLink garantit d'ouvrir la bonne application, mais ce mécanisme présente plusieurs défauts:

Chaque client du service doit subir la procédure de vérification .
Les utilisateurs d'Android peuvent désactiver AppLink pour une application spécifique dans les paramètres.
Les versions Android antérieures à 6.0 et les versions iOS antérieures à 9.0 ne prennent pas en charge AppLink.

Toutes ces failles AppLink augmentent la courbe d'apprentissage pour les clients de services potentiels et peuvent entraîner une défaillance de l'utilisateur OAuth 2.0 dans certaines circonstances. C'est pourquoi de nombreux développeurs ne choisissent pas le mécanisme AppLink comme substitution pour la redirection de navigateur dans le protocole OAuth 2.0.

OK, qu'est-ce qu'il y a à attaquer?

Les problèmes liés à Mobile OAuth 2.0 ont créé des attaques spécifiques. Voyons ce qu'ils sont et comment ils fonctionnent.

Attaque d'interception de code d'autorisation

Considérons la situation où la machine utilisateur a une application légitime (client OAuth 2.0) et une application malveillante qui a enregistré le même schéma que celui légitime. L'image ci-dessous montre le schéma d'attaque.

Origine de l'image https://tools.ietf.org/html/rfc7636#section-1

Voici le problème: à la quatrième étape, le navigateur renvoie le code dans l'application via un schéma d'URI personnalisé et, par conséquent, le code peut être intercepté par une application malveillante (car il est enregistré le même schéma qu'une application légitime). Ensuite, l'application malveillante modifie le code en access_token et reçoit l'accès aux données de l'utilisateur.

Quelle est la protection? Dans certains cas, vous pouvez utiliser la communication inter-processus; nous en parlerons plus tard. En général, vous avez besoin d'un schéma appelé clé de preuve pour l'échange de code . Il est décrit dans le schéma ci-dessous.

Origine de l'image: https://tools.ietf.org/html/rfc7636#section-1.1

La demande client a plusieurs paramètres supplémentaires: code_verifier , code_challenge (dans le schéma t(code_verifier) ) et code_challenge_method (dans le schéma t_m ).

Code_verifier - est un nombre aléatoire d'une longueur minimale de 256 bits , qui n'est utilisé qu'une seule fois . Ainsi, un client doit générer un nouveau code_verifier pour chaque demande de code .

Code_challenge_method - il s'agit du nom d'une fonction de conversion, principalement SHA-256.

Code_challenge - est code_verifier auquel la conversion code_challenge_method été appliquée et qui a été codé dans URL Safe Base64.

La conversion de code_verifier en code_challenge est nécessaire pour repousser les vecteurs d'attaque basés sur l'interception de code_verifier (par exemple, à partir des journaux système de l'appareil) lors de la demande de code .

Dans le cas où une client is allowed to use plain conversion of code_verifier utilisateur ne prend pas en charge SHA-256, un client is allowed to use plain conversion of code_verifier . Dans tous les autres cas, SHA-256 doit être utilisé.

Voici comment fonctionne ce schéma:

Le client génère code_verifier et le mémorise.
Le client choisit code_challenge_method et reçoit code_challenge de code_verifier .
[Étape A] Le client demande du code , avec code_challenge et code_challenge_method ajoutés à la demande.
[Étape B] Le fournisseur stocke code_challenge et code_challenge_method sur le serveur et renvoie le code à un client.
[Étape C] Le client demande access_token , auquel code_verifier ajouté code_verifier .
Le fournisseur reçoit code_challenge de code_challenge entrant, puis le compare à code_challenge , qu'il a enregistré.
[Étape D] Si les valeurs correspondent, le fournisseur donne au client access_token .

Pour comprendre pourquoi code_challenge interception de code, voyons à quoi ressemble le flux de protocole du point de vue de l'attaquant.

Tout d'abord, le code demandes d'application légitimes ( code_challenge et code_challenge_method sont envoyés avec la demande ).
Une application malveillante intercepte le code (mais pas code_challenge , car le code _challenge ne figure pas dans la réponse).
Une application malveillante demande access_token (avec un code valide, mais sans code_verifier valide).
Le serveur remarque une incompatibilité de code_challenge et déclenche un message d'erreur.

Notez que l'attaquant ne peut pas deviner code_verifier (valeur aléatoire de 256 bits!) Ou le trouver quelque part dans les journaux (puisque la première requête a réellement transmis code_challenge ).

Ainsi, code_challenge répond à la question du fournisseur de services: " access_token est- access_token demandé par le même client d'application qui a demandé le code ou un autre?".

OAuth 2.0 CSRF

OAuth 2.0 CSRF est relativement inoffensif lorsque OAuth 2.0 est utilisé pour l'autorisation. C'est une tout autre histoire quand OAuth 2.0 est utilisé pour l'authentification. Dans ce cas, OAuth 2.0 CSRF conduit souvent à une prise de contrôle de compte.

Parlons plus de l'attaque CSRF conformément à OAuth 2.0 à travers l'exemple du client de l'application de taxi et du fournisseur provider.com. Tout d'abord, un attaquant sur son propre appareil se connecte au compte attacker@provider.com et reçoit le code de taxi. Il interrompt ensuite le processus OAuth 2.0 et génère un lien:

 com.taxi.app://oauth? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4

Ensuite, l'attaquant envoie ce lien à sa victime, par exemple, sous la forme d'un courrier ou d'un message texte provenant de taxi. La victime clique sur le lien, l'application taxi s'ouvre et reçoit access_token . En conséquence, ils se retrouvent dans le compte de taxi de l' attaquant . Ignorant cela, la victime utilise ce compte: faire des voyages, saisir des données personnelles, etc.

Désormais, l'attaquant peut se connecter à tout moment au compte de taxi de la victime, car il est lié à attacker@provider.com . L'attaque de connexion CSRF a permis au contrevenant de voler un compte.

Les attaques CSRF sont généralement repoussées avec un jeton CSRF (il est également appelé state ), et OAuth 2.0 ne fait pas exception. Comment utiliser le jeton CSRF:

L'application client génère et enregistre le jeton CSRF sur l'appareil mobile d'un client.
L'application client inclut le jeton CSRF dans la demande d'accès au code .
Le serveur renvoie le même jeton CSRF avec le code dans sa réponse.
L'application client compare les jetons CSRF entrants et enregistrés. Si leurs valeurs correspondent, le processus se poursuit.

Exigences de jeton CSRF: nonce doit être d'au moins 256 bits et reçu d'une bonne source de séquences pseudo-aléatoires.

En bref, le jeton CSRF permet à un client d'application de répondre à la question suivante: "Est-ce moi qui access_token lancé la demande access_token ou quelqu'un essaie de me access_token ?".

Secret client codé en dur

Les applications mobiles sans backend stockent parfois des valeurs client_id et client_secret client_id dur. Bien sûr, ils peuvent être facilement extraits par une application d'ingénierie inverse.

L'impact de l'exposition de client_id et client_secret dépend fortement de la quantité de fournisseur de services de confiance mise sur la certaine paire client_id , client_secret . On les utilise juste pour distinguer un client d'un autre tandis que d'autres ouvrent des points de terminaison d'API cachés ou font des limites de taux plus souples pour certains clients.

L'article Pourquoi les clés et les secrets de l'API OAuth ne sont pas sûrs dans les applications mobiles développe plus sur ce sujet.

Application malveillante agissant en tant que client légitime

Certaines applications malveillantes peuvent imiter les applications légitimes et afficher un écran de consentement en leur nom (un écran de consentement est un écran où un utilisateur voit: "J'accepte de fournir l'accès à ..."). L'utilisateur peut cliquer sur «autoriser» et fournir à l'application malveillante ses données.

Android et iOS fournissent les mécanismes de recoupement des applications. Un fournisseur d'application peut s'assurer qu'une application client est légitime et vice versa.

Malheureusement, si le mécanisme OAuth 2.0 utilise un thread via un navigateur, il est impossible de se défendre contre cette attaque.

Autres attaques

Nous avons examiné de plus près les attaques exclusives au mobile OAuth 2.0. Cependant, n'oublions pas l'original OAuth 2.0: substitution redirect_uri , interception du trafic via une connexion non sécurisée, etc. Vous pouvez en lire plus ici .

Comment le faire en toute sécurité?

Nous avons appris le fonctionnement du protocole OAuth 2.0 et ses vulnérabilités sur les appareils mobiles. Maintenant, assemblons les pièces séparées pour avoir un schéma OAuth 2.0 mobile sécurisé.

Bon, mauvais OAuth 2.0

Commençons par la bonne façon d'utiliser l'écran de consentement. Les appareils mobiles ont deux façons d'ouvrir une page Web dans une application mobile.

La première façon est via l'onglet personnalisé du navigateur (à gauche sur l'image). Remarque : l'onglet personnalisé du navigateur pour Android est appelé onglet personnalisé Chrome et pour iOS - SafariViewController. C'est juste un onglet de navigateur affiché dans l'application: il n'y a pas de basculement visuel entre les applications.

La deuxième façon se fait via WebView (à droite sur la photo) et je le considère mauvais par rapport au mobile OAuth 2.0.

WebView est un navigateur intégré pour une application mobile.

" Navigateur intégré " signifie que l'accès aux cookies, au stockage, au cache, à l'historique et à d'autres données Safari et Chrome est interdit pour WebView. L'inverse est également correct: Safari et Chrome ne peuvent pas accéder aux données WebView.

« Navigateur d'applications mobiles » signifie qu'une application mobile qui exécute WebView a un accès complet aux cookies, au stockage, au cache, à l'historique et à d'autres données WebView.

Maintenant, imaginez: un utilisateur clique sur "entrer avec ..." et une WebView d'une application malveillante demande son identifiant et son mot de passe au fournisseur de services.

Échec épique:

L'utilisateur entre son identifiant et son mot de passe pour le compte du fournisseur de services dans l'application, qui peut facilement voler ces données.
OAuth 2.0 a été initialement développé pour ne pas entrer le login et le mot de passe du fournisseur de services.

L'utilisateur s'habitue à saisir son identifiant et son mot de passe n'importe où, augmentant ainsi les possibilités de pêche .

Compte tenu de tous les inconvénients de WebView, une conclusion évidente s'offre: utilisez l'onglet personnalisé du navigateur pour l'écran de consentement.

Si quelqu'un a des arguments en faveur de WebView au lieu de l'onglet personnalisé du navigateur, j'apprécierais que vous écriviez à ce sujet dans les commentaires.

Schéma OAuth 2.0 mobile sécurisé

Nous allons utiliser le schéma d'autorisation de code d'autorisation, car il nous permet d'ajouter code_challenge ainsi que d' state et de se défendre contre une attaque d'interception de code et OAuth 2.0 CSRF.

Origine de l'image: https://tools.ietf.org/html/rfc8252#section-4.1

La demande d'accès au code (étapes 1-2) se présente comme suit:

 https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 3D% 3D & https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c

À l'étape 3, le navigateur obtient une réponse avec redirection:

 com.mail.cloud.app://outh? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24

À l'étape 4, le navigateur ouvre le schéma d'URI personnalisé et transmet le jeton CSRF à une application cliente.
demande access_token (étape 5):

 https://o2.mail.ru/token? code_verifier=e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc& code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& client_id=984a644ec3b56d32b0404777e1eb73390c

La dernière étape apporte une réponse avec access_token .

Ce schéma est généralement sécurisé, mais il existe des cas particuliers où OAuth 2.0 peut être plus simple et plus sécurisé.

IPC Android

Android dispose d'un mécanisme de communication de données bidirectionnelle entre les processus: IPC (communication inter-processus). IPC est meilleur que le schéma d'URI personnalisé pour deux raisons:

Une application qui ouvre le canal IPC peut confirmer l'authenticité d'une application qu'elle ouvre par son certificat. L'inverse est également vrai: l'application ouverte peut confirmer l'authenticité de l'application qui l'a ouverte.
Si un expéditeur envoie une demande via le canal IPC, il peut recevoir une réponse via le même canal. Avec le recoupement (élément 1), cela signifie qu'aucun processus étranger ne peut intercepter access_token .

Par conséquent, nous pouvons utiliser la subvention implicite pour simplifier le schéma OAuth 2.0 mobile. Aucun code_challenge et state signifie également moins de surface d'attaque. Nous pouvons également réduire les risques que des applications malveillantes agissent comme un client légitime essayant de voler les comptes d'utilisateurs.

SDK pour les clients

Outre la mise en œuvre de ce schéma OAuth 2.0 mobile sécurisé, un fournisseur doit développer un SDK pour ses clients. Cela simplifiera la mise en œuvre d'OAuth 2.0 côté client et réduira simultanément le nombre d'erreurs et de vulnérabilités.

Conclusions

Permettez-moi de le résumer pour vous. Voici la liste de contrôle (de base) pour OAuth 2.0 sécurisé pour les fournisseurs OAuth 2.0:

Une base solide est cruciale. Dans le cas d'OAuth 2.0 mobile, la fondation est un schéma ou un protocole choisi pour la mise en œuvre. Il est facile de faire des erreurs lors de l' implémentation de votre propre schéma OAuth 2.0 . D'autres ont déjà frappé et appris leur leçon; il n'y a rien de mal à apprendre de leurs erreurs et à sécuriser la mise en œuvre en une seule fois. Le schéma OAuth 2.0 mobile le plus sécurisé est décrit dans Comment le faire en toute sécurité ?
Access_token et d'autres données sensibles doivent être stockés dans le trousseau pour iOS et dans le stockage interne pour Android. Ces stockages ont été spécialement développés spécialement pour cela. Le fournisseur de contenu peut être utilisé dans Android, mais il doit être configuré en toute sécurité.
Client_secret est inutile , sauf s'il est stocké dans le backend. Ne le donnez pas aux clients publics.
N'utilisez pas WebView pour l'écran de consentement; utilisez l'onglet personnalisé du navigateur.
Pour vous défendre contre une attaque d'interception de code, utilisez code_challenge .
Pour vous défendre contre OAuth 2.0 CSRF, utilisez state .
Utilisez HTTPS partout , avec rétrogradation interdite à HTTP. Voici une démo de 3 minutes expliquant pourquoi (avec un exemple de bug bounty).
Suivez les normes de cryptographie (choix de l'algorithme, longueur des jetons, etc.). Vous pouvez copier les données et comprendre pourquoi cela a été fait de cette façon, mais ne lancez pas votre propre crypto.
Code doit être utilisé qu'une seule fois, avec une courte durée de vie.
Du côté client de l'application, vérifiez ce que vous ouvrez pour OAuth 2.0; et du côté du fournisseur d'applications, vérifiez qui vous ouvre pour OAuth 2.0.
Gardez à l'esprit les vulnérabilités courantes d'OAuth 2.0 . Mobile OAuth 2.0 agrandit et complète l'original, par conséquent, la vérification de redirect_uri pour une correspondance exacte et d'autres recommandations pour OAuth 2.0 d'origine sont toujours en vigueur.
Vous devez fournir à vos clients un SDK. Ils auront moins de bogues et de vulnérabilités et il leur sera plus facile d'implémenter votre OAuth 2.0.

Lectures complémentaires

"Vulnérabilités du mobile OAuth 2.0" https://www.youtube.com/watch?v=vjCF_O6aZIg
Recherche sur les conditions de course OAuth 2.0 https://hackerone.com/reports/55140
Presque tout sur OAuth 2.0 en un seul endroit https://oauth.net/2/
Pourquoi les clés et les secrets de l'API OAuth ne sont pas sécurisés dans les applications mobiles https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
[RFC] OAuth 2.0 pour les applications natives https://tools.ietf.org/html/rfc8252
[RFC] Clé de preuve pour l'échange de code par les clients publics OAuth https://tools.ietf.org/html/rfc7636
[RFC] Modèle de menace OAuth 2.0 et considérations de sécurité https://tools.ietf.org/html/rfc6819
[RFC] Protocole d'enregistrement de client dynamique OAuth 2.0 https://tools.ietf.org/html/rfc7591
Google OAuth 2.0 pour applications mobiles et de bureau https://developers.google.com/identity/protocols/OAuth2InstalledApp

Crédits

Merci à tous ceux qui m'ont aidé à écrire cet article. Surtout à Sergei Belov, Andrei Sumin, Andrey Labunets pour les commentaires sur les détails techniques, à Pavel Kruglov pour la traduction anglaise et à Daria Yakovleva pour l'aide à la sortie de la version russe de cet article.

Sécurité du mobile OAuth 2.0