Really early draft, I'll go back and fix terminology, remove
redundancies, and add examples but my laptop battery is about to die
and I may not get to a power source for another couple of hours so I'm
sending this preview out. If you see something hugely substantively
wrong with this, please let me know. I'll send out a real draft
tonight or early tomorrow morning.
-John
----
Clients SHOULD be able to supply a token via an RFC 2617 OAuth
Authorization header as an alternative to using a URL parameter.
Servers MAY accept such a header as an alternative to a URL parameter;
servers supporting this capability MUST signal clients by returning the
WWW-Authenticate header upon all requests for the protected resource.
For the rest of this section, "server" means "server opting to support
RFC 2617 for OAuth" (tbd: need a better way to scope this)
Authorization: OAuth token="OAuthToken"
- OAuthToken is the base64-encoded token data obtained from
the OAuth service.
- TBD: ClientID as well?
To reject an HTTP request that lacks sufficient authentication or
authorization, the server MUST respond with an RFC 2617-compliant 401
Authorization Needed response. Such a response MUST include an OAuth
WWW-Authenticate header and MAY include additional WWW-Authenticate
headers:
401 Authorization Needed
...
WWW-Authenticate: OAuth realm="RealmURI",
fault="NeedsConsent",
url=""
- The RFC 2617 auth scheme is OAuth (tbd: case sensitive?)
- RealmURI denotes the scope of the authorization realm
- The fault parameter provides more detailed reasons for the 401
response
- "NeedsToken" indicates that the client did not provide a token
or the token is invalid
- "NeedsConsent" indicates that the client has a valid token, but
must obtain additional user consent via OAuth
- "ExpiredToken" indicates that the token was valid in the past,
but has expired or been revoked
- AuthURI is the address of a web page that the client
SHOULD present to the user to obtain authorization from the user
In response, a client should:
- Set or append the "&succUrl=..." parameter to the AuthURI.
The purpose of this success URL is to tell the OAuth service where to
redirect upon success of login or permission grant.
- Present the web page at AuthURI to the end user, for
example by opening a web browser or using a browser widget.
- Be prepared to handle an invocation of the succUrl with an
appended "token" parameter, giving a new token to use for subsequent
requests to the same server and OAuth realm.
(TBD: Note that the succUrl can be a _javascript_: URL, or a custom
scheme
(e.g., aim:) if the destination client is not a web browser. Or it
could be pointing to a local web server
(http://localhost:1080/openauthcallback.cgi)
or perhaps other schemes
to get the token from point A to point B. Whatever method is chosen,
eventually the client will receive an OpenAuth token that it can use to
try (or re-try) the HTTP request.)
A client MAY also include an empty, token-less OAuth Authorization
header on any HTTP request to inform a server that it supports OAuth.
The server MUST then respond with the appropriate WWW-Authenticate
header for the requested resource in the response. For example, a
client could inquire using HEAD and then adjust its UI if the server
supports OAuth.
Some intermediaries may silently block the use of WWW-Authenticate or
Authorization. If a client receives a 401 with NeedToken when it has
supplied a fresh token, it SHOULD attempt to fall back to passing the
token using a URL parameter.
|