Re: [OAUTH-WG] OAuth & Protected feeds

[Torsten Lodderstedt <[e-mail]>]

James,
> This example illustrates that OAuth2 discovery needs to let a service
> explicitly indicate whether a direct and/or user-delegation flow is required.
> For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters:
> 'user-uri' and 'token-uri'. If only one is present, only the corresponding mode
> is useful in this interaction.
>    

In my opinion, this decision is up to the authorization server and not 
the resource server.

egards,
Torsten.

>
> Another interesting facet of this example is what token the app uses
> at step 4. Is it the token the app got in the first OAuth2 flow (step 1),
> or the token from the second OAuth2 flow (step 3)?
>
> Presumably the second token overrides the first.
> In this example, however, it may be sufficient to keep using the first token.
> OAuth2 doesn’t need to make returning a token mandatory -- it is not
> always required in a user-delegation flow.
>
> --
> James Manger
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Darren Bounds
> Sent: Thursday, 29 July 2010 6:29 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [OAUTH-WG] OAuth&  Protected feeds
>
> Please excuse the cross posting.
>
> Following the Federated Social Web Summit in Portland a couple weeks
> ago, there has been a lot of chatter around protected feeds and how
> they'll function to achieve SWAT0
> (http://federatedsocialweb.net/wiki/SWAT0)  Protected feed
> subscriptions are clearly an important component of DiSo and necessary
> for features like remote follow/friending.
>
> During the summit Brett Stlakin published and discussed a document
> (http://tinyurl.com/push-oauth) where he proposes one technique for
> how OAuth may be used with PuSH to achieve the requirements. The
> proposal details an OAuth 2 flow (in addition to OAuth 1x) for
> handling a usecase that involves ToS acknowledgement before a
> protected feed subscription may be granted. The flow is essentially
> the web server client profile combined with the assertion grant type.
> While the flow will work and achieve the goals it also has a
> fundamental need for a user-agent redirect, something that not all
> providers may desire or require.
>
> What I'd like to propose is a variant of the assertion grant type that
> would make the user-agent redirect optional. The goal here was to stay
> within the bounds of the current spec where ever possible. That said;
> it may be desirable to break this out into it's own client profile.
>
> The flow detailed below is using the OAuth 2 scenario described in
> Brett's document (http://tinyurl.com/push-oauth)
>
> 1) cliqset.com would like to request an access token from google.com.
> Sends a request with grant_type=assertion.
>
> Request:
> POST /token HTTP/1.1
> Host: google.com
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=assertion&assertion_type=http://webfinger.org/&
> assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ==
>
> The assertion value in the request is a Base64 encoded JSON string
> with two properties, uri and magic_signature. Example:
>
> {
>   "uri": "acct:[e-mail]",
>   "magic_signature": "asdlkklafsdjkldsfjlkj="
> }
>
> Response:
> HTTP/1.1 200 OK
> Content-Type: application/json
> Cache-Control: no-store
>
> {
>   "access_token":"supersecrettoken"
>   "precondition_uri","http://google.com/oauth/authorize?state=opaquevalue
>   "code","myrandomcode123"
> }
>
> The access token response introduces two new optional properties:
> precondition_uri and code
>
> The existence of a precondition_uri means the consumer will be
> required to redirect the user to this uri in order to complete the
> activation of the provided access token.
>
> The precondition_uri resource has the same characteristics of the
> OAuth 2.0 Web Server client profile with the ‘state’ property being
> used to maintain state between the assertion request and the user
> redirect. Successful acknowledgement of the precondition results in a
> 302 response with the code provided in the assertion response (see
> example below).
>
> The existence of a code is required upon the presence of a precondition_uri.
>
> If no precondition_uri is provided, the access token should be
> considered active and immediately usable barring any provider specific
> back-end authorization (e.g. user acceptance of remote follow).
>
> 2) access token received optional precondition_uri. Issuing user
> redirect to precondition_uri with redirect_uri.
>
> Request:
> GET /oauth/authorize?state=opaquevalue&response_type=token&client_id=acct:[e-mail]&redirect_uri=http://cliqset.com/callback
> HTTP/1.1
> Host: google.com
>
> User acknowledges the precondition. This could be any number of
> activities, including authenticating.
>
>
> Response:
> HTTP/1.1 302 Found
> Location: http://cliqset.com/callback?code=myrandomcode123
>
> 3) Subscription has been authorized. ToS has been acknowledged. Compete.
>
> The consumer is able to activate the access_token by confirming the
> code provided in the redirect.
>
> This flow offers what we feel are several significant advantages over
> the hybrid approach.
>
> 1) Redirection becomes optional and is only required when the
> precondition_uri is defined by the provider in the access token
> response.
>
> 2) For providers who require TOS acknowledgement, it enables
> additional flexibility in how they go about it. For example, if a
> provider only requires TOS acknowledgement on the initial subscription
> request by a given user, subsequent requests will not provide a
> precondition_uri.
>
> 3) It is also worth exploring this flow as a suitable and more
> flexible alternative to the traditional Web Server flow.
>
>
> Questions? Comments? Suggestions?
>
>
> --
> darren bounds
> [e-mail]
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>