Authentification avec OAuth2 pour une application *et* un site web

Question

Je développe un site Web auquel on accède principalement 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 matériel OAuth2 de Google, car il offre une interface utilisateur décente sur Android.

Google indique 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. Cela peut supprimer la nécessité de créer, maintenir et sécuriser un magasin de noms d'utilisateur et de mots de passe." ce qui est ce que je veux faire. Cependant quand je regarde tous leurs exemples et autres, je ne trouve que des trucs pour avoir un site web. ou une application authentifie un utilisateur auprès des services de Google.

En effet, lorsque j'enregistre mon application ("client") dans OAuth2 de Google, des options sont proposées pour les clients de sites web 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 projet OAuth2 et je pense qu'il y aura un problème, que je vais maintenant expliquer.

Voici comment j'ai envisagé le fonctionnement :

1. L'utilisateur demande à MyApp d'accéder à ses données privées.
2. L'application utilise la fonction AccountManager pour demander un jeton d'accès aux API de Google.
3. Android dit à l'utilisateur "L'application 'MyApp' veut accéder à vos informations de base sur Google. Est-ce que cela vous convient ?"
4. L'utilisateur dit oui.
5. AccountManager se 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 demande à 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 veulent Je pense que Google répondra "Oui, la personne qui vous l'a donné est bien cet utilisateur", mais je pense que ce qui se passera réellement (d'après le projet OAuth2 et la documentation de Google), c'est qu'il dira "Pas question ! Ce jeton n'est valable que pour MyApp, et vous êtes MySite. DÉGAGEZ !".

Comment dois-je m'y prendre ? Et s'il vous plaît, ne dites pas "Utilisez OpenID" ou "N'utilisez pas OAuth2" ou d'autres réponses aussi peu utiles. Oh, et j'aimerais vraiment continuer à utiliser l'agréable AccountManager Une interface utilisateur plutôt qu'un popup pourri WebView s

Modifier

La réponse provisoire (je ferai un rapport si ça marche !) de Nikolay est que ça devrait fonctionner et que les serveurs de Google ne se soucient pas de la provenance du jeton d'accès. Cela me semble peu sûr, mais je verrai si cela fonctionne !

Mise à jour

J'ai mis en œuvre ce modèle avec Facebook au lieu de Google et cela fonctionne parfaitement. Le serveur OAuth2 ne se soucie pas de l'origine du jeton d'accès. Du moins, celui de Facebook ne s'en soucie pas, donc je suppose que celui de Google non plus.

Dans ces conditions, c'est une très très mauvaise idée de stocker des jetons d'accès ! Mais nous ne voulons pas non plus avoir à frapper les serveurs de Facebook/Google pour vérifier l'authentification de chaque car cela va tout ralentir. La meilleure solution consiste probablement à ajouter un cookie d'authentification supplémentaire pour votre site que vous remettez lorsque le jeton d'accès est validé, mais une solution plus simple consiste à traiter le jeton d'accès comme un mot de passe et à en stocker un hachage. Il n'est pas non plus nécessaire de le saler puisque les jetons d'accès sont vraiment très longs. Ainsi, les étapes ci-dessus deviennent quelque chose comme :

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

10. Si Google dit que le jeton d'accès n'est pas valide, nous disons à l'utilisateur de dégager. Sinon, Google dit "Oui, c'est un utilisateur valide" et nous vérifions alors notre base de données des utilisateurs enregistrés. Si le nom d'utilisateur Google (ou l'identifiant 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.

Answer 1

Je viens de poster une réponse à une question similaire sur StackOverflow.

Google appelle cela Applications hybrides et explique comment un "L'application Android obtient un accès hors ligne pour le back-end Web" .

L'essentiel est que vous devrez passer un massage scope dans la chaîne GoogleAuthUtil.getToken afin qu'il renvoie un code d'autorisation (et non un jeton OAuth2). Ce code d'autorisation peut être transmis de votre application mobile à votre serveur et être échangé contre un jeton OAuth2 et un jeton de rafraîchissement. ce schéma .

El scope doit ressembler à quelque chose comme ceci :

oauth2:server:client_id:<your_server_client_it>:api_scope:<scope_url_1> <scope_url_2> ...

Answer 2

Vous pouvez utiliser le jeton d'accès récupéré par l'application mobile n'importe où ailleurs. Drive SDK a une introduction simple et agréable qui décrit le flux de données sur le site Web de Drive. https://developers.google.com/drive/quickstart-Android

Answer 3

Vous avez probablement besoin d'OpenID Connect, qui utilise des jetons OAuth pour l'authentification. Quant à AccountManager Le support actuel d'OAuth est un peu bricolé, le nouveau support d'OAuth a été mis en place. Services Google Play qui sera bientôt disponible, devrait permettre d'améliorer la situation. Voir ici pour un Démonstration .

Answer 4

Au moins avec Google, le jeton d'accès finit par expirer. C'est pourquoi le système Android [AccountManager](http://developer.android.com/reference/android/accounts/AccountManager.html) a le invalidateAuthToken le jeton d'accès mis en cache a expiré, et vous devez indiquer à la méthode AccountManager d'arrêter de vous donner l'ancien et de vous en donner un nouveau. Cela rend la mise en cache du jeton un peu plus sûre, 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 indique simplement "à un moment donné dans un passé récent, ce jeton a été acquis par une source de confiance".

Voici quelques éléments que j'ai trouvés utiles lorsque je travaille avec des jetons. La première est le point de terminaison tokeninfo de Google. Le jeton lui-même est juste un JSON codé en base64. Cela signifie qu'il n'est pas crypté et que vous devez vous assurer d'utiliser le protocole 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 navigueriez vers :

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

et Google déballera le jeton pour vous. Il s'agit d'un simple objet JSON qui comprend un champ "expires_in" vous indiquant le nombre de secondes pendant lequel le jeton est encore valide. À 6:03 dans la vidéo ci-dessous, vous pouvez voir le jeton décompressé :

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

Cette vidéo donne un aperçu complet d'OAuth2 et mérite d'être regardée dans son intégralité si vous avez l'intention d'utiliser OAuth et des jetons. Le conférencier aborde également d'autres formes de jetons OAuth2, qui ne sont pas des jetons d'accès, et qui n'expirent pas.

Une autre ressource utile est l'OAuth Playground. Il vous permet de faire des choses basiques comme demander des scopes, créer des requêtes et récupérer des tokens. 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, l'intervenant de la vidéo, qui explique comment utiliser les jetons d'accès pour communiquer avec un serveur depuis une application Android. Cela m'a été utile car j'ai commencé à comprendre comment les différents éléments de la Google API Console fonctionnent ensemble :

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

Pour ce qui est de 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 ci-dessus sur la vérification des appels back-end depuis Android, 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 les jetons en cache :

Les bibliothèques peuvent mettre en cache les certitudes de Google et ne les rafraîchir qu'en cas de besoin, de sorte que la vérification est (presque toujours) un appel statique rapide.

Enfin, vous pouvez effectivement utiliser l'option AccountManager pour obtenir des jetons d'accès. Toutefois, Google encourage désormais plutôt l'utilisation de l'option [GoogleAuthUtil](http://developer.android.com/reference/com/google/android/gms/auth/GoogleAuthUtil.html) dans la bibliothèque Play Services :

En bref, quelle est la différence avec les requêtes OAuth2 getAuthToken et getToken ?

Notez ici le commentaire de Tim Bray, le même gars encore une fois dans les liens ci-dessus, disant qu'ils mettent leurs efforts dans la GoogleAuthUtil route. Notez toutefois que cela signifie que vous seriez limité à l'authentification Google. Je crois que le AccountManager pourrait être utilisé pour obtenir, par exemple, un jeton Facebook à la place - ce qui n'est pas le cas avec l'option GoogleAuthUtil .

Answer 5

Lorsque nous avons eu besoin de faire quelque chose de similaire sur un serveur OAuth non Google, nous avons conservé les jetons dans une base de données sur le site Web. L'application utilisait ensuite les services web pour demander le jeton lorsque cela était nécessaire pour demander des données.

L'utilisateur peut effectuer l'enregistrement OAuth sur le web ou sur l'application. Ils ont partagé le même jeton d'application, donc ils ont pu 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 qu'ils puissent être utilisés par n'importe quelle application qui en a besoin.