Fwd: [Fwd: Less drafty: RFC 2617 for OAuth]

FYI.

Begin forwarded message:

> From: John Panzer <jpanzer@acm.org>
> Date: 28 August 2007 5:35:50 AM
> To: Atom Publishing Protocol <atom-protocol@imc.org>
> Subject: [Fwd: Less drafty: RFC 2617 for OAuth]
>
> Sorry -- sent wrong draft.  Please look at this one instead:
>
> (Would like to get feedback on this from the group; it's a proposal  
> to add RFC 2617 compatible auth[nz] to OAuth, an open replacement  
> for AuthSub/OpenAuth/Flickr API Auth/BBAuth/etc.)
>
>
>
> From: John Panzer <jpanzer@acm.org>
> Date: 28 August 2007 2:24:01 AM
> To: oauth@googlegroups.com
> Subject: Less drafty: RFC 2617 for OAuth
>
>
> All,
>
> Here's a draft that's worth banging on I think.  I'm attempting to  
> follow the current SVN spec for terminology.  There are a lot of  
> TBDs in the text below, and I'll send out some specific queries  
> about those when I have time (likely tomorrow).
>
> One thing that this proposal adds to OAuth is a discovery mechanism  
> that lets an SP declare where to send the user to dynamically in  
> order to obtain auth(nz).  This comes from the existing prior art  
> with OpenAuth and is I think a missing piece.  This is obviously  
> useful only to Consumers who have to deal with multiple Service  
> Providers of a certain type; but that's life in the AtomPub world,  
> where I come from.  Although Consumers need to pre-register  
> themselves and contain a table of (SP, Consumer Key, Consumer  
> Secret) tuples, this decouples the URLs of the Protected Resource  
> from the service used to grant access and keeps Consumers from  
> having to track these.  E.g., I can set up a resource on  
> x.blogspot.com but protect it using oauth.google.com.  Consumers  
> only need to be pre-registered with oauth.  (Also, SPs that don't  
> require pre-registration can be dealt with completely dynamically.)
>
> ---
> This section defines an RFC 2617 extension to support OAuth.  It  
> uses the standard Authorization and WWW-Authenticate headers to  
> pass credentials rather than using URL parameters.  All Consumers  
> SHOULD be able to supply an OAuth Authorization header as an  
> alternative to passing URL parameters.  Service Providers MAY  
> accept such a header and such Service Providers MUST signal  
> Consumers by returning the OAuth WWW-Authenticate header upon all  
> requests for the protected resource.  For the remainder of this  
> section, we assume that the Service Provider under discussion has  
> chosen to support this extension.
>
> Providing Credentials: The Authorization header
>
> Once a Consumer obtains a multi-use token for a service, it sends  
> the Authorization header in subsequent requests:
> Authorization: OAuth oauth_token="..." oauth_key="..."  
> oauth_nonce="..." oauth_ts="..." oauth_sigalg="..." oauth_sig="..."
> The parameters are as described in "Signing an API Request"
> For idempotent operations (GET, HEAD, DELETE in particular) the  
> nonce is optional (TBD: Challenge this)
> To reject a request that lacks appropriate credentials, the Service  
> Provider MUST respond with a 401 Authorization Needed response.   
> Such a response MUST include at least one OAuth WWW-Authenticate  
> header and MAY include additional WWW-Authenticate headers:
> 401 Authorization Needed
> ...
> WWW-Authenticate: OAuth realm="...", fault="...", url="..."
> The RFC 2617 auth scheme is OAuth (TBD: case sensitive?)
> realm denotes the scope of the authorization realm
> The fault parameter provides more detailed reasons for the 401  
> response and is extensible:
> "NeedsToken" indicates that the Consumer did not provide a token or  
> the token is invalid; this is the case when no Authorization:  
> header was sent.
> "NeedsConsent" indicates that the Consumer has a valid token, but  
> must obtain additional user consent
> "ExpiredToken" indicates that the token was valid in the past, but  
> has expired or been revoked
> "BadSignature" indicates that the oauth_sig the Service Provider  
> computed did not match that sent by the Consumer.  For debugging  
> purposes, it is RECOMMENDED that the Service Provider send back the  
> request string it used to compute its signature.
> TBD: Nonce reuse?  Unknown signature algorithm?  Signature failure?
> url is the address of a web page that the Consumer SHOULD present  
> to the user to obtain authorization or consent.
> In response, a Consumer SHOULD:
> Set or append an "oauth_cb=..." parameter to the url.  This sets  
> the Callback Endpoint URL for this request only; if not supplied,  
> it defaults to the static Callback Endpoint URL associated with the  
> given Consumer.  (TBD: The Consumer needs some way to pass through  
> its current state; it need not be a full callback URL, though that  
> is the most flexible option, but there does need to be an  
> additional standard oauth parameter for this.)
> Present the web page at url to the end user, for example by opening  
> a web browser or using a browser widget.
> Handle an invocation of the Callback Endpoint URL as described in  
> the Authentication section, steps 1-5, resulting in a Multi-Use  
> Token and Multi-Use Token Secret if successful.
> (TBD: Note that the oauth_cb can be a javascript: URL, or a custom  
> scheme if the destination Consumer is not a web service.  Or it  
> could be pointing to a local web server or perhaps other schemes to  
> get the token from point A to point B.  Whatever method is chosen,  
> eventually the Consumer will receive the necessary data.  The  
> second exchange of the single-use for a multi-use token should take  
> place using standard HTTP calls.)
>
> (TBD: We have no standard way for a Consumer to indicate what kind  
> of permission it wants from user for the given SP; we really need  
> at least the basics of this.  E.g., the user needs to know if I'm  
> just asking to read the data or if I'm asking to be able to write  
> or delete their data.)
>
> A Consumer MAY also include an empty, token-less OAuth  
> Authorization header on any HTTP request to inform a Service  
> Provider that it supports OAuth.  The Service Provider MUST then  
> respond with the appropriate WWW-Authenticate header for the  
> requested resource in the response.  For example, a Consumer could  
> inquire using HEAD and then adjust its UI if the Service Provider  
> supports OAuth.
>
> NB: Some intermediaries may silently block the use of WWW- 
> Authenticate or Authorization.  If a Consumer receives a 401 with  
> fault="NeedsToken" when it has supplied a fresh Multi-Use Token, it  
> SHOULD attempt to fall back to passing the token using a URL  
> parameter.  Only if the fallback fails should it assume that  
> authentication/authorization has failed.
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 31 August 2007 11:29:36 UTC