0

We are using G Suite API with our Micro service for document editing, and we have a different data center and also different db. now once user comes to my application and trying to open document first time then google give consent screen based on that i can get refresh token and access token and i store into one data center.

But problem is that if user comes from another instance which use different data center with different db and user trying to open document with old credentials then google doesn't give any consent screen so i am not getting user's refresh token.

1) So is there any way to get refresh token without using consent screen?

2) Is there any way to identify if user comes from different sub domain then i need to provide consent screen for that?

John Hanley
  • 74,467
  • 6
  • 95
  • 159
Ravi
  • 38
  • 7

4 Answers4

0

It might be possible to use the prompt=consent option to force a re-prompt for auth, even though the user has already authorized your app.

See https://developers.google.com/identity/protocols/OAuth2WebServer#creatingclient

pinoyyid
  • 21,499
  • 14
  • 64
  • 115
  • Thanks for your quick response, but problem with this use case is that if i use this option then it will prompt user every time for a consent. – Ravi Jan 04 '19 at 06:26
  • so you change your code so it only uses 'prompt=consent' on the first use. Subsequent uses default to 'prompt=none' – pinoyyid Jan 04 '19 at 16:24
0

You can identify the user's domain using the hd parameter [1] and you can request a refresh token without the consent screen after the domain admin has configured domain wide delegation by installing your application from the GSuite Marketplace [2].

[1] https://developers.google.com/identity/protocols/OpenIDConnect#hd-param

[2] https://support.google.com/a/answer/172482?hl=en

user2705223
  • 1,219
  • 6
  • 10
0

When you request an OAuth Flow (access_type=offline`), a Refresh Token is returned to your application. This only happens once (obtaining a Refresh Token). Your application is expected to save the Refresh Token for future needs.

In your use case, one of your systems completed the authentication and the user has moved to a different system. You will need to reauthenticate with prompt=consent, access_type=offline. You will not get another Refresh Token without reauthenticating.

I spent a lot of time on this issue last November. Here is a link which has lots of details on this problem.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • Thanks for your quick response, but problem with this use case is that once again user moved to first system then from that system user get refresh token which is already expired due to newly generated refresh token in another system. So, is there any way to override this? – Ravi Jan 04 '19 at 07:18
  • 1
    In that case, you will need to save the refresh token and then share that token with your various systems. In the Client ID token will be the user's identity. Use the email address as your ID into your shared system (memcache, etc.). Save the Refresh Token. Then when the user arrives at a system, check the ID and grab the refresh token. Also keep track of the expires_at for the Access Token. – John Hanley Jan 04 '19 at 07:45
  • Thanks @john Hanley, but we have a security concern so we are not allow to put this information into cache and share that cache with other application. – Ravi Jan 04 '19 at 08:44
  • 1
    @Ravi - You only have two choices: 1) Save the Refresh Token 2) authenticate the user at each system. You may not like it but you must design your systems to support OAuth's requirements. Since you cannot cache the token, your only option is to require authentication at each system. Since this invalidates the refresh token, it would be better that you design each system as its own OAuth Client ID (meaning each system has its own set of OAuth tokens and identity). – John Hanley Jan 04 '19 at 10:00
  • you say "refresh token which is already expired due to newly generated refresh token ". Requesting a 2nd Refresh Token will **not** invalidate an existing Refresh Token. Currently Google allows approximately 25 valid Refresh Tokens per account-project. – pinoyyid Jan 04 '19 at 16:27
0

Any application can only have one valid refresh token for a user. You can request for a new refresh token using the prompt=true&access_type=offline on the request as said by @John. But every time the previous one will become invalid.

Based on you comments on the other answers, I'm assuming creating a new micro service that returns the token to the one being used is not a possibility (that would be my recommendation)

You asked "to identify if user comes from different sub domain"...
If those applications are for end users of gmail.com accounts, you can treat them as different applications and configure different projects on the developer console.
It will be a bit of a pain when enabling new APIs, I would recommend doing that from a script that replicates to all application needed.

If your end users are from companies using GSuite, you can have your app installed as domain-wide application (either manually or from GSuite Marketplace). In that case you can use just client side authentication to get an id_token, send the token to the server and use a service account to impersonate the user in any given service without worrying about any token from them.

Luiz Ferraz
  • 1,427
  • 8
  • 13