Upcoming changes to the OAuth2 endpoint

[Justin Smith]

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected. We will be releasing these changes on November 15, 2011. 

There's a minor change to the error behavior of the client-side flow, as well as two changes to the server-side flow. The client-side flow error change brings our OAuth2 support into compliance with the latest specification. The changes to the server-side flow are motivated by feedback we've received from partners & on this forum. Concretely, these changes will surface offline, out-of-band access to end-users and auto-approval.

For more information no the changes, see http://googlecode.blogspot.com/2011/10/upcoming-changes-to-oauth-20-endpoint.html

--justin

[Ward Yaternick]

In regards to Server-Side processing,  let's assume the client has requested and received a short-lived token. The next step is to POST a request to obtain a refresh token from the server.  You said in your blog (excerpt below) that "Refresh tokens are not returned" when the user is returning from a prior session where a refresh token was issued. 

My question is: What happens? What does the server return when it is asked for a refresh token in this situation?

The reason I ask is that perhaps this is the issue I'm experiencing in the other thread of this Group currently active.  In that thread, I explain that I ask for the refresh token but the POST doesn't seem to get a reply from the server; it just sits and waits. I won't repeat the whole thread here but I was just wondering if this is a situation where the server is confused by being asked for a Refresh token when the client isn't expected to be asking.

Thanks, 

Ward

-----

blog excerpt: 

"To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved."

[Justin Smith]

Lets say a user comes to the site and has never been there before. The following could happen:

a) client requests an authorization code by redirecting a browser (GET) to a Google URL with several parameters (including access_type=offline)

b) client receives the response, parses the authorization code from the response, and redeems the authorization code for an access and refresh token. This is a POST. The client stores the refresh token.

c) client sends the access token as part of an API request

d) when the access token times out, the client can get a new access token using the refresh token. This is a POST.

Fast forward, let's say the user comes back to the site and triggers a similar flow. The flow becomes:

e) client requests an authorization code by redirecting a browser (GET) to a Google URL with several parameters (including access_type=offline)

f) client receives the response, parses the authorization code from the response, and redeems the authorization code for an access token (no refresh token is returned). This is a POST.

g) client sends the access token as part of an API request

h) when the access token times out, the client can get a new access token using the refresh token (stored in (b)). This is a POST.

I'll try to repro the behavior you are seeing on a Windows machine & we'll go from there.

[Ward Yaternick]

What happens in step h if the refresh token is lost or corrupted and therefore can't be used? 

How does the client and/or vendor recover from that situation? 

I think I know the answer but would be good to see it stated.

thanx

[Justin Smith]

Today explicit consent is required each time through the flow. An access token and refresh token returns each time you exchange an authorization code.

With the changes outlined in the original post, we're moving to a model where consent is remembered from the first time through the flow. The client gets a refresh token on the 1st time through the flow (not the subsequent iterations).

If the client loses the refresh token, you send the user through the flow with the approval_prompt=force parameter. That will ask the user for explicit consent, and the next time the client exchanges the authorization code, it will get a new refresh token. Keep in mind this is not the behavior today, but it is coming later in the month.