Google - continually use refresh token ( NOT Working )

[kishoreyellamraju]

The refresh access token is not happening on the master branch. The pull request #117 solved this but looks like its broken on the master branch. The session times out after 3600 seconds and asks user to login again.

[jehiah]

@kishore1431 can you share what your relevant config options are? Also, are you seeing any errors in the oauth2_proxy logs?

[kishoreyellamraju]

Here are the config options that i am using. I don't see any errors but i no longer see the below statement in the logs

"2016/02/24 11:45:02 google.go:154: refreshed access token Session{xyz@abcd.com token:true expires:2016-02-24 12:45:02 -0800 PST refresh_token:true} (expired on 2016-02-24 11:21:58 -0800 PST)"

I rolled back to v2.0.1 and the refresh access token is working as expected but this version has "approval_prompt" hardcoded to "force" in the code :(.

Note: used dummy cookie/domain names.

approval_prompt="auto"
access_type="offline"
cookie_name = "_oauth2_abcdef_s1234"
cookie_secret = "oauth2_1234oauth"
cookie_domain = ".abcd.com"
cookie_expire = "9h"
cookie_refresh = "1h"
cookie_secure = true

[jehiah]

@kishore1431 are you sure you are not just observing the timeout passed the 9h cookie TTL? (FWIW, i run with expiration set to 504h and refresh set to 3h.

[kishoreyellamraju]

@jehiah :). Its definitely not the 9h timeout, its timing out every 60 mins and asking user to login again.

[szibis]

Yes i have same issue. All cookie refresh is working, and there is valid response from google:

200 GET https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token> {
 "issued_to": "<id>.apps.googleusercontent.com",
 "audience": "<id>.apps.googleusercontent.com",
 "user_id": "<userid>",
 "scope": "https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
 "expires_in": 1108,
 "email": "xx@example.com",
 "verified_email": true,
 "access_type": "offline"
}

in config:

cookie_refresh = "15m"
cookie_expire = "168h"

As we see in log output above, we have expire_in that google is setting to max 3600 seconds on start - no more, no less and it is not configurable as far as i know.
And in this 1h period of time all is working like it should. When i set refresh cookie to 15 minutes and block user account in Google, then user gets 403 when cookie try to be refreshed and this is what we need, but......

2016/02/27 17:22:21 oauthproxy.go:533: 127.0.0.1:58466 ("111.111.111.111") refreshing 1h44m28s old session cookie for Session{xx@example.com token:true expires:2016-02-27 16:37:52 +0000 UTC} (refresh after 15m0s)
2016/02/27 17:22:21 oauthproxy.go:547: 127.0.0.1:58466 ("111.111.111.111") removing session. token expired Session{xx@example.com token:true expires:2016-02-27 16:37:52 +0000 UTC}

Last try to refresh cookies session failed because access token in Google expired and it is not refreshed in last 3600 seconds.
We have feature like group access and refresh token in Google, but after this commit something is broken - d49c3e1
This code is never visible in logs as i check -

oauth2_proxy/providers/google.go

Line 154 in d49c3e1

log.Printf("refreshed access token %s (expired on %s)", s, origExpiration)

Only way to start working again is refresh whole site in browser. This is especially bad idea when we operate on site with many javascripts and after 1 hour any request from javascript failing.

[szibis]

More update. Looks like problem exists only on pages that use xhr requests from javascript. After one hour when access token expires and full auth is triggered for any request (cookie refresh and session expires in oauth2) then any request from javascript inside page fails.
It fail on accounts.google.com, because Google is not allowing this origin to talk from javascript - CORS (they don't expose Access-Control-Allow-Origin header ). Even after adding Authorized JavaScript origins inside google developers pages settings for this oauth2 user.

I think main problem is that access token in oauth2 proxy is only redeemed when all sessions expired and triggers whole auth from web page side (using auth_request from nginx). This should be refreshed in background just like cookie refresh.

[szibis]

Error from Google:

XMLHttpRequest cannot load https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&approval_p…callback&response_type=code&scope=profile+email&state=/. 
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://<my origin> is therefore not allowed access.

Origin is available in request headers to Google. My origin is set in google developers panel in Authorized JavaScript origins, but as i write before only jsonp requests have Access-Control-Allow-Origin present from Google.

[r0ps3c]

Hi,

I believe we are seeing this also, is there a workaround or fix available for this?

[r0ps3c]

@szibis, where are you seeing that xhr error? In the logs for oauth2_proxy or somewhere else?

[antgel]

Hi all. We also suffer from this in a heavily-Javascript based webapp. It's been really quiet on this bug for months - any progress / workarounds / whatever that can help move forward? We can code a bit too, but we don't know anything about Go. :)

[jehiah]

@antgel If you can confirm this is still a problem against the most recent release (v2.1) or HEAD and provide steps to reproduce that would be helpful.

[antgel]

So, we are using the latest version with the auth_request, the users authenticate using a web page, but then they are redirected to a single page app and only use AJAX. And we see in the oauth2_proxy logs that it doesn't update their cookie, only removes it.

Reproduction is hard as our app is internal. Would you be up for doing a screenshare, or I could send screenshots or logs, or anything you tell me that would be useful. Sorry to be difficult but we would like to help.

I see lines in the log like:
Jul 19 13:31:33 i-0e4e37ed80d3bbce2 oauth2_proxy[4424]: 2016/07/19 13:31:33 oauthproxy.go:538: 10.31.68.84:21097 refreshing 21h31m4s old session cookie for Session{michael@MUNGED.com token:true expires:2016-07-18 17:00:29 +0000 UTC refresh_token:true} (refresh after 1h0m0s)

[r0ps3c]

I'm no longer seeing this bug (since after I originally reported it) but suspect that something else in our infrastructure - specifically outbound proxy filtering - was causing the issue

[antgel]

We don't have anything fancy going on like that.