How to make Google sign-in token valid for longer

问题:

I have implemented google sign-in successfully.

I am able to authenticate user and in response I receive token. However the token expires in 1 hour.

expires_in: "3600"

I tried searching in the docs - https://developers.google.com/identity/sign-in/web/reference - but cannot find a paramenter to extend the lifespan of the token.

---

What I'm actually trying to do?

https://developers.google.com/identity/sign-in/web/backend-auth

after a user successfully signs in, send the user's ID token to your server using HTTPS

I'm sending token with each request to the server:

endpoint/get?access_token=" + access_token

And then on the server I'm calling https://www.googleapis.com/oauth2/v3/tokeninfo

So I have a token, every request is authenticated, but after 1 hour of working the tokeninfo method returns false and I need to re-authenticate the user.

In my code I circumvented that by storing all the historical access_tokens and if client uses old token I check against historical data and manually issue new token using refresh_token (one of my permissions is to grant offline access)

---

So yes, I'd be very interested to know:

• How to expand lifespan of the access_token?

OR

• Given the limited lifespan how to ensure requests are authenticated on the backend?

回答1:

As @DaImTo noted, you can't extend the life of an access_token. You can get a new one using a refresh_token, but often if you're trying to do this client side and have a server, you should re-think your approach.

It sounds like there are two "authentications" that you're doing here - the client authenticating against the server, and the server authenticating against the Google service. Right now, the server should be holding onto the refresh token - so it can always re-authenticate against Google. It sounds like you're wrestling with how to authenticate your client against the server after the auth_token timeout.

In general, the client shouldn't send the access_token to the server, nor the refresh_token. What it does is during the first sign-in, the client gets a one-time code (from Google) which it hands to the server. The server uses this to talk to Google and get the access_token and refresh_token, confirming the user has authenticated themselves, and then sends something (usually a cookie) back to the client saying "ok, I've authenticated you. Here is how you keep authenticating yourself for the rest of our conversation."

That later action is pretty standard and is unrelated to oauth itself. The client and server then communicate as they always do - no oauth stuff is exchanged at all, you're relying on the cookie (or equivalent) to keep up the client-server authentication. The server continues to use the auth token and refresh token to talk to Google.

https://developers.google.com/identity/sign-in/web/server-side-flow I think is the best guide to this at the moment. Or at least it is the best one I can find at the moment. It has a good diagram, at least.

The key point is that you're exchanging the brilliantly named "code" with the server (what I was calling the "one-time code"). Once you have done that, the server authenticates you with Google - and it then has the access/refresh tokens and you communicate with the server without having to pass those.

回答2:

Access tokens are short lived and only last for one hour this is not something you can extend.

What you need to do is take the refresh token and get a new access token.

example:

You take the refresh_token that you got from your initial request and HTTP Post it to: Note: grant_type=refresh_token

https://accounts.google.com/o/oauth2/token
client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&refresh_token=1/ffYmfI0sjR54Ft9oupubLzrJhD1hZS5tWQcyAvNECCA&grant_type=refresh_token

response

{
"access_token" : "ya29.1.AADtN_XK16As2ZHlScqOxGtntIlevNcasMSPwGiE3pe5ANZfrmJTcsI3ZtAjv4sDrPDRnQ",
"token_type" : "Bearer",
"expires_in" : 3600
}