Let's specify how API failures MAY be reported, in enough detail to enable the Consumer to act appropriately. There are several possible outcomes that a Consumer should probably handle differently; for example:
- request accepted and service performed: rejoice and move on - unsupported signing algorithm: try a different one, or inform the user that this isn't going to work - invalid timestamp: read the Service Provider's clock and try again with a fresh timestamp - expired token: get a fresh token and try again - invalid consumer key: try a different one
An HTTP response header could convey this information. Specifying another way seems harder, but worth a try.
It would be good if these were locale-independent, so that the Service Provider need not be internationalized.
> Let's specify how API failures MAY be reported, in enough detail to > enable the Consumer to act appropriately. There are several possible > outcomes that a Consumer should probably handle differently; for > example:
> - request accepted and service performed: rejoice and move on > - unsupported signing algorithm: try a different one, or inform the > user that this isn't going to work > - invalid timestamp: read the Service Provider's clock and try again > with a fresh timestamp > - expired token: get a fresh token and try again > - invalid consumer key: try a different one
> An HTTP response header could convey this information. Specifying > another way seems harder, but worth a try.
> It would be good if these were locale-independent, so that the Service > Provider need not be internationalized.
> What else might a Consumer need to know?
> How will this information be transmitted?
-- Chris Messina Citizen Provocateur & Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 IM: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private
So I am sending this after suggestions from the OAuth Extensions
session at IIW today. Basically the idea is to not reinvent some thing
new again. We already have a way of reporting errors in OpenID - so
why don't we use the same format in OAuth too.
In OpenID protocol, the error responses are clearly defined in the
spec for both direct and indirect responses.
If we just use the OpenID error response formats, all we need to
define in this extension are the values for the "error_code" param and
let the SP/OP/IDPs to provide additional information (what ever that
they think would be useful for trouble shooting) in the
"error"/"openid.error" params.
---------- Forwarded message ----------
From: "Chris Messina" <chris.mess...@gmail.com>
Date: Oct 5, 1:38 am
Subject: API failure handling
To: OAuth Extensions
Awesome! I cleaned up the formatting a little. Hope it helps some.
Chris
On 10/4/07, John Kristian <jkrist...@netflix.com> wrote:
So while thinking about how to use OAuth for Javascript Consumers, one thing I realized is that there is no way for the Javascript Consumers (even Flash Apps have the same problem) running inside browsers to read the HTTP headers in the response when the HTTP status code is not 200.
But on the other hand since we want to make use of the www-authenticate header when denying access with a 401 unauthorized HTTP response, may be we need to define another input parameter that indicates how the consumer wants to get the errors back. (for ex. return_error_in_response_body=1).
Thoughts ?
This would be a stopper for us because we need to support Javascript consumers for some of our AOL Open Services.
> So while thinking about how to use OAuth for Javascript Consumers, one > thing I realized is that there is no way for the Javascript Consumers (even > Flash Apps have the same problem) running inside browsers to read the HTTP > headers in the response when the HTTP status code is not 200.
> But on the other hand since we want to make use of the www-authenticate > header when denying access with a 401 unauthorized HTTP response, may be we > need to define another input parameter that indicates how the consumer wants > to get the errors back. (for ex. return_error_in_response_body=1).
> Thoughts ?
> This would be a stopper for us because we need to support Javascript > consumers for some of our AOL Open Services.
Blaine Cook wrote: > My understanding is that the error will always be returned in the body.
> On Thu, Jul 10, 2008 at 6:51 AM, Praveen Alavilli > <ppalavi...@gmail.com <mailto:ppalavi...@gmail.com>> wrote:
> So while thinking about how to use OAuth for Javascript Consumers, > one thing I realized is that there is no way for the Javascript > Consumers (even Flash Apps have the same problem) running inside > browsers to read the HTTP headers in the response when the HTTP > status code is not 200.
> But on the other hand since we want to make use of the > www-authenticate header when denying access with a 401 > unauthorized HTTP response, may be we need to define another input > parameter that indicates how the consumer wants to get the errors > back. (for ex. return_error_in_response_body=1).
> Thoughts ?
> This would be a stopper for us because we need to support > Javascript consumers for some of our AOL Open Services.
On Thu, Jul 10, 2008 at 10:57 AM, Allen Tom <a...@yahoo-inc.com> wrote: > Doesn't that mean that browser based JS consumers will require that the > response be in JSON?
I don't see why that would be a requirement. JSON is useful if you want to eval() the response into JavaScript variables, but you can also parse responses without any problem.
Also, how do browser based JS consumers protect their Consumer Secret?
They don't, but that's fine. SPs should treat JS consumer keys / secrets with roughly the same trust metrics as user-agent strings.
Yes - in fact custom response formats (json,xml,yaml, php, amf0/3, etc.) might be a useful feature too.
I don't think the JS consumers would even have a Consumer Secret. Probably the only possible option is to use the referer provided by the browser to make sure the token and token_secret are used from the same web site for which they are originally granted. The SP can also use a cookie if it wants to make sure the token and secret are used from the same browser instance. But again the security for such consumers is so low that the SP should anyway restrict the kind of access allowed for them.
On Thu, Jul 10, 2008 at 1:57 PM, Allen Tom <a...@yahoo-inc.com> wrote: > Doesn't that mean that browser based JS consumers will require that the > response be in JSON?
> Also, how do browser based JS consumers protect their Consumer Secret?
> Allen
> Blaine Cook wrote:
> My understanding is that the error will always be returned in the body.
> On Thu, Jul 10, 2008 at 6:51 AM, Praveen Alavilli <ppalavi...@gmail.com> > wrote:
>> So while thinking about how to use OAuth for Javascript Consumers, one >> thing I realized is that there is no way for the Javascript Consumers (even >> Flash Apps have the same problem) running inside browsers to read the HTTP >> headers in the response when the HTTP status code is not 200.
>> But on the other hand since we want to make use of the www-authenticate >> header when denying access with a 401 unauthorized HTTP response, may be we >> need to define another input parameter that indicates how the consumer wants >> to get the errors back. (for ex. return_error_in_response_body=1).
>> Thoughts ?
>> This would be a stopper for us because we need to support Javascript >> consumers for some of our AOL Open Services.
Praveen Alavilli wrote: > So while thinking about how to use OAuth for Javascript Consumers, one > thing I realized is that there is no way for the Javascript Consumers > (even Flash Apps have the same problem) running inside browsers to > read the HTTP headers in the response when the HTTP status code is not > 200.
To clarify, are you thinking about cross-domain JSONP-based JS clients which get nothing on a non-200 response? Those would not be able to see anything at all, not even a body, unless you return a 200 response. I think you need a slightly different protocol for dealing with JSONP.
> But on the other hand since we want to make use of the > www-authenticate header when denying access with a 401 unauthorized > HTTP response, may be we need to define another input parameter that > indicates how the consumer wants to get the errors back. (for ex. > return_error_in_response_body=1).
> Thoughts ?
> This would be a stopper for us because we need to support Javascript > consumers for some of our AOL Open Services.
On Fri, Jul 11, 2008 at 1:41 AM, John Panzer <jpan...@acm.org> wrote:
> Praveen Alavilli wrote: > > So while thinking about how to use OAuth for Javascript Consumers, one > > thing I realized is that there is no way for the Javascript Consumers > > (even Flash Apps have the same problem) running inside browsers to > > read the HTTP headers in the response when the HTTP status code is not > > 200. > To clarify, are you thinking about cross-domain JSONP-based JS clients > which get nothing on a non-200 response? Those would not be able to see > anything at all, not even a body, unless you return a 200 response. I > think you need a slightly different protocol for dealing with JSONP.
yes (a most common usecase for standalone gadgets - not container based like iGoogle that has an OAuth proxy). When you say slightly different protocol for dealing with JSONP, it's nothing more than adding couple new request parameters (one for indicating it needs errors in response body, format of the response - json/php/amf0/amf3/yaml and the other the jsonp callback). Everything else remains the same (no change to the Core spec). Am I missing anything that we need to consider ?
> > But on the other hand since we want to make use of the > > www-authenticate header when denying access with a 401 unauthorized > > HTTP response, may be we need to define another input parameter that > > indicates how the consumer wants to get the errors back. (for ex. > > return_error_in_response_body=1).
> > Thoughts ?
> > This would be a stopper for us because we need to support Javascript > > consumers for some of our AOL Open Services.
Is there a recommended way for Flash and cross-domain JSONP (script tag) consumers to make 2 or 3 legged OAuth requests?
Specifically, I'm interested in the case where the Consumer was already authorized as if it were a server based web application, but then runs in the browser as a JS/Flash type application that circumvents the XHR same-host restriction by either writing cross-domain script tags (javascript) or using XHR with crossdomain.xml (Flash).
Is there a recommended way for these hybrid server/browser consumers to natively call OAuth without leaking their secrets? Is this the scenario that John Kristian's Accessor Secret extension is supposed to solve? At the OAuth summit, there was mention of an Open Social Security Token that apparently a transient credential that is issued to the browser when the JS is loaded which maps to an Access Token.
>> So while thinking about how to use OAuth for Javascript Consumers, one >> thing I realized is that there is no way for the Javascript Consumers >> (even Flash Apps have the same problem) running inside browsers to >> read the HTTP headers in the response when the HTTP status code is not >> 200.
> To clarify, are you thinking about cross-domain JSONP-based JS clients > which get nothing on a non-200 response? Those would not be able to see > anything at all, not even a body, unless you return a 200 response. I > think you need a slightly different protocol for dealing with JSONP.
> Flash is another (complicated and changing) story; I'm not sure what the > latest capabilities are but there certainly are odd limitations.
>> But on the other hand since we want to make use of the >> www-authenticate header when denying access with a 401 unauthorized >> HTTP response, may be we need to define another input parameter that >> indicates how the consumer wants to get the errors back. (for ex. >> return_error_in_response_body=1).
>> Thoughts ?
>> This would be a stopper for us because we need to support Javascript >> consumers for some of our AOL Open Services.
> Is there a recommended way for these hybrid server/browser consumers
> to natively call OAuth without leaking their secrets? Is this the scenario
> that John Kristian's Accessor Secret extension is supposed to solve?
I am not sure how Accessor secret would help here. We are not just talking about JS consumers that have trusted server side components (the basic requirement of the Accessor secret extension) - we are talking about any simple JS Consumers (typically widgets that can be inserted on any web site) that do not have a server side component. Ex. http://dev.aol.com/aim/tutorials/add_blist_widget or even a Yahoo widget or a Mac Dashboard widget - that are all self contained. They don't need access to their own servers before acceesing user data from some where else.
That said I am not sure even if the Accessor Secret would really buy anything given that it's just pushing the problem from one place to other. Instead of SP now the Trusted server needs to make sure it exposes the access token, secret and accesor secret to it's own legitimate untrusted consumers. In your example in the old email thread even if there is an accessor secret, voyeur.example.org can make a server side call to the trusted component running on printer.example.com to obtain it's access token/secret and accessor secret right - unless printer.example.com is some how making sure the request is coming from it's own consumer (by checking the referer). And the problem with flash apps is that the referer header is not even available.
The security bar is so low for JS consumers that I don't think there can be anything done expect for restricting the access (scope, time, resources, etc.) and enforcing strict rate limits on the calls with potential use of some human check challenge methods like Captcha.
- Praveen
On Sat, Jul 12, 2008 at 5:31 PM, John Kristian <jkrist...@netflix.com> wrote:
> On Jul 11, 11:35 am, Allen Tom <a...@yahoo-inc.com> wrote: > > Is there a recommended way for these hybrid server/browser consumers > > to natively call OAuth without leaking their secrets? Is this the > scenario > > that John Kristian's Accessor Secret extension is supposed to solve?
>> So while thinking about how to use OAuth for Javascript Consumers, one >> thing I realized is that there is no way for the Javascript Consumers >> (even Flash Apps have the same problem) running inside browsers to >> read the HTTP headers in the response when the HTTP status code is not >> 200.
> To clarify, are you thinking about cross-domain JSONP-based JS clients > which get nothing on a non-200 response? Those would not be able to see > anything at all, not even a body, unless you return a 200 response. I > think you need a slightly different protocol for dealing with JSONP.
Do we really want another protocol to deal with client's invoking identity based web services because of the way they can (or can't) process the transport layer? In the current case of HTTP, OAuth is using the transport layer to return application level errors. It mixes application level errors with transport errors.
I really like Praveen's idea about an extension for supporting environments that can't process transport level errors. As he suggested, there just needs to be a couple of extension parameters and the existing specification will work fine. xoauth_error_in_body=1 -- if present or set to 1, this parameter means that the HTTP response code should be 200 and a http_code response parameter should be returned. Note that if a special header is being returned to signify authorization required, that header can be included in the body as well xoauth_response_format={json,xml,amf3,...} -- specifies the desired format of the response. If the SP doesn't support this format it should just return the data with the appropriate Content-Type value xoauth_jsonp_callback=... -- this parameter is unique to JSON and specifies the browser js function to call
It doesn't seem like the processing rules for dealing with these parameters are that complicated. They would be optional and it's the client that's triggering them. So, if the SP doesn't support a parameter, it can just ignore it.
In addition to JSON, XML etc., let's support the OAuth core format; I
mean percent encoded name value pairs. To encourage interoperability,
let's require support for at least this format, or some extremely
simple format. OAuth is more apt to be widely adopted if it can be
implemented with simple software. An XML parser isn't really simple.
On Jul 14, 2:23 pm, George Fletcher <gffle...@aol.com> wrote:
> xoauth_response_format={json,xml,amf3,...} -- specifies the desired
> format of the response. If the SP doesn't support this format it should
> just return the data with the appropriate Content-Type value
>> Praveen Alavilli wrote: >>> So while thinking about how to use OAuth for Javascript >>> Consumers, one >>> thing I realized is that there is no way for the Javascript >>> Consumers >>> (even Flash Apps have the same problem) running inside browsers to >>> read the HTTP headers in the response when the HTTP status code >>> is not >>> 200. > John Panzer wrote: >> To clarify, are you thinking about cross-domain JSONP-based JS >> clients >> which get nothing on a non-200 response? Those would not be able >> to see >> anything at all, not even a body, unless you return a 200 >> response. I >> think you need a slightly different protocol for dealing with JSONP. George Fletcher wrote: > Do we really want another protocol to deal with client's invoking > identity based web services because of the way they can (or can't) > process the transport layer? In the current case of HTTP, OAuth is > using > the transport layer to return application level errors. It mixes > application level errors with transport errors.
Hardly. Authentication & authorization are totally within the scope of HTTP. There is precedent and oauth should be scoped to mirror hoyle for those existing auth protocols. Saying that JS handling of oauth is broken is akin to saying JS handling of HTTP-Digest auth is broken.
Asserting that oauth is an application level protocol is erroneous. Resource access is application level. This isn't a SOAP request encapsulating a SAML assertion describing a failed SQL transaction. It's an HTTP auth protocol.
I'm not saying this isn't a legitimate problem. But we need to accept that this is javascript's fault, and create an encapsulation protocol. I guess this wouldn't really be better than xoauth_error_in_body, xoauth_response_format=json & xoauth_jsonp_callback params. So the important thing is that this "solution" is always called a hack, no better than the tantek box model hack or other frustrating/required workarounds.
> Hardly. Authentication & authorization are totally within the scope of > HTTP. There is precedent and oauth should be scoped to mirror hoyle > for those existing auth protocols. Saying that JS handling of oauth is > broken is akin to saying JS handling of HTTP-Digest auth is broken.
Fair enough; especially when modeled in a RESTful way. However, there are times when http-rpc makes sense and OAuth in this case is more of a "framework" layer (like WS-Security in the SOAP <Header>). If OAuth is being treated as a framework that the application layer is building on top of, then to me the "application space" is OAuth+Application and HTTP is the transport. I suppose it's some what arbitrary where the boundaries are drawn.
> Asserting that oauth is an application level protocol is erroneous. > Resource access is application level. This isn't a SOAP > request encapsulating a SAML assertion describing a failed SQL > transaction. It's an HTTP auth protocol.
True. I wasn't trying to assert that OAuth is an application level protocol, just that it is a framework for securing application level service calls.
> I'm not saying this isn't a legitimate problem. But we need to accept > that this is javascript's fault, and create > an encapsulation protocol. I guess this wouldn't really be better > than xoauth_error_in_body, xoauth_response_format=json > & xoauth_jsonp_callback params. So the important thing is that this > "solution" is always called a hack, no better than the tantek box > model hack or other frustrating/required workarounds.
Not just browser+javascript but other application environments that restrict access to HTTP as well (e.g. flash).
|
