Quel est le droit OAuth 2.0 flux pour une application mobile
J'essaie d'implémenter l'autorisation déléguée dans une API Web pour applications mobiles en utilisant OAuth 2.0. Selon la spécification, 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 à nouveau accorder des autorisations à l'application une fois le jeton arrivé à expiration ou sa révocation. Je suppose que c'est un bon scénario pour du code javascript s'exécutant sur un navigateur tel qu'il est mentionné dans les spécifications. afin de minimiser le nombre de fois où l'utilisateur doit accorder des autorisations à l'application pour obtenir un jeton, le flux de codes d'autorisation apparaît alors comme une bonne option, car il prend en charge les jetons d'actualisation. Ce flux semble toutefois fortement dépendre d'un navigateur Web. 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 utiliser le flux implicite?
Précision: application mobile = application native
Comme indiqué dans d'autres commentaires et quelques sources en ligne, implicite semble être un choix naturel pour les applications mobiles, mais la meilleure solution n'est pas toujours évidente (et en fait, implicite n'est pas recommandé pour les raisons exposées ci-dessous).
Meilleures pratiques pour l'application native OAuth2
Quelle que soit l'approche choisie (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://tools.ietf.org/html/rfc8252
Considérez les options suivantes
implicite
Devrais-je utiliser implicite?
Pour citer la section 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
Le flux d’autorisations d’attribution implicite OAuth 2.0) (défini dans la section 4.2 de OAuth 2.0 [RFC6749]) fonctionne normalement avec 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] (obligatoire 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 rend le 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 nécessitant un rafraîchissement des jetons d'accès.
Code d'autorisation
Si vous utilisez le code d'autorisation, une approche consiste à utiliser un proxy via votre propre composant de serveur Web, ce qui enrichit les demandes de jetons avec le secret du client pour éviter de le stocker sur l'application distribuée sur les périphériques.
Extrait ci-dessous de: https://dev.fitbit.com/docs/oauth2/
Le flux d'octroi de codes d'autorisation est recommandé pour les applications disposant d'un service Web. Ce flux nécessite une communication entre serveurs utilisant le secret client d'une application.
Remarque: ne mettez jamais le secret de votre client dans du code distribué, tel que des applications téléchargées via un magasin d'applications ou du code JavaScript côté client.
Les applications qui ne disposent pas d'un 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 également votre appétit pour le risque, après une évaluation appropriée des risques de vos approches présélectionnées et une meilleure compréhension de 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 indique
La meilleure pratique actuelle du secteur consiste à utiliser le flux d'autorisation en omettant le secret client et à utiliser un agent d'utilisateur externe pour compléter le flux. Un agent utilisateur externe est généralement le navigateur natif du périphérique (avec un domaine de sécurité distinct de l’application native), de sorte que l’application ne puisse pas accéder au stockage des cookies ni 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'autorisations, alors https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ indique que vous devriez
- Autoriser les clients à enregistrer des modèles d'URL personnalisés pour leurs URL de redirection.
- Prise en charge des URL de redirection IP en boucle 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. Exigez que toutes les applications déclarent si elles sont publiques ou confidentielles et ne communiquez des secrets de client qu'à des 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 incorporée dans la vue Web d'une application native, au lieu d'être lancée dans un navigateur système, et rejetez ces demandes.
Considérations relatives aux vues Web
Il existe de nombreux exemples dans la nature utilisant des vues Web, par exemple un agent utilisateur incorporé, mais cette approche doit être évitée (en particulier lorsque l'application n'est pas la première partie) et, dans certains cas, il peut vous être interdit d'utiliser une API comme extrait. en dessous de ici démontre
Toute tentative d'intégration de la page d'authentification OAuth 2.0) entraînera l'interdiction de votre application à partir de l'API Fitbit.
Pour des raisons de sécurité, la page d’autorisation OAuth 2.0 doit être présentée dans un navigateur dédié. Les utilisateurs de Fitbit ne peuvent confirmer qu’ils s’authentifient auprès du site authentique Fitbit.com s’ils disposent des outils fournis par le logiciel. navigateur, tel que la barre d’URL et les informations de 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 modèles d'URL personnalisés en tant qu'URI de redirection pour rediriger l'utilisateur du navigateur vers l'application demandant l'autorisation.
les applications iOS peuvent utiliser la classe SFSafariViewController au lieu de basculer d'application vers Safari. L'utilisation de la classe WKWebView ou UIWebView est interdite.
Les applications Android peuvent utiliser Chrome Onglets personnalisés au lieu de basculer d'application vers le navigateur par défaut. L'utilisation de WebView est interdite.
Pour clarifier davantage, voici une citation de cette section d'un précédent projet de lien vers la meilleure pratique fournie ci-dessus.
Les agents d'utilisateur intégrés, généralement implémentés avec des vues Web, constituent une méthode alternative pour autoriser les applications natives. Ils sont cependant dangereux pour une utilisation par des tiers par définition. Ils impliquent l’utilisateur qui se connecte avec ses identifiants de connexion complets, mais les redescend à des identifiants moins puissants OAuth.
Même lorsqu'ils sont utilisés par des applications de premier plan de confiance, les agents d'utilisateur intégrés enfreignent le principe du moindre privilège en obtenant des informations d'identification plus puissantes que nécessaire, augmentant ainsi potentiellement la surface d'attaque.
Dans les implémentations typiques d'agents d'utilisateur intégrés basées sur la vue Web, l'application hôte peut: consigner chaque frappe saisie dans le formulaire pour capturer les noms d'utilisateur et les mots de passe; soumettre automatiquement les formulaires et contourner le consentement de l'utilisateur; copier les cookies de session et les utiliser pour effectuer des actions authentifiées en tant qu’utilisateur.
Encourager les utilisateurs à entrer leurs informations d'identification dans une vue Web intégrée sans la barre d'adresse habituelle et les autres fonctions d'identité des navigateurs empêche l'utilisateur de savoir s'il se connecte au site légitime, et même lorsqu'il le fait, il les entraîne que vous pouvez saisir les informations d’identification sans valider d’abord le site.
Outre les problèmes de sécurité, les vues Web ne partagent pas l'état d'authentification avec d'autres applications ni avec le navigateur du système, ce qui oblige l'utilisateur à se connecter pour chaque demande d'autorisation et à une expérience utilisateur médiocre.
En raison de ce qui précède, l'utilisation d'agents d'utilisateur incorporés n'est PAS RECOMMANDÉE, sauf lorsqu'une application première approuvée fait office d'agent d'utilisateur externe pour d'autres applications ou fournit une connexion unique pour plusieurs applications différentes.
Les serveurs d'autorisation DEVRAIENT envisager de prendre des mesures pour détecter et bloquer les connexions via des agents d'utilisateur intégrés qui ne sont pas les leurs, dans la mesure du possible.
Quelques 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 -quel-sont-les-a
Malheureusement, je ne pense pas qu'il y ait une réponse claire à cette question. Cependant, voici les options que j'ai identifiées:
S'il est correct de demander à l'utilisateur ses informations d'identification, utilisez le Informations d'identification du mot de passe du propriétaire de la ressource . Cependant, cela peut ne pas être possible pour certaines raisons, notamment
- Les politiques de convivialité ou de sécurité interdisent l’insertion du mot de passe directement dans 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 une 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 de la
redirect_uriest un défi majeur pour lequel les options suivantes sont disponibles:- Utilisez la technique décrite dans https://developers.google.com/accounts/docs/OAuth2InstalledApp , où un
redirect_uri(par exemple.urn:ietf:wg:oauth:2.0:oob) signale au noeud final d'autorisation d'afficher le code d'autorisation au lieu d'être redirigé 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 serveur
localhostsur le périphérique (la gestion des ports peut ne pas être simple). - Utilisez un schéma d'URI personnalisé (par exemple,
myapp://...) que, lors de la suppression du référencement, déclenche un "gestionnaire" enregistré (les détails dépendent de la plate-forme mobile). - Si disponible, utilisez un "affichage Web" spécial, tel que le WebAuthenticationBroker sous Windows 8, pour contrôler et accéder aux réponses de redirection HTTP.
- Utilisez la technique décrite dans https://developers.google.com/accounts/docs/OAuth2InstalledApp , où un
J'espère que cela t'aides
Pedro
TL; DR: Utiliser l'attribution 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 ce n'était pas censé être utilisé comme ça. Il y a des problèmes de sécurité autour de la redirection. Etats Justin Richer :
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 une adresse URI de redirection donnée et une application mobile spécifique est respectée. Toute application de l'appareil peut tenter de s'inscrire dans le processus de redirection et lui faire prendre en charge l'URI de redirection. Et devinez quoi: si vous avez utilisé le flux implicite dans votre application native, vous venez de donner à l'attaquant votre jeton d'accès. Il n’ya pas de récupération à partir de ce moment-là: ils ont le jeton et ils peuvent l’utiliser.
Et avec le fait que cela ne vous permet pas d'actualiser le jeton d'accès, mieux vaut l'éviter.
2. Type d'attribution de code d'autorisation
L'attribution de 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 du client, vous devez exécuter un serveur en tant qu'intermédiaire en tant que Facebook écrit :
Nous recommandons que les jetons d'accès aux applications ne soient utilisés 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, lequel envoie ensuite les demandes d'API à Facebook à l'aide du jeton d'accès.
Solution non idéale, mais il existe une nouvelle méthode plus efficace OAuth sur les appareils mobiles: Clé de preuve pour l'échange de code
3. Type d'attribution de code d'autorisation avec PKCE (clé de vérification pour l'échange de code)
En dehors des limitations, une nouvelle technique a été créée pour vous permettre d'utiliser le code d'autorisation sans secret client. Vous pouvez lire le complet RFC 7636 ou cette courte introduction .
PKCE (RFC 7636) est une technique permettant de sécuriser des 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 à tout client public. Il nécessite une assistance supplémentaire de la part du serveur d'autorisation. Il n'est donc pris en charge que par certains fournisseurs.