Re: [OAUTH-WG] OAuth2 scheme

In the SASL mechanism draft spec where we went with that is to use LINK headers.  See http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01 if you want to take a look.  WWW-Authenticate headers return the supported authentication schemes and LINK headers tell you there are OAuth endpoints you can interact with.

It's a swag at discovery in band, might work here too.

________________________________
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: OAuth WG <oauth@ietf.org>
Sent: Thursday, April 7, 2011 6:48 PM
Subject: Re: [OAUTH-WG] OAuth2 scheme

We should define a “WWW-Authenticate: OAuth2 …” response header – not to encompass the MAC, Bearer, and any other generic HTTP authentication scheme, but as a way for a server to tell the client that it can perform an OAuth2 get-a-token flow to gain access. When the sort of OAuth2 flow depends on the error with a current token (eg expired vs invalid) then the “WWW-Authenticate: OAuth2 …” response header needs to reflect this. It could do so be including an error code. A better, more direct, approach is to explicitly identify “refresh flow” and/or “user-delegation flow” and/or “assertion flow” etc.

Bearer or OAuth2 WWW-Authenticate response header?
The rule should be:
#1. If the client can fix an error by sending an “Authorization: Bearer …” request header (or the query or POST alternative) then the server should return “WWW-Authenticate: Bearer …”.

#2. If the client can fix an error by performing an OAuth2 flow at an authorization server then the resource server should return “WWW-Authenticate: OAuth2 …”.

The server can return both response headers if both options are possible.

There is no point in re-presenting a rejected Bearer token so #1 isn’t that useful. It could be appropriate if no token was presented as the client might have a token, but didn’t know this resource needed it. It might be appropriate if a client presented a token with insufficient scope as the client might have another token with the right scope so “WWW-Authenticate: Bearer scope=…” could help. #1 is not really necessary when a presented token is invalid or expired as the client needs to get a new one (eg using an OAuth2 flow that is outside the scope of the Bearer scheme).

I don’t think an error code in a “WWW-Authenticate: Bearer …” response helps a client retry the request with a “Authorization: Bearer …” header that will work.
An error code might help a client choose the right OAuth2 flow (eg refresh vs new user-delegation) so it might have a place in #2, a “WWW-Authenticate: OAuth2 …” response header.

Eran said to Mike:
> Alternatively, if you have use cases or requirements for introducing just the WWW-Authenticate side of an OAuth2 authorization scheme (your open issue), which includes an ‘error’ attribute for use with the proposed registry, please present those and explain how it will work alongside the Bearer and MAC schemes (as currently drafted).

The “discovery” use-case in this email warrants the WWW-Authenticate side of an OAuth2 scheme.
An error attribute (plus a registry) might help, but we need the rest of the details of the response header first.
It works well alongside Bearer and MAC schemes: a “WWW-Auth.: OAuth2” response points to OAuth2 flows the client can try; a “WWW-Auth.: MAC/Bearer” response points to retrying a request with “Authz: MAC/Bearer”. Even when a client is given multiple options it will know which to choose based on its context (eg if it doesn’t have another Bearer token it will ignore the “WWW-Auth: Bearer” response and follow the “WWW-Auth: OAuth2” response).

--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth