Example 1: OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=token+cookie' OpenIDConnect End User Authorization Response '<other required OAuth2 parameters>&access_token=foo&cookie=bar'
Example 2: OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=code+cookie' OpenIDConnect End User Authorization Response '<other required OAuth2 parameters>&code=foo' OpenIDConnect outcome of grant redemption ... '<other required OAuth2 parameters>[&refresh_token=foo]&access_token=bar&cookie=baz' Example 3 (specific syntax still to be agreed upon): OpenIDConnect End User Cookie Refresh Request '<other required OAuth2 parameters>&response_type=cookie&cookie=... ' OpenIDConnect End User Cookie Refresh Response '<other required OAuth2 parameters>&cookie=foo' Example 4 (specific syntax still in the work): OpenIDConnect End User Logout Request '&access_token=bar' (to new endpoint) OpenIDConnect End User Logout Response '<something to mean ok>' On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > Can you send an example wire interaction? > > > > EHL > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > *Sent:* Thursday, February 17, 2011 10:07 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > Ok. > > > > So you want to request a cookie from both endpoints: the authorization > endpoint and the token endpoint? How would that work? There is no > response_type on the token endpoint. > > > > There is no need to. The grant carries the information. > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > *Sent:* Thursday, February 17, 2011 9:30 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > So an implicit grant can produce just a cookie or both cookie and token, > but not code? > > > > Yes, cookies would be returned in the same context of access_tokens, either > as the result of an implicit grant or resulting from an explicit exchange > from a code-type grant. > > > > > > > > EHL > > > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > *Sent:* Thursday, February 17, 2011 5:10 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > Is cookie exchanged for an access token? Authorization grants are not meant > to be useful by themselves, only exchanged for an access token. > > > > In this scenario, grants are exchanged for access tokens and/or cookies. > > > > > > Can you request only a cookie? Or is it always with either a token or code? > > > > The idea is that a grant can be exchanged for only a cookie in some cases. > > > > > > EHL > > > > > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > *Sent:* Thursday, February 17, 2011 4:50 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don’t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > > > > It's a separate grant type that can be combined with either of the previous > types. > > > > > > > > Without full requirements we can’t design an extension point. Asking to > make this parameter a free text field is not helpful. > > > > The requirement is to allow another grant type, cookie. > > > > - cookie can be used separately or in combination with code or token. > > > > - if specified by itself or in combination with token, it's returned in the > End User Authorization Response, in analogy/in addition to the access_token > > > > - If specified in combination with code, it's returned in exchange for the > code, in analogy with the access_token > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but common > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduce > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting ** > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization grant. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I am > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn’t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedei...@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > The best approach (at this point) is to leave the spec unchanged. However, > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without sufficient > requirement. I also think that adding extension parameters can handle this > cleanly. > > > > The spec, as currently written does not imply that the only possible values > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usability > reasons, and require more frequent refresh requirements. In any case, there > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However, > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=code > > response_type=token > > response_type=code+token > > response_type=cookie > > response_type=code+cookie > > response_type=token+cookie > > response_type=foo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2.0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values or > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
