[Openid-specs-ab] Offline access discussion
george.fletcher at teamaol.com
Tue May 22 19:23:11 UTC 2012
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.
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab