Nous utilisons l'API G Suite avec notre service Micro pour l'édition de documents, et nous avons un centre de données différent et également une base de données différente. maintenant, une fois que l'utilisateur accède à mon application et essaie d'ouvrir le document pour la première fois, Google donne un écran de consentement basé sur le fait que je peux obtenir un jeton d'actualisation et un jeton d'accès et je stocke dans un centre de données.
Mais le problème est que si l'utilisateur provient d'une autre instance qui utilise un centre de données différent avec une base de données différente et un utilisateur essayant d'ouvrir un document avec d'anciennes informations d'identification, Google ne donne aucun écran de consentement, je ne reçois donc pas le jeton d'actualisation de l'utilisateur.
1) Existe-t-il donc un moyen d'obtenir un jeton d'actualisation sans utiliser l'écran de consentement?
2) Existe-t-il un moyen d'identifier si l'utilisateur provient d'un sous-domaine différent, alors je dois fournir un écran de consentement pour cela?
4 Réponses :
Il peut être possible d'utiliser l'option prompt = consent pour forcer une nouvelle demande d'authentification, même si l'utilisateur a déjà autorisé votre application.
Voir https://developers.google.com/identity/protocols/OAuth2WebServer# création de client
Merci pour votre réponse rapide, mais le problème avec ce cas d'utilisation est que si j'utilise cette option, elle invitera l'utilisateur à chaque fois à donner son consentement.
vous changez donc votre code pour qu'il n'utilise que «prompt = consent» lors de la première utilisation. Les utilisations suivantes par défaut sont «prompt = none»
Vous pouvez identifier le domaine de l'utilisateur à l'aide du paramètre hd [1] et vous pouvez demander un jeton d'actualisation sans l'écran de consentement une fois que l'administrateur du domaine a configuré la délégation à l'échelle du domaine en installant votre application à partir de GSuite Marketplace [2].
[1] https://developers.google.com/identity/ protocoles / OpenIDConnect # hd-param
Lorsque vous demandez un flux OAuth (access_type = offline`), un jeton d'actualisation est renvoyé à votre application. Cela ne se produit qu'une seule fois (obtention d'un jeton de rafraîchissement). Votre application devrait enregistrer le jeton d'actualisation pour les besoins futurs.
Dans votre cas d'utilisation, l'un de vos systèmes a terminé l'authentification et l'utilisateur est passé à un autre système. Vous devrez vous authentifier à nouveau avec prompt = consentement, access_type = offline . Vous n'obtiendrez pas un autre jeton d'actualisation sans vous authentifier à nouveau.
J'ai passé beaucoup de temps sur cette question en novembre dernier. Voici un lien qui contient de nombreux détails sur ce problème.
Merci pour votre réponse rapide, mais le problème avec ce cas d'utilisation est qu'une fois de plus, l'utilisateur est passé au premier système, puis de cet utilisateur système reçoit un jeton d'actualisation qui a déjà expiré en raison d'un jeton d'actualisation nouvellement généré dans un autre système. Alors, y a-t-il un moyen de contourner cela?
Dans ce cas, vous devrez enregistrer le jeton d'actualisation, puis partager ce jeton avec vos différents systèmes. Dans le jeton d'ID client, il y aura l'identité de l'utilisateur. Utilisez l'adresse e-mail comme identifiant dans votre système partagé (Memcache, etc.). Enregistrez le jeton d'actualisation. Ensuite, lorsque l'utilisateur arrive sur un système, vérifiez l'ID et récupérez le jeton d'actualisation. Gardez également une trace de expires_at pour le jeton d'accès.
Merci @john Hanley, mais nous avons un problème de sécurité, nous ne sommes donc pas autorisés à mettre ces informations dans le cache et à partager ce cache avec une autre application.
@Ravi - Vous n'avez que deux choix: 1) Enregistrer le jeton d'actualisation 2) authentifier l'utilisateur sur chaque système. Cela ne vous plaira peut-être pas, mais vous devez concevoir vos systèmes pour prendre en charge les exigences d'OAuth. Étant donné que vous ne pouvez pas mettre en cache le jeton, votre seule option est d'exiger une authentification sur chaque système. Étant donné que cela invalide le jeton d'actualisation, il serait préférable de concevoir chaque système comme son propre ID client OAuth (ce qui signifie que chaque système a son propre ensemble de jetons OAuth et d'identité).
Vous dites "Actualiser le jeton déjà expiré en raison d'un jeton de rafraîchissement nouvellement généré". Demander un 2e rafraîchissement du jeton pas Invallamez un jeton de rafraîchissement existant. Actuellement, Google permet d'environ 25 jetons de rafraîchissement valides par projet de compte.
Toute application ne peut avoir qu'un seul jeton d'actualisation valide pour un utilisateur. Vous pouvez demander un nouveau jeton d'actualisation en utilisant le prompt = true & access_type = offline sur la demande comme indiqué par @John. Mais à chaque fois que le précédent deviendra invalide.
Sur la base de vos commentaires sur les autres réponses, je suppose que la création d'un nouveau micro service qui renvoie le jeton à celui utilisé n'est pas une possibilité (ce serait ma recommandation)
Vous avez demandé "d'identifier si l'utilisateur provient d'un sous-domaine différent" ...
Si ces applications sont destinées aux utilisateurs finaux de comptes gmail.com, vous pouvez les traiter comme des applications différentes et configurer différents projets sur la console développeur.
Ce sera un peu pénible lors de l'activation de nouvelles API, je recommanderais de le faire à partir d'un script qui se réplique vers toutes les applications nécessaires.
Si vos utilisateurs finaux appartiennent à des entreprises utilisant GSuite, vous pouvez installer votre application en tant qu'application à l'échelle du domaine (manuellement ou depuis GSuite Marketplace). Dans ce cas, vous pouvez utiliser uniquement l'authentification côté client pour obtenir un id_token, envoyer le jeton au serveur et utiliser un compte de service pour usurper l'identité de l'utilisateur dans un service donné sans vous soucier de tout jeton de leur part.