XRD-Based OAuth Discovery Sneak-Peek

The new approach to OAuth discovery centers around the introduction the OAuth Provider. The OAuth Provider is the resource whose descriptor provides all the information needed to interact with the server and obtain a set of client and token credentials.

Find the OAuth Provider descriptor and you have everything you need. Please keep in mind that this is just an initial outline and that no code should be written yet according to this example.

Let’s jump right in…

The client tries to access the photo identified by http://photos.example.net/photo/1:

GET /photo/1 HTTP/1.1
Host: photos.example.net

And receives back an unauthorized response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm=”http://photos.example.net/”,
provider=”http://photos.example.net/oauth”

Note the new challenge parameter ‘provider‘. This identifies the URI of the OAuth Provider used by the protected resource. For the purpose of discovery, it doesn’t matter what the http://photos.example.net/oauth URI points to, but it is expected to be a human-readable documentation of the OAuth endpoints and configuration.

The client performs LRDD discovery on the OAuth Provider URI to find the location of its XRD descriptor, the same way explained in the OpenID example. Once the location has been identified, the client obtains the XRD document:

<XRD>
<Subject>http://photos.example.net/oauth</Subject>
<Expires>2009-12-31T23:59:59Z</Expires>

<Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type&gt;
<Type>http://oauth.net/example/ext/mobile</Type&gt;

<Link>
<Rel>http://oauth.net/core/1.0/endpoint/initiate</Rel&gt;
<URI>https://photos.example.net/oauth/initiate</URI&gt;
</Link>
<Link>
<Rel>http://oauth.net/core/1.0/endpoint/authorize</Rel&gt;
<URI>https://photos.example.net/oauth/authorize</URI&gt;
</Link>
<Link>
<Rel>http://oauth.net/core/1.0/endpoint/token</Rel&gt;
<URI>https://photos.example.net/oauth/token</URI&gt;
</Link>
</XRD>

The OAuth Provider XRD lists two global configuration types, one to indicate support for the HMAC-SHA1 signature method, and another to indicate support for the (made up) mobile extension. It then goes to list the three endpoints needed to perform the redirection-based flow described by the OAuth Core 1.0 specification.

That’s pretty much it.

I hope this time you agree that it is truly simple. What is still missing in this example is a way to express how an unregistered client can obtain a set of client credentials, but first we need an extension to define that flow before we can “discover” it. Also, this is where additional links can point to alternative token request methods.

3 thoughts on “XRD-Based OAuth Discovery Sneak-Peek

  1. If all your protected resources use the same OAuth Provider, then they should all just point to it. The OAuth Provider will have a single XRD. It is based on the OAuth Provider, not how many resources / APIs you have.

Comments are closed.