[Openid-specs-ab] Offline access discussion

Nat Sakimura sakimura at gmail.com
Tue May 22 19:27:46 UTC 2012

Thanks George.

Breno, could I hear your opinion?


On Wed, May 23, 2012 at 4:23 AM, George Fletcher <
george.fletcher at teamaol.com> wrote:

>  A few comments...
> 1. You are correct that AOL's implementation requires server side session
> state. This could be an issue for some IdP implementations.
> 2. Refreshing tokens via the browser (front-channel) ensures that the
> browser is still present. This is useful for the case where the user just
> closes their browser. Any associated RPs will not be able to retrieve an
> updated access token because there will be no browser present via which to
> do the "refresh".
> 3. Given that AOL wants to support the offline_access concept for native
> OAuth2 authorizations as well and OpenID Connect, I think this needs to
> stay part of the scope. It seems strange that if a developer is using
> OpenID Connect they pass the offline_access value in one parameter but then
> use a different parameter if doing OAuth2.
> 4. Proxying via the front-channel is somewhat more complex than a simple
> back channel call be between the RP and the central IdP. At a minimum front
> channel requires a js library to manage polling of the shared "IdP" to
> maintain fresh tokens, or to refresh a token. Most likely, this is a code
> flow which will force the RP to still do a back channel call to actually
> retrieve the token.
> Thanks,
> George
> On 5/22/12 3:00 PM, Nat Sakimura wrote:
> In the Yahoo! meeting, we had some discussions around offline access. The
> discussion did not finish there and we did not have much time to discuss in
> the IIW to reach the consensus either.
>  From what I see from the notes in the issue tracker (
> https://bitbucket.org/openid/connect/issue/539/ ), the following is my
> take:
>  So Google and AOL approach does not seem too dissimilar.
> Both requires explicit user consent for obtaining the refresh token.
> Differences:
>    1. In AOL's case, refresh token which is bound to the session is
>    returned for 'code' case, while Google does not return it. In AOL's case,
>    the client should send refresh token through the back channel to update the
>    access token, while in Google's case, prompt=none front channel call should
>    be used to get the refreshed access token.
>       1. Advantage of AOL's approach is that it allows simpler
>       implementation for the proxied clients (e.g., MapQuest-AOL-Google case).
>       2. Google states that their approach allows "unified button" for
>       new registration and authentication. (Is this also achievable with AOL's
>       methodology?)
>       3. Perhaps Googles approach allows the server to be stateless while
>       AOL's approach requires it to be stateful?
>     2. AOL uses scope to indicate the offline access request, while
>    Google uses a new extension parameter called access_type.
>       1. AOL's approach is one less extension variable while Google's
>       approach probably is cleaner than putting everything in the scope bucket.
> I do not think we have consensus on this issue yet. Please discuss.
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120523/4c0cc86e/attachment-0001.html>

More information about the Openid-specs-ab mailing list