I see 4 suggestions for discovery (getting details about the OAuth endpoints etc to client apps):
1. Include it as extra params when advertising authentication mechanisms. WWW-Authenticate: MAC realm="...", <any MAC-specific params>, auth_url="http..." I don't like this as it changes WWW-Auth headers for other auth schemes, which might be theoretically feasible for new schemes this WG defines, but is not really possible for other schemes. It unnecessarily binds the delegation flow to a specific auth mechanism up front. There is nowhere to put the info if a server support delegation, but doesn't use an HTTP auth scheme to exchange the resulting state from the authz server to resource servers. When we specify a new parameter it affects all other auth schemes as well. Do we really want a discovery spec adding params to the WWW-Auth header defined in the MAC spec? If you updated the discovery spec you would need to check every other auth scheme (past & future) for param name clashes. 2. Define a WWW-Auth scheme specifically for announcing support for delegation flows. WWW-Authenticate: OAuth2 realm="..." token_url="http..." auth_url="http..." This is my preference. The only downside is that there is no matching Authorization header (and it is more about authz than auth) so some feel it not how WWW-Auth is supposed to be used. I see WWW-Auth as accompanying responses when a better response is possible with more authentication -- and providing details about how to "improve" the authentication. Providing the info required to perform an OAuth delegation flow is a close enough fit in my mind. When a client app gets a 401, it looks at WWW-Auth headers to decide if it can continue. Orchestrating an OAuth delegation flow is a way to continue. 3. Define link relations. Link: <http://login.example.com/auth?> rel="oauth2-auth" This feels possible, but not ideal. Details about how to delegate is not quite a "relationship". There is probably more than a single URI that you want to specify, and a handful of other parameters. 4. Something else entirely, such a host-meta. I would prefer to offer discovery inline -- in the 401 response. -- James Manger ---------- From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, 8 February 2011 10:07 AM I'm a strong advocate of the Link approach, given that authorization information does not belong on the authentication headers. > ---------- > From: [email protected] [mailto:[email protected]] On Behalf > Of William Mills > Sent: Monday, February 07, 2011 2:50 PM > > OK. > > So then the question is the right way to communicate token endpoints. Is it > cleaner/preferred to have everything in the WWW-Authenticate header, or > to break things out so we're not stuffing a lot into those headers and > repeating outselves? So, all in one would be: > > WWW-Authenticate: MAC realm="somerealm" > token_url="http://login.example.com/token"; > auth_url="http://login.example.com/webauth"; > > Broken out might be: > > WWW-Authenticate: MAC realm="OAuth2" > Link: <http://login.example.com/token?grant_type=MAC> rel="oath2- > token" > Link: > <http://login.example.com/auth?.done=http://foo.service.come/blahblahbl > ah> rel="oath2-auth" _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
