Quel est le bon flux OAuth 2.0 pour une application mobile ?

Question

J'essaie de mettre en œuvre l'autorisation déléguée dans une API Web pour les applications mobiles en utilisant OAuth 2.0. Selon les spécifications, le flux d'octroi implicite ne prend pas en charge les jetons d'actualisation, ce qui signifie qu'une fois qu'un jeton d'accès est accordé pour une période spécifique, l'utilisateur doit accorder à nouveau des autorisations à l'application lorsque le jeton expire ou est révoqué.

Je suppose que c'est un bon scénario pour un code javascript s'exécutant sur un navigateur, comme cela est mentionné dans la spécification. J'essaie de réduire au minimum le nombre de fois où l'utilisateur doit accorder des autorisations à l'application pour obtenir un jeton, il semble donc que le flux de code d'autorisation soit une bonne option car il prend en charge les jetons de rafraîchissement.

Cependant, ce flux semble dépendre fortement d'un navigateur web pour effectuer les redirections. Je me demande si ce flux est toujours une bonne option pour une application mobile si un navigateur web intégré est utilisé. Ou dois-je opter pour le flux implicite ?

Answer 1

Clarification : Application mobile = application native

Comme indiqué dans d'autres commentaires et dans quelques sources en ligne, l'implicite semble être une solution naturelle pour les applications mobiles, mais la meilleure solution n'est pas toujours évidente (et en fait, l'implicite n'est pas recommandé pour les raisons exposées ci-dessous).

Meilleures pratiques pour les applications natives OAuth2

Quelle que soit l'approche que vous choisissez (il y a quelques compromis à prendre en compte), vous devez prêter attention aux meilleures pratiques décrites ici pour les applications natives utilisant OAuth2 : https://www.rfc-editor.org/rfc/rfc8252

Envisagez les options suivantes

Implicite

Dois-je utiliser l'implicite ?

Pour citer la section 8.2 https://www.rfc-editor.org/rfc/rfc8252#section-8.2

Le flux d'autorisation d'octroi implicite d'OAuth 2.0 (défini dans la section 4.2 d'OAuth 2.0 [RFC6749]) fonctionne généralement avec la pratique consistant à effectuer la demande d'autorisation dans le navigateur et à recevoir la réponse d'autorisation via une communication inter-applications basée sur l'URI.
Cependant, comme le flux implicite ne peut pas être protégé par PKCE [RFC7636] (ce qui est requis dans la section 8.1), l'utilisation de l'Implicit Flow avec des applications natives n'est PAS RECOMMANDEE .

Les jetons d'accès accordés via le flux implicite ne peuvent pas non plus être rafraîchis sans interaction avec l'utilisateur, ce qui rend le flux d'octroi de code d'autorisation -- qui peut émettre des jetons d'actualisation - est l'option la plus pratique pour les autorisations d'applications natives qui nécessitent l'actualisation des jetons d'accès.

Code d'autorisation

Si vous optez pour le code d'autorisation, une approche consisterait à utiliser votre propre composant de serveur Web qui enrichit les demandes de jetons avec le secret du client pour éviter de le stocker dans l'application distribuée sur les appareils.

Extrait ci-dessous de : https://dev.fitbit.com/docs/oauth2/

Le flux d'octroi de code d'autorisation est recommandé pour les applications qui ont un service web. Ce flux nécessite une communication de serveur à serveur en utilisant le secret du client d'une application.

Note : Ne mettez jamais votre secret client dans du code distribué, tel que des applications téléchargées via une boutique d'applications ou du JavaScript côté client.

Les applications qui ne disposent pas d'un service web doivent utiliser l'option Implicit d'octroi implicite.

Conclusion

La décision finale doit tenir compte de l'expérience que vous souhaitez offrir à l'utilisateur, mais aussi de votre goût du risque, après avoir procédé à une évaluation correcte des risques liés aux approches présélectionnées et avoir mieux compris leurs implications.

Une bonne lecture est ici https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Un autre est https://www.oauth.com/oauth2-servers/oauth-native-apps/ qui stipule

La meilleure pratique actuelle de l'industrie est d'utiliser le flux d'autorisation tout en omettant le secret du client, et d'utiliser un agent utilisateur externe pour pour compléter le flux. Un agent utilisateur externe est généralement le navigateur natif de l'appareil navigateur natif de l'appareil, (avec un domaine de sécurité distinct de l'application native,) afin que l'application ne puisse pas accéder au stockage des cookies ou inspecter ou modifier le contenu de la page à l'intérieur du navigateur.

Considération du PKCE

Vous devriez également considérer PKCE qui est décrit ici. https://www.oauth.com/oauth2-servers/pkce/

Plus précisément, si vous implémentez également le serveur d'autorisation, alors https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ stipule que vous devez

• Permettre aux clients d'enregistrer des schémas d'URL personnalisés pour leurs URL de redirection.
• Prise en charge des URL de redirection d'IP de bouclage avec des numéros de port arbitraires afin de prendre en charge les applications de bureau.
• Ne croyez pas que les applications natives puissent garder un secret. Exigez que toutes les applications déclarent si elles sont publiques ou confidentielles, et ne délivrez des secrets clients qu'aux applications confidentielles.
• Supporter l'extension PKCE, et exiger que les clients publics l'utilisent.
• Tenter de détecter lorsque l'interface d'autorisation est intégrée à la vue Web d'une application native, au lieu d'être lancée dans un navigateur système, et rejeter ces demandes.

Considération des vues Web

Il existe de nombreux exemples dans la nature qui utilisent des Web Views, c'est-à-dire un user-agent intégré, mais cette approche doit être évitée (en particulier lorsque l'application n'est pas de première partie) et, dans certains cas, elle peut entraîner l'interdiction d'utiliser une API, comme le montre l'extrait ci-dessous tiré de aquí démontre

Toute tentative d'intégrer la page d'authentification OAuth 2.0 aura pour conséquence que votre application sera interdite d'accès à l'API Fitbit.

Pour des raisons de sécurité, la page d'autorisation OAuth 2.0 doit être présentée dans une vue dédiée du navigateur. Les utilisateurs de Fitbit peuvent uniquement confirmer qu'ils s'authentifient auprès du véritable site Fitbit.com que s'ils disposent les outils fournis par le navigateur, tels que la barre URL et le certificat TLS (Transport Layer Security). et les informations du certificat TLS (Transport Layer Security).

Pour les applications natives, cela signifie que la page d'autorisation doit s'ouvrir dans le navigateur par défaut. Les applications natives peuvent utiliser des schémas d'URL personnalisés personnalisés en tant qu'URI de redirection afin de rediriger l'utilisateur du navigateur vers l'application requise. l'application demandant l'autorisation.

Les applications iOS peuvent utiliser la classe SFSafariViewController au lieu de l'application bascule vers Safari. L'utilisation de la classe WKWebView ou UIWebView est interdite.

Les applications Android peuvent utiliser les onglets personnalisés de Chrome au lieu de l'application de basculer vers le navigateur par défaut. L'utilisation de WebView est interdite.

Pour plus de clarté, voici une citation de cet article d'une version antérieure du lien vers les meilleures pratiques fourni ci-dessus

Les agents utilisateurs intégrés, généralement mis en œuvre avec des vues Web, sont une méthode alternative pour autoriser les applications natives. Ils sont cependant dangereux pour l'utilisation par des tiers par définition. Ils impliquent que l'utilisateur l'utilisateur se connecte avec ses identifiants de connexion complets, pour les voir ensuite réduites à des informations d'identification OAuth moins puissantes.

Même lorsqu'ils sont utilisés par des applications tierces de confiance, les agents utilisateurs embarqués violent le principe du moindre privilège en obtenant des informations d'identification plus puissantes plus puissants qu'ils n'en ont besoin, ce qui augmente potentiellement la surface d'attaque.

Dans les implémentations typiques de l'agent utilisateur embarqué basées sur la vue web, l'option l'application hôte peut : enregistrer chaque frappe de touche saisie dans le formulaire pour pour capturer les noms d'utilisateur et les mots de passe ; soumettre automatiquement les formulaires et contourner les contrôles. l'utilisateur ; copier les cookies de session et les utiliser pour effectuer des actions authentifiées en tant qu'utilisateur.

Encourager les utilisateurs à saisir des informations d'identification dans une vue Web intégrée sans la barre d'adresse habituelle et les autres caractéristiques d'identité des navigateurs. il est impossible pour l'utilisateur de savoir s'il se connecte au site Web de l'entreprise. site légitime, et même si c'est le cas, cela leur apprend qu'il est possible de d'entrer des informations d'identification sans valider le site au préalable.

Mis à part les problèmes de sécurité, les vues web ne partagent pas la l'état d'authentification avec d'autres applications ou avec le navigateur du système, ce qui oblige l'utilisateur de se connecter à chaque demande d'autorisation, ce qui entraîne une mauvaise une expérience utilisateur médiocre.

En raison de ce qui précède, l'utilisation d'agents utilisateurs intégrés n'est PAS RECOMMANDÉE, sauf dans le cas où une application tierce de confiance fait office d'agent utilisateur externe pour d'autres applications, ou fournit une authentification unique pour plusieurs applications parties.

Les serveurs d'autorisation DEVRAIENT envisager de prendre des mesures pour détecter et bloquer bloquer les connexions via des agents d'utilisateur intégrés qui ne sont pas les leurs, si possible. possible.

Certains points intéressants sont également soulevés ici : https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

Answer 2

Malheureusement, je ne pense pas qu'il existe une réponse claire à cette question. Cependant, voici les options que j'ai identifiées :

• S'il est acceptable de demander à l'utilisateur ses informations d'identification, alors utilisez la fonction Mot de passe du propriétaire de la ressource . Toutefois, cela peut ne pas être possible pour certaines raisons, à savoir

  • Les politiques d'utilisation ou de sécurité interdisent l'insertion du mot de passe directement dans l'application.
  • Le processus d'authentification est délégué à un fournisseur d'identité externe et doit être effectué via un flux basé sur une redirection HTTP (par exemple OpenID, SAMLP ou WS-Federation).

• Si l'utilisation d'un flux basé sur un navigateur est nécessaire, utilisez alors l'option Flux de code d'autorisation . Ici, la définition de la redirect_uri est un défi majeur, pour lequel il existe les options suivantes :

  • Utilisez la technique décrite dans https://developers.google.com/accounts/docs/OAuth2InstalledApp où une redirect_uri (par exemple urn:ietf:wg:oauth:2.0:oob ) signale au point de terminaison de l'autorisation d'afficher le code d'autorisation au lieu de rediriger vers l'application cliente. L'utilisateur peut copier ce code manuellement ou l'application peut essayer de l'obtenir à partir du titre du document HTML.
  • Utilisez un localhost au niveau de l'appareil (la gestion des ports peut ne pas être aisée).
  • Utilisez un schéma d'URI personnalisé (par ex. myapp://... ) qui, lorsqu'il est déréférencé, déclenche un "gestionnaire" enregistré (les détails dépendent de la plate-forme mobile).
  • S'il est disponible, utilisez une "vue web" spéciale, telle que la WebAuthenticationBroker sur Windows 8, pour contrôler et accéder aux réponses de redirection HTTP.

J'espère que cela vous aidera

Pedro

Answer 3

TL;DR : Utiliser le code d'autorisation Grant avec PKCE

1. Type de subvention implicite

Le type de subvention implicite est assez populaire dans les applications mobiles. Mais il n'a pas été conçu pour être utilisé de cette manière. La redirection pose des problèmes de sécurité. Justin Richer déclare :

Le problème se pose lorsque vous réalisez que, contrairement à ce qui se passe avec un serveur distant il n'existe aucun moyen fiable de s'assurer que la liaison entre un URI de redirection donnée et une application mobile spécifique est honorée. Toute application n'importe quelle application sur l'appareil peut tenter de s'insérer dans le processus de et l'amener à servir l'URI de redirection. Et devinez quoi : si vous avez utilisé le flux implicite dans votre application native, alors vous vous venez de donner votre jeton d'accès à l'attaquant. Il n'y a pas de récupération à partir de Ils ont le jeton et ils peuvent l'utiliser.

Et comme il ne vous permet pas de rafraîchir le jeton d'accès, il vaut mieux l'éviter.

2. Code d'autorisation Type de subvention

L'octroi du code d'autorisation nécessite un secret du client. Mais vous ne devez pas stocker d'informations sensibles dans le code source de votre application mobile. Les gens peuvent les extraire. Pour ne pas exposer le secret du client, vous devez faire fonctionner un serveur comme intermédiaire en tant que Facebook écrit :

Nous recommandons que les jetons d'accès aux applications ne soient utilisés que directement à partir de les serveurs de votre application afin d'assurer la meilleure sécurité possible. Pour les applications native, nous suggérons que l'application communique avec votre propre serveur et serveur effectue ensuite les demandes d'API à Facebook en utilisant le jeton d'accès à l'application. Token d'accès.

Ce n'est pas une solution idéale, mais il existe une nouvelle, une meilleure façon d'utiliser OAuth sur les appareils mobiles : Clé de preuve pour l'échange de codes

3. Type d'octroi de code d'autorisation avec PKCE (Proof Key for Code Exchange)

En dehors de ces limites, une nouvelle technique a été créée qui permet d'utiliser le code d'autorisation sans secret client. Vous pouvez lire l'intégralité RFC 7636 o cette brève introduction .

PKCE (RFC 7636) est une technique permettant de sécuriser les clients publics qui n'utilisent pas un secret de client.

Elle est principalement utilisée par les applications natives et mobiles, mais la technique peut être appliquée à tout client public. Elle nécessite un support supplémentaire supplémentaire par le serveur d'autorisation, elle n'est donc prise en charge que par certains certains fournisseurs.

de https://oauth.net/2/pkce/

Answer 4

L'utilisation d'une vue Web dans votre application mobile devrait être un moyen abordable de mettre en œuvre le protocole OAuth2.0 sur la plate-forme Android.

En ce qui concerne le champ redirect_uri, je pense que http://localhost est un bon choix et vous n'avez pas besoin de porter un serveur HTTP dans votre application, car vous pouvez remplacer l'implémentation de la fonction onPageStarted dans le WebViewClient et arrêter de charger la page web à partir de http://localhost après avoir vérifié le url paramètre.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Answer 5

L'expérience utilisateur la plus fluide pour l'authentification, et la plus facile à mettre en œuvre, consiste à intégrer une vue web dans votre application. Traitez les réponses reçues par la webview depuis le point d'authentification et détectez les erreurs (annulation par l'utilisateur) ou l'approbation (et extrayez le jeton des paramètres de requête de l'url). Et je pense que vous pouvez faire cela sur toutes les plateformes. J'ai réussi à le faire fonctionner pour les plateformes suivantes : ios, Android, mac, Windows store 8.1 apps, Windows phone 8.1 apps. Je l'ai fait pour les services suivants : dropbox, google drive, onedrive, box, basecamp. Pour les plateformes non-Windows, j'ai utilisé Xamarin qui n'expose pas toutes les APIs spécifiques à la plateforme, mais qui en expose suffisamment pour rendre cela possible. C'est donc une solution assez accessible, même d'un point de vue multiplateforme, et vous n'avez pas à vous soucier de l'interface utilisateur du formulaire d'authentification.