Quel est le bon flux OAuth 2.0 pour une application mobile

J'essaie d'implémenter l'autorisation déléguée dans une API Web pour les applications mobiles 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 de temps spécifique, l'utilisateur doit à nouveau accorder des autorisations à l'application une fois que le jeton expire ou qu'il est révoqué.

Je suppose que c'est un bon scénario pour un code javascript fonctionnant sur un navigateur, comme mentionné dans la spécification. J'essaie de minimiser les temps pendant lesquels 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 d'actualisation.

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 devrais-je suivre le flux implicite?

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 claire (et en fait, implicite n'est pas recommandée pour les raisons exposées ci-dessous).

Bonnes pratiques OAuth2 pour les applications natives

Quelle que soit l'approche que vous choisissez (il y a quelques compromis à considérer), vous devez faire attention aux meilleures pratiques décrites ici pour les applications natives utilisant OAuth2: https://tools.ietf.org/html/rfc8252

Considérez les options suivantes

Implicite

Dois-je utiliser implicite?

Pour citer la section 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

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

Les jetons d'accès accordés via le flux implicite ne peuvent pas non plus être actualisés sans interaction de l'utilisateur, ce qui fait du flux d'octroi de code d'autorisation - qui peut émettre des jetons d'actualisation - 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 le proxy via votre propre composant de serveur Web qui enrichit les demandes de jetons avec le secret client pour éviter de le stocker sur 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 disposent d'un service Web. Ce flux nécessite une communication de serveur à serveur à l'aide du secret client d'une application.

Remarque: ne placez jamais votre secret client dans un code distribué, tel que des applications téléchargées via un magasin d'applications ou JavaScript côté client.

Les applications qui n'ont pas de service Web doivent utiliser le flux d'octroi implicite.

Conclusion

La décision finale doit prendre en compte l'expérience utilisateur souhaitée, mais aussi votre appétit pour le risque après avoir effectué une évaluation des risques appropriée de vos approches présélectionnées et une meilleure compréhension des 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 indique

La meilleure pratique actuelle du secteur consiste à utiliser le flux d'autorisation tout en omettant le secret client et à utiliser un agent utilisateur externe pour terminer le flux. Un agent utilisateur externe est généralement le 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 dans le navigateur.

Considération 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, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ indique que vous devez

• Autorisez les clients à enregistrer des schémas d'URL personnalisés pour leurs URL de redirection.
• Prend en charge les URL de redirection IP de bouclage avec des numéros de port arbitraires afin de prendre en charge les applications de bureau.
• Ne supposez pas que les applications natives peuvent garder un secret. Exiger de toutes les applications qu'elles déclarent si elles sont publiques ou confidentielles et ne délivrer des secrets clients qu'aux applications confidentielles.
• Prend en charge l'extension PKCE et exige que les clients publics l'utilisent.
• Essayez de détecter le moment où l'interface d'autorisation est intégrée dans la vue Web d'une application native, au lieu d'être lancée dans un navigateur système, et rejetez ces demandes.

Prise en compte des vues Web

Il existe de nombreux exemples dans la nature utilisant des vues Web, c'est-à-dire un agent utilisateur intégré, mais cette approche doit être évitée (en particulier lorsque l'application n'est pas la première partie) et dans certains cas, elle peut vous interdire d'utiliser une API comme extrait ci-dessous à partir d' ici montre

Toute tentative d'intégration de la page d'authentification OAuth 2.0 entraînera l'interdiction de votre application de l'API Fitbit.

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

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 comme URI de redirection pour rediriger l'utilisateur du navigateur vers l'application qui demande l'autorisation.

Les applications iOS peuvent utiliser la classe SFSafariViewController au lieu de basculer 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 basculer vers le navigateur par défaut. L'utilisation de WebView est interdite.

Pour clarifier davantage, voici une citation de cette section d'un projet précédent du lien des 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 des applications natives. Ils sont cependant dangereux pour une utilisation par des tiers par définition. Ils impliquent que l'utilisateur se connecte avec ses informations de connexion complètes, uniquement pour les faire passer à des informations d'identification OAuth moins puissantes.

Même lorsqu'ils sont utilisés par des applications propriétaires de confiance, les agents utilisateurs intégrés violent le principe du moindre privilège en obtenant des informations d'identification plus puissantes que ce dont ils ont besoin, augmentant potentiellement la surface d'attaque.

Dans les implémentations typiques basées sur la vue Web des agents utilisateurs intégrés, l'application hôte peut: enregistrer chaque frappe saisie dans le formulaire pour capturer les noms d'utilisateur et les mots de passe; soumettre automatiquement des formulaires et contourner le consentement de l'utilisateur; copiez les cookies de session et utilisez-les pour effectuer des actions authentifiées en tant qu'utilisateur.

En encourageant les utilisateurs à entrer leurs informations d'identification dans une vue Web intégrée sans la barre d'adresse habituelle et les autres fonctionnalités d'identité des navigateurs, il est impossible pour l'utilisateur de savoir s'il se connecte au site légitime, et même lorsqu'ils le sont, cela les forme qu'il est OK pour entrer les informations d'identification sans valider le site au préalable.

Outre les problèmes de sécurité, les vues Web ne partagent pas l'état d'authentification avec d'autres applications ou le navigateur système, ce qui oblige l'utilisateur à se connecter pour chaque demande d'autorisation et entraîne une mauvaise expérience utilisateur.

En raison de ce qui précède, l'utilisation d'agents utilisateurs intégrés n'est PAS RECOMMANDÉE, sauf lorsqu'une application propriétaire de confiance agit en tant qu'agent utilisateur externe pour d'autres applications ou fournit une authentification unique pour plusieurs applications propriétaires.

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

Quelques points intéressants sont également soulevés ici: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- une

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

• Si vous pouvez demander à l'utilisateur ses informations d'identification, utilisez les informations d'identification du mot de passe du propriétaire de la ressource . Cependant, cela peut ne pas être possible pour certaines raisons, à savoir

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

• Si l'utilisation d'un flux basé sur un navigateur est requise, utilisez le flux de code d'autorisation . Ici, la définition du redirect_uriest un enjeu majeur, pour lequel il existe les options suivantes:

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

J'espère que cela t'aides

Pedro

TL; DR: Utiliser l'octroi de code d'autorisation avec PKCE

1. Type de subvention implicite

Le type de subvention implicite est très populaire avec les applications mobiles. Mais il n'était pas destiné à être utilisé comme ça. Il y a des problèmes de sécurité autour de la redirection. Justin Richer déclare :

Le problème survient lorsque vous réalisez que contrairement à une URL de serveur distant, il n'existe aucun moyen fiable de garantir que la liaison entre un URI de redirection donné et une application mobile spécifique est respectée. Toute application sur l'appareil peut essayer de s'insérer dans le processus de redirection et de lui faire servir l'URI de redirection. Et devinez quoi: si vous avez utilisé le flux implicite dans votre application native, vous venez de remettre à l'attaquant votre jeton d'accès. Il n'y a pas de récupération à partir de ce moment-là - ils ont le jeton et ils peuvent l'utiliser.

Et avec le fait qu'il ne vous permet pas d'actualiser le jeton d'accès, mieux vaut l'éviter.

2. Type d'autorisation de code d'autorisation

L'octroi du code d'autorisation nécessite un secret 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 client, vous devez exécuter un serveur en tant qu'intermédiaire pendant que Facebook écrit :

Nous recommandons que les jetons d'accès aux applications ne soient utilisés que directement à partir des serveurs de votre application afin de fournir la meilleure sécurité. Pour les applications natives, nous suggérons que l'application communique avec votre propre serveur et que le serveur envoie ensuite les requêtes API à Facebook à l'aide du jeton d'accès aux applications.

Ce n'est pas une solution idéale, mais il y a une nouvelle, une meilleure façon de faire OAuth sur les appareils mobiles: Clé de preuve pour l'échange de code

3. Type d'octroi de code d'autorisation avec PKCE (clé de preuve pour l'échange de code)

En dehors des limitations, une nouvelle technique a été créée qui vous permet d'utiliser le code d'autorisation sans secret client. Vous pouvez lire la RFC 7636 complète ou cette courte introduction .

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

Il est principalement utilisé par les applications natives et mobiles, mais la technique peut également être appliquée à n'importe quel client public. Il nécessite une prise en charge supplémentaire de la part du serveur d'autorisation, il n'est donc pris en charge que sur certains fournisseurs.

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

L'utilisation d'une vue Web dans votre application mobile devrait être un moyen abordable d'implémenter le protocole OAuth2.0 sur la plate-forme Android.

En ce qui concerne le champ redirect_uri, je pense que http://localhostc'est un bon choix et que vous n'avez pas à porter un serveur HTTP dans votre application, car vous pouvez remplacer l'implémentation de la onPageStartedfonction dans la WebViewClientclasse et arrêter le chargement de la page Web http://localhostaprès avoir vérifié le urlparamètre.

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

L'expérience utilisateur la plus fluide pour l'authentification et la plus simple à mettre en œuvre consiste à intégrer une vue Web dans votre application. Traitez les réponses reçues par la vue Web à partir du point d'authentification et détectez l'erreur (annulation de l'utilisateur) ou l'approbation (et extrayez le jeton des paramètres de requête d'URL). Et je pense que vous pouvez le faire sur toutes les plateformes. J'ai réussi à faire ce travail pour les éléments suivants: iOS, Android, Mac, applications Windows Store 8.1, application Windows Phone 8.1. Je l'ai fait pour les services suivants: dropbox, google drive, onedrive, box, basecamp. Pour les plates-formes non Windows, j'utilisais Xamarin, qui n'exposait pas toutes les API spécifiques à la plate-forme, mais il en a exposé suffisamment pour rendre cela possible. C'est donc une solution assez accessible, même d'un point de vue multiplateforme, et vous ne le faites pas.