Google HTTP / REST OAuth：授权代码请求具有数据库用户的状态，访问令牌请求没有

Question

I am using the OAuth server flow for Google. It starts with the user clicking a link that runs javascript to open a popup with the following request in the URI which is all working great:

var endpoint = "https://accounts.google.com/o/oauth2/auth";
        endpoint = endpoint + "?scope="+encodeURIComponent(googlecalendar.SCOPES);
        endpoint = endpoint + "&redirect_uri="+encodeURIComponent("https://myserver/google/");
        endpoint = endpoint + "&response_type=code";
        endpoint = endpoint + "&access_type=offline";
        endpoint = endpoint + "&approval_prompt=force";
        endpoint = endpoint + "&client_id="+encodeURIComponent(googlecalendar.CLIENT_ID);
        endpoint = endpoint + "&state="+encodeURIComponent(googlecalendar.USER_ID);

On the server side, I get the state which contains the user_id for my DB and the authorisation code. Now I want to exchange the authorisation code for access token (and renew token). This will be a HTTP request with a redirect URI, no state parameter is included.

The problem is that when I get those, I will need to store them against a user in my DB, but I don't have any way to check which user the callback is for.

The best I was able to come up with is using the token to query the google user's identity it belongs to but this still won't help me to find the user in the DB.

Can anyone help me with this flow? There must be some way to do. I don't want to use client libraries because later when I need to create watchers the PHP client library does not include this for the calendar API.

Answer 1

Short Answer

Despite the presence of a redirect parameter, the access token will generate a standard 200 response, not a 301 redirect. Depending on how you issue and handle the request/response, you can preserve your state.

More Detailed Answer

According to section 4.1.4 of the OAuth 2.0 spec document (RFC 6749), the response to an Access Token Request should be an "HTTP/1.1 200 OK".

In other words, the server will not perform a redirect, meaning you can issue a request and process the response in the same scope (either in the client or server, whatever your situation), so your database user ID need only be in local memory.

This is different from the Authorization Request, which is supposed to result in an "HTTP/1.1 302 Found" (redirect). See section 4.1.2 .

So why is the redirect_uri parameter required?

According to section 4.1.3 , the server must:

• ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.

In other words, the redirect_uri acts as a sort of secret or password which the server must use to verify the access token request. If the client fails to provide a redirect_uri parameter, or the parameter value is different from the original request, then the server must reject the access token request.