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. Or should both be possible? What do you think?
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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Darren Bounds Sent: Thursday, 29 July 2010 6:29 AM To: oauth@ietf.org; pubsubhub...@googlegroups.com; federated-social-...@googlegroups.com 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:dbou...@cliqset.com", "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:dbou...@cliqset.com&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 dar...@cliqset.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
