Quel est le bon flux OAuth 2.0 pour une application mobile

Question 1

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?

Question 2

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

Question 3

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

Question 4

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/

Question 5

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) {}

Question 6

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.

Answer 1

87

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?

security mobile oauth-2.0 Pablo Cibraro
la source

1

La question serait la suivante: est-ce comme la priorité la plus élevée que l'utilisateur n'ait plus jamais à taper un mot de passe après la première connexion?

lessprivilege

Oui, c'est exactement mon exigence. L'utilisateur ne doit taper le mot de passe qu'une seule fois. Cependant, je ne veux pas configurer un jeton avec une durée de vie infinie et le conserver dans l'application mobile, car cela irait à l'encontre de la capacité de révoquer le jeton. (Sauf si j'ajoute une logique dans l'application mobile pour détecter que la demande n'était pas autorisée, je demande donc un nouveau jeton après cela)

Pablo Cibraro

1

Vous pouvez ajouter un jeton avec une durée de vie infinie et toujours le révoquer. Et oui, la logique de l'application devrait être capable de détecter cela. La RFC 6750 définit un moyen de vérifier si l'erreur est due à un jeton révoqué.

Pedro Felix

1

Veuillez éviter les vues Web (sauf si vous possédez la pile complète et n'utilisez pas de connexion sociale) qui ouvrent la possibilité de compromettre les mots de passe. Lorsque des informations d'identification me sont demandées par un agent utilisateur tiers intégré, je désinstallerais l'application. Certaines API interdisent même maintenant de telles intégrations telles que celle-ci dev.fitbit.com/docs/oauth2 J'ai fourni une autre réponse pour clarifier davantage certains de ces concepts ( stackoverflow.com/a/38582630/752167 )

Matt C

Answer 2

1

La question serait la suivante: est-ce comme la priorité la plus élevée que l'utilisateur n'ait plus jamais à taper un mot de passe après la première connexion?

lessprivilege

Answer 3

Oui, c'est exactement mon exigence. L'utilisateur ne doit taper le mot de passe qu'une seule fois. Cependant, je ne veux pas configurer un jeton avec une durée de vie infinie et le conserver dans l'application mobile, car cela irait à l'encontre de la capacité de révoquer le jeton. (Sauf si j'ajoute une logique dans l'application mobile pour détecter que la demande n'était pas autorisée, je demande donc un nouveau jeton après cela)

Pablo Cibraro

Answer 4

1

Vous pouvez ajouter un jeton avec une durée de vie infinie et toujours le révoquer. Et oui, la logique de l'application devrait être capable de détecter cela. La RFC 6750 définit un moyen de vérifier si l'erreur est due à un jeton révoqué.

Pedro Felix

Answer 5

1

Veuillez éviter les vues Web (sauf si vous possédez la pile complète et n'utilisez pas de connexion sociale) qui ouvrent la possibilité de compromettre les mots de passe. Lorsque des informations d'identification me sont demandées par un agent utilisateur tiers intégré, je désinstallerais l'application. Certaines API interdisent même maintenant de telles intégrations telles que celle-ci dev.fitbit.com/docs/oauth2 J'ai fourni une autre réponse pour clarifier davantage certains de ces concepts ( stackoverflow.com/a/38582630/752167 )

Matt C

Answer 6

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

Answer 7

3

Google supprimera la prise en charge des visionnages Web le 20 avril 2017 developer.googleblog.com/2016/08/…

Matt C

Answer 8

Pour info, le document fait référence au début de cette réponse si ce n'est plus le brouillon OAuth 2.0 pour les applications natives - tools.ietf.org/html/rfc8252

Kostiantyn Sokolinskyi

Answer 9

Merci @KostiantynSokolinskyi, modifié en conséquence avec un lien pour rfc qui n'est plus brouillon

Matt C

Answer 10

@MattC Quelle est la meilleure façon d'implémenter l'enregistrement d'un nouvel utilisateur? Devrions-nous le faire dans l'application ou sur l'IDP? Est-il possible de se connecter automatiquement au registre de publication de l'utilisateur? stackoverflow.com/questions/60187173/…

Yashvit

Answer 11

Désolé, je suis confus au sujet de certains détails ... Pouvez-vous jeter un œil? Merci! lien ---> stackoverflow.com/q/61313694/4619958

ch271828n

Answer 12

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

Answer 13

Merci Pedro pour la contribution !. Oui, il semble que le flux de code d'autorisation avec le schéma d'URI personnalisé ou la vue Web semble être la meilleure option ici.

Pablo Cibraro

Answer 14

1

Tout dépend si vous souhaitez que le client saisisse le mot de passe dans une vue Web ou dans l'application cliente. Si possible, je préférerais l'application cliente - puis échangez immédiatement le secret avec un jeton d'accès / d'actualisation.

lessprivilege

Answer 15

Merci Dominick !. Mon client utilise ADFS pour authentifier les utilisateurs, il souhaite donc saisir les informations d'identification dans la page de connexion. La vue Web fonctionnera pour eux

Pablo Cibraro

Answer 16

5

Je suis curieux de savoir pourquoi vous recommanderiez le "flux de code d'autorisation"? N'auriez-vous pas besoin de client_secret et client_id pour échanger le code contre un access_token? Je pensais que le flux "implicite" a été conçu pour ces scénarios, car il ne nécessite pas de stockage de secrets dans l'appareil.

Eugenio Pace

Answer 17

1

implicite ne prend pas en charge les jetons d'actualisation OOB. Dans le scénario de Pablo - je recommanderais clairement le flux RO. On dirait que l'entreprise a déployé des applications contre le même backend d'entreprise.

leastprivilege

Answer 18

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/

Answer 19

-3

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) {}

Zéphyr
la source

3

Bonnes pratiques pour les applications natives utilisant OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps

Matt C

1

Comme l'a dit Matt C, ci-dessus. Les vues Web sont une mauvaise idée pour les applications mobiles - elles ne sont pas sécurisées, permettent à l'application d'accéder aux informations d'identification (donc pas plus sécurisées que RO) et ne permettent pas aux utilisateurs de vérifier le domaine et les certificats TLS. Utilisez le type d'accord Auth Code avec un gestionnaire d'URI personnalisé et assurez-vous d'utiliser Proof Code for Key Exchange (PKCE) pour empêcher les applications malveillantes sur votre téléphone d'intercepter le code d'authentification et d'accéder à votre API.

ChrisC

2

La version mise à jour de l'ébauche du document sur les meilleures pratiques d'OAuth 2.0 pour les applications natives se trouve à l' adresse tools.ietf.org/html/draft-ietf-oauth-native-apps

Jeff Olson

Answer 20

3

Bonnes pratiques pour les applications natives utilisant OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps

Matt C

Answer 21

1

Comme l'a dit Matt C, ci-dessus. Les vues Web sont une mauvaise idée pour les applications mobiles - elles ne sont pas sécurisées, permettent à l'application d'accéder aux informations d'identification (donc pas plus sécurisées que RO) et ne permettent pas aux utilisateurs de vérifier le domaine et les certificats TLS. Utilisez le type d'accord Auth Code avec un gestionnaire d'URI personnalisé et assurez-vous d'utiliser Proof Code for Key Exchange (PKCE) pour empêcher les applications malveillantes sur votre téléphone d'intercepter le code d'authentification et d'accéder à votre API.

ChrisC

Answer 22

2

La version mise à jour de l'ébauche du document sur les meilleures pratiques d'OAuth 2.0 pour les applications natives se trouve à l' adresse tools.ietf.org/html/draft-ietf-oauth-native-apps

Jeff Olson

Answer 23

-4

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.

Radu Simionescu
la source

Tout en offrant une expérience utilisateur pratique, nous verrons l'industrie s'éloigner de cette approche. Comme les vues Web ouvrent la possibilité de compromettre les mots de passe, lorsque des informations d'identification me sont demandées par un agent utilisateur intégré, je désinstallerais l'application. Certaines API interdisent même maintenant de telles intégrations telles que celle-ci dev.fitbit.com/docs/oauth2

Matt C

Bonnes pratiques pour les applications natives utilisant OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps

Matt C

Je ne vois pas comment un service activé par oauth pourrait interdire cette approche. C'est indétectable et sûr ... Certains services activés par oauth fournissent des clients spécifiques à la plate-forme pour faciliter l'authentification, et ces clients font réellement ce que j'ai décrit ici (afficher une vue Web intégrée et suivre les changements d'URL). La meilleure pratique que vous avez liée recommande la même chose: utilisez le navigateur système ou la vue Web intégrée. Quel argument attaquez-vous de ma réponse? c'est flou.

Radu Simionescu

Aucune attaque n'est prévue, soulignant simplement le problème. Le lien indique qu'il existe les 2 approches que vous mentionnez, mais seul un agent utilisateur externe peut être considéré comme sécurisé, en particulier il indique que les options pour les applications natives sont "via un agent utilisateur intégré ou un agent utilisateur externe. Ce document recommande des applications externes. les agents utilisateurs comme les onglets de navigateur intégrés à l'application sont le seul choix sécurisé et utilisable pour OAuth. "

Matt C

Citation supplémentaire "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" ....... "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 connexion 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. "

Matt C du

Answer 24

Tout en offrant une expérience utilisateur pratique, nous verrons l'industrie s'éloigner de cette approche. Comme les vues Web ouvrent la possibilité de compromettre les mots de passe, lorsque des informations d'identification me sont demandées par un agent utilisateur intégré, je désinstallerais l'application. Certaines API interdisent même maintenant de telles intégrations telles que celle-ci dev.fitbit.com/docs/oauth2

Matt C

Answer 25

Bonnes pratiques pour les applications natives utilisant OAuth2: tools.ietf.org/html/draft-wdenniss-oauth-native-apps

Matt C

Answer 26

Je ne vois pas comment un service activé par oauth pourrait interdire cette approche. C'est indétectable et sûr ... Certains services activés par oauth fournissent des clients spécifiques à la plate-forme pour faciliter l'authentification, et ces clients font réellement ce que j'ai décrit ici (afficher une vue Web intégrée et suivre les changements d'URL). La meilleure pratique que vous avez liée recommande la même chose: utilisez le navigateur système ou la vue Web intégrée. Quel argument attaquez-vous de ma réponse? c'est flou.

Radu Simionescu

Answer 27

Aucune attaque n'est prévue, soulignant simplement le problème. Le lien indique qu'il existe les 2 approches que vous mentionnez, mais seul un agent utilisateur externe peut être considéré comme sécurisé, en particulier il indique que les options pour les applications natives sont "via un agent utilisateur intégré ou un agent utilisateur externe. Ce document recommande des applications externes. les agents utilisateurs comme les onglets de navigateur intégrés à l'application sont le seul choix sécurisé et utilisable pour OAuth. "

Matt C

Answer 28

Citation supplémentaire "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" ....... "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 connexion 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. "

Matt C du

Quel est le bon flux OAuth 2.0 pour une application mobile

Réponses: