Authentification avec OAuth2 pour une application *et* un site web
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 il s'agit d'une application Android, je vais commencer à utiliser le truc OAuth2 de Google, puisqu'il fournit un UI décent sur Android.
Google déclare que " vous pouvez choisir d'utiliser le système D'authentification de Google comme un moyen de externaliser l'authentification de l'utilisateur pour votre application. Cela peut supprimer le besoin de créer, maintenir et sécuriser un nom d'utilisateur et le mot de passe du magasin. c'est ce que je veux faire. cependant quand je passe en revue tous leurs exemples et ainsi de suite, Je ne peux trouver des trucs sur le fait d'avoir un site web ou une application authentifier un utilisateur contre les services de Google.
et en effet, lorsque je vais enregistrer mon application ("client") avec OAuth2 de Google, il y a des options pour les clients du site web et les clients" installés " (c'est-à-dire une application mobile), mais pas les deux. Je peux créer deux clients séparés mais j'ai lu le projet OAuth2 et je pense qu'il y aura un problème, que je vais maintenant expliquer.
Voici comment je l'ai envisagé travailler:
- L'utilisateur demande à MyApp d'accéder à ses données personnelles.
- utilise la classe
AccountManagerD'Android pour demander un token d'accès pour les API de Google. - Android dit à l'utilisateur "L'application 'MyApp' veut accéder à vos informations de base sur Google. Est-ce ok?"
- L'utilisateur dit oui.
-
AccountManagerse connecte au serveur OAuth2 de Google en utilisant les informations stockées sur le téléphone, et demande un token d'accès.
Le jeton d'accès - (qui suit les lignes vertes) est retourné.
-
AccountManagerrenvoie le token d'accès à MyApp. - MyApp envoie une demande à MySite données privées, y compris le jeton d'accès.
- MySite doit vérifier l'utilisateur, en utilisant le token d'accès. Il valide le token comme décrit ici , avec Google - " Google, est-ce que ce token est valide?".
- maintenant, ce que je veux se produire est que Google dit" oui, celui qui vous l'a donné est en effet cet utilisateur.", mais ce que je pense va réellement se produire (basé sur le projet OAuth2 et la documentation de Google) est que il dira: "pas question! Ce jeton n'est valable que pour MyApp, et tu es MySite. GTFO!".
alors comment faire? Et S'il vous plaît ne dites pas "utiliser OpenID" ou "N'utilisez pas OAuth2" ou d'autres réponses tout aussi inutiles. Oh, et je tiens vraiment à garder à l'aide de la belle AccountManager de l'INTERFACE utilisateur plutôt que de la merde popup WebView s
Modifier
réponse provisoire (je ferai un rapport si cela fonctionne!) de Nikolaï, c'est qu'il doit en fait, cela fonctionne, et les serveurs de Google ne se soucieront pas de l'origine du token d'accès. Semble un peu peu pour moi, mais je vais voir si ça marche!!!
mise à Jour
j'ai mis en œuvre Ce modèle avec Facebook au lieu de Google et il fonctionne totalement. Le serveur OAuth2 ne se soucie pas d'où vient le token d'accès. Au moins Facebook ne le fait pas, donc je suppose que Google ne le fait pas non plus.
À la lumière de cela, il est une très mauvaise idée de stocker les jetons d'accès! Mais nous ne voulons pas non plus avoir à aller sur les serveurs Facebook/Google pour vérifier l'authentification pour les requêtes every car cela ralentira tout. Probablement la meilleure chose est d'ajouter un cookie d'authentification supplémentaire pour votre site que vous distribuez lorsque leur token d'accès est validé, mais une façon plus simple est juste de traiter le token d'accès comme un mot de passe et de stocker un hachage de celui-ci. Vous n'avez pas besoin de le saler non plus puisque les jetons d'accès sont vraiment très longs. Si les étapes ci-dessus deviennent quelque chose comme:
9. Monsite besoin de vérifier l'utilisateur, en utilisant le jeton d'accès. D'abord, il vérifie son cache de hachage valide les jetons d'accès. Si le hachage du token est trouvé là, il sait que l'utilisateur est authentifié. Sinon, il vérifie avec Google comme décrit ici , avec Google - " Google, ce token est-il valide?".
10. Si Google déclare que le token d'accès est invalide,nous en informons L'utilisateur. Autrement Google dit "oui qui est un utilisateur valide" et nous vérifions alors notre base de données d'utilisateur enregistré. Si ce nom d'utilisateur Google (ou Facebook id si vous utilisez Facebook) n'est pas trouvé, nous pouvons créer un nouvel utilisateur. Ensuite, nous cachons la valeur hachée du token d'accès.
6 réponses
vous avez probablement besoin D'OpenID Connect, qui utilise des tokens OAuth pour l'authentification. En ce qui concerne AccountManager , le support actuel de OAuth est un peu hacky, le nouveau Google Play Services , mis en ligne 'soon' devrait rendre cela meilleur. Voir ici pour une Démo .
je viens de poster une réponse à une question similaire.
Google appelle ce Hybrid Apps et explique comment une " application Android obtient l'accès hors ligne pour le Web back-end " .
l'essentiel est que vous devrez passer une chaîne de caractères scope massée dans GoogleAuthUtil.getToken afin de lui faire retourner un Code D'Autorisation (pas un jeton OAuth2). Que Le Code d'autorisation peut être transmis de votre application mobile à votre serveur et être échangé contre un Token OAuth2 et un Token de rafraîchissement, selon ce schéma .
le paramètre scope doit ressembler à quelque chose comme ceci:
oauth2:server:client_id:<your_server_client_it>:api_scope:<scope_url_1> <scope_url_2> ...
vous pouvez utiliser le token d'accès récupéré par l'application mobile n'importe où ailleurs. Drive SDK a une belle et simple intro qui passe par le flux sur https://developers.google.com/drive/quickstart-android
au moins avec Google, le token d'accès finit par expirer. C'est pourquoi l'android AccountManager a la méthode invalidateAuthToken --le token d'accès caché est expiré, et vous devez dire au AccountManager d'arrêter de vous donner l'ancien et à la place obtenir un nouveau. Cela rend un peu plus sûr de mettre en cache le token, car le token lui-même ne vous donne pas un accès Éternel en tant qu'utilisateur. Au lieu de cela, quand valide, il dit simplement "à un moment donné dans le passé récent, ce jeton a été acquis par un source."
voici quelques choses que j'ai trouvées utiles en travaillant avec des jetons. Le premier est tokeninfo endpoint de Google. Le jeton lui-même est juste Base64-encoded JSON. Cela signifie qu'il n'est pas crypté, vous devez ê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 token était "abcdef", vous navigueriez vers:
https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=abcdef
et Google déballerait le token pour vous. Il s'agit d'un simple objet JSON qui inclut un champ "expires_in" vous indiquant le nombre de secondes pour lesquelles le jeton est encore valide. À 6: 03 dans la vidéo ci-dessous vous pouvez voir le token déballé:
https://developers.google.com/events/io/sessions/383266187
cette vidéo comprend une vue d'ensemble complète de OAuth2 et vaut bien la peine de regarder dans son intégralité si vous allez avoir affaire à des OAuth et des tokens. L'orateur traite également d'autres formes de Oauth2 jetons, qui ne sont pas des jetons d'accès, qui n'expirent pas.
une autre ressource utile est le terrain de jeu D'OAuth. Cela vous permet de faire des choses de base comme les étendues, les demandes d', et obtenir 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 par Tim Bray, le haut-parleur dans 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 car j'ai commencé à comprendre comment fonctionnent les différentes choses de la Console de L'API Google. 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 token d'accès sur le serveur. Comme expliqué dans la vérification des appels Back End à partir du lien Android ci-dessus, vérifier un token est presque toujours un appel statique rapide, ce qui signifie qu'il n'y a aucune raison de mettre en cache les tokens:
les bibliothèques peuvent mettre en cache les certs de Google et ne les rafraîchir que si nécessaire, de sorte que la vérification est (presque toujours) un appel statique rapide.
Enfin, vous pouvez en effet utiliser le AccountManager pour obtenir des jetons d'accès. Cependant, Google maintenant encourage l'utilisation de la classe GoogleAuthUtil dans la bibliothèque Play Services à la place:
ici noter Le Commentaire de Tim Bray, le même gars encore une fois à partir des liens ci-dessus, disant qu'ils mettent leurs efforts dans le GoogleAuthUtil itinéraire. 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 token Facebook à la place--pas le cas avec GoogleAuthUtil .
il décrit exactement ce que vous voulez: https://developers.google.com/identity/protocols/CrossClientAuth
lorsque nous avions besoin de faire quelque chose de similaire sur un serveur autre que google outh, nous avons gardé les jetons dans un DB sur le site. L'application utiliserait alors les services web pour demander le token au besoin pour demander des données.
l'utilisateur peut procéder à l'enregistrement sur le web ou sur l'application. Ils partageaient le même token d'application, donc ils pouvaient partager le même token d'accès. Après l'enregistrement, nous stockerions les jetons d'accès et de rafraîchissement dans la base de données pour une utilisation à partir de n'importe quelle application il le fallait.