android - type - oauth2 implicit flow




Authentification avec OAuth2 pour une application*et*un site web (4)

Je développe un site Web qui est principalement accessible via une application, et je veux utiliser OAuth2 pour l'enregistrement et l'authentification des utilisateurs. Comme c'est une application Android, je vais commencer à utiliser OAuth2 de Google, car il fournit une interface utilisateur décente sur Android.

Google déclare que «vous pouvez choisir d'utiliser le système d'authentification de Google comme un moyen d'externaliser l'authentification des utilisateurs pour votre application, ce qui peut vous éviter de devoir créer, maintenir et sécuriser un nom d'utilisateur et un mot de passe. c'est ce que je veux faire. Cependant, quand je passe en revue tous leurs exemples et autres, je ne peux trouver des choses à propos d'avoir un site Web ou une application authentifier un utilisateur contre les services de Google.

Et en effet, quand je vais enregistrer mon application ("client") avec OAuth2 de Google, il y a des options pour les clients du site et les clients "installés" (c'est-à-dire une application mobile) mais pas les deux. Je peux créer deux clients distincts mais j'ai lu le brouillon OAuth2 et je pense qu'il y aura un problème, que je vais maintenant expliquer.

Voici comment je l'ai envisagé de travailler:

  1. L'utilisateur demande à MyApp d'accéder à ses données privées.
  2. App utilise la classe AccountManager d'Android pour demander un jeton d'accès aux API de Google.
  3. Android dit à l'utilisateur "L'application 'MyApp' veut avoir accès à vos informations de base sur Google.
  4. L'utilisateur dit oui.
  5. AccountManager connecte au serveur OAuth2 de Google à l'aide des informations d'identification stockées sur le téléphone et demande un jeton d'accès.
  6. Le jeton d'accès (qui suit les lignes vertes) est renvoyé.
  7. AccountManager renvoie le jeton d'accès à MyApp.
  8. MyApp envoie une requête à MySite pour les données privées de l'utilisateur, y compris le jeton d'accès.
  9. MySite doit vérifier l'utilisateur, en utilisant le jeton d'accès. Il valide le jeton comme décrit ici , avec Google - "Google, ce jeton est-il valide?".
  10. Maintenant, ce que je veux faire, c'est que Google dise "Oui, celui qui vous l'a donné est bien cet utilisateur", mais ce qui va se passer (d'après le projet OAuth2 et la documentation de Google), c'est qu'il dira "Non Ce jeton n'est valable que pour MyApp, et vous êtes MySite.

Alors, comment dois-je faire cela? Et SVP ne dites pas "Utiliser OpenID" ou "Ne pas utiliser OAuth2" ou d'autres réponses non utiles. Oh et je voudrais vraiment continuer à utiliser la gentille interface utilisateur de AccountManager plutôt que la foutue popup WebView s

modifier

La réponse provisoire (je vais rapporter si ça marche!) De Nikolay est que cela devrait fonctionner, et les serveurs de Google ne se soucieront pas d'où vient le jeton d'accès. Ça me semble un peu incertain, mais je verrai si ça marche!

Mettre à jour

J'ai mis en place ce modèle avec Facebook au lieu de Google et cela fonctionne totalement. Le serveur OAuth2 ne se soucie pas d'où vient le jeton d'accès. Au moins, Facebook ne fonctionne pas, donc je suppose que Google n'est pas non plus.

À la lumière de cela, c'est une très très mauvaise idée de stocker des jetons d'accès! Mais nous ne voulons pas non plus devoir cliquer sur les serveurs de Facebook / Google pour vérifier l'authentification de chaque requête, car cela ralentira tout. Probablement la meilleure chose est d'ajouter un cookie d'authentification supplémentaire pour votre site que vous distribuez quand leur jeton d'accès est validé, mais un moyen plus simple est juste de traiter le jeton d'accès comme un mot de passe et de stocker un hachage. Vous n'avez pas besoin de le saler car les jetons d'accès sont vraiment très longs. Donc, les étapes ci-dessus deviennent quelque chose comme:

9. MySite doit vérifier l'utilisateur, en utilisant le jeton d'accès. D'abord, il vérifie son cache de jetons d'accès valides hachés. Si le hachage du jeton y est trouvé, il sait que l'utilisateur est authentifié. Sinon, il vérifie avec Google comme décrit ici , avec Google - "Google, ce jeton est-il valide?".

10. Si Google dit que le jeton d'accès est invalide, nous le disons au GTFO. Sinon, Google indique "Oui, c'est un utilisateur valide" et nous vérifions ensuite notre base de données d'utilisateurs enregistrés. Si ce nom d'utilisateur Google (ou Facebook si vous utilisez Facebook) n'est pas trouvé, nous pouvons créer un nouvel utilisateur. Ensuite, nous mettons en cache la valeur hachée du jeton d'accès.


Lorsque nous devions faire quelque chose de similaire sur un serveur OAuth non-google, nous conservions les jetons dans une base de données sur le site Web. L'application utilise ensuite les services Web pour demander le jeton lorsque cela est nécessaire pour demander des données.

L'utilisateur peut effectuer l'enregistrement OAuth sur le Web ou l'application. Ils partageaient le même jeton d'application, afin qu'ils puissent partager le même jeton d'accès. Après l'enregistrement, nous stockons les jetons d'accès et d'actualisation dans la base de données pour les utiliser depuis n'importe quelle application.




Au moins avec Google, le jeton d'accès finit par expirer. C'est pourquoi android AccountManager a la méthode invalidateAuthToken - le jeton d'accès mis en cache a expiré, et vous devez indiquer au AccountManager d'arrêter de vous donner l'ancien et d'en obtenir un nouveau. Cela rend un peu plus sûr de mettre en cache le jeton, car le jeton lui-même ne vous donne pas un accès éternel en tant qu'utilisateur. Au lieu de cela, lorsqu'il est valide, il dit simplement "à un moment donné dans le passé récent, ce jeton a été acquis par une source de confiance."

Voici quelques choses que j'ai trouvées utiles lorsque je travaille avec des jetons. Le premier est le point de terminaison tokeninfo de Google. Le jeton lui-même est juste JSON codé en base64. Cela signifie qu'il n'est pas crypté, vous devez donc être sûr d'utiliser HTTPS pour la communication. Cependant, cela signifie également que vous pouvez examiner le jeton et avoir une meilleure idée de ce qui se passe.

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=

Si votre jeton était "abcdef", vous devez naviguer vers:

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=abcdef

et Google décompresserait le jeton pour vous. C'est un simple objet JSON qui inclut un champ "expires_in" vous indiquant le nombre de secondes pour lesquelles le token est toujours valide. A 6:03 dans la vidéo ci-dessous vous pouvez voir le jeton déballé:

https://developers.google.com/events/io/sessions/383266187

Cette vidéo comprend un aperçu complet de OAuth2 et vaut la peine d'être regardée dans son intégralité si vous devez utiliser OAuth et les jetons. Le locuteur parle également d'autres formes de jetons Oauth2, qui ne sont pas des jetons d'accès, qui n'expirent pas.

Une autre ressource utile est le terrain de jeu OAuth. Cela vous permet de faire des choses élémentaires comme des portées de requête, de créer des requêtes et de récupérer des jetons. Ce lien semble fonctionner de manière sporadique, et sur Chrome, j'ai dû installer l'application Oauth Playground:

https://developers.google.com/oauthplayground/

Et voici un tutoriel de Tim Bray, le conférencier de la vidéo, expliquant comment utiliser les jetons d'accès pour communiquer avec un serveur à partir d'une application Android. Cela m'a été utile parce que j'ai commencé à comprendre comment les différents éléments de la console API de Google fonctionnent ensemble:

http://android-developers.blogspot.in/2013/01/verifying-back-end-calls-from-android.html

En ce qui concerne la réponse à votre question, je dirais que vous n'avez jamais besoin de mettre en cache le jeton d'accès sur le serveur. Comme expliqué dans le lien Vérification des appels back end d'Android ci-dessus, la vérification d'un jeton est presque toujours un appel statique rapide, ce qui signifie qu'il n'y a aucune raison de mettre en cache les jetons:

Les bibliothèques peuvent mettre en cache les certificats Google et ne les actualiser que lorsque cela est nécessaire. La vérification est (presque toujours) un appel statique rapide.

Enfin, vous pouvez utiliser le AccountManager pour obtenir des jetons d'accès. Cependant, Google encourage désormais l'utilisation de la classe GoogleAuthUtil dans la bibliothèque Play Services à la place:

En bref, quelle est la différence d'utiliser OAuth2 request getAuthToken et getToken

Ici, notez le commentaire de Tim Bray, le même gars encore une fois à partir des liens ci-dessus, en disant qu'ils mettent leurs efforts dans la route GoogleAuthUtil . Notez cependant que cela signifie que vous serez limité à l'authentification Google. Je crois que le AccountManager pourrait être utilisé pour obtenir, par exemple, un jeton Facebook à la place - pas le cas avec GoogleAuthUtil .







google-authentication