I found when I started trying to put this into WWW-Authenticate header it ended
up with a lot of extensions and parsing. Link headers make sense to me in that
the client that needs to know where the authenticator for a site is can look at
the linking relationships, and a registry already exists for defining them
because we're extending the current model that pretty much fits.
We need to convey the same information no matter what we do.
As for error codes, I think that's orthogonal to the discovery information.
-bill
________________________________
From: "Manger, James H" <james.h.man...@team.telstra.com>
To: Eran Hammer-Lahav <e...@hueniverse.com>; William J. Mills
<wmi...@yahoo-inc.com>; OAuth WG <oauth@ietf.org>
Sent: Thursday, April 7, 2011 11:47 PM
Subject: RE: [OAUTH-WG] OAuth2 scheme
A WWW-Auth header is a server’s security statement about how to gain access.
A Link header is a server’s statement of a relationship to another URI.
I find the Links+WWW-Auth approach more complex, less intuitive, and not as
good a match for HTTP semantics.
Each WWW-Auth header in my approach is a standalone statement of a path the
client can take to gain access. When an OAuth2 flow is a possible path, include
a “WWW-Auth: OAuth2 …” response header.
Using Links+WWW-Auth requires interpreting a combination of headers.
draft-mills-kitten-sasl-oauth-01#section-7.2 has an example of a error response:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: BEARER realm="example.com"
Link: <https://login.yahoo.com/oauth> rel="oauth2-authenticator"
Link: <https://login.yahoo.com/oauth> rel="ouath2-token"
A Link header is a nice, clean, intuitive approach for delivering a static
token endpoint URI.
However, that is not actually what a client needs in an HTTP error response.
The client needs to know what to do next, in the context of this request and
the credentials it included. That is more dynamic.
Consider the error codes that Mike Jones & others want to standardise/register
across authentication schemes. They are needed to know which OAuth2 flow to
perform (eg try a refresh if the token has expired; redo user delegation if
more scope is needed).
Should the error code go in an OAuth2 Link header? That feels a bit strange. It
requires extra parameters to be defined for specific Link relations (possible,
but not as intuitive). No one has suggested this, though I think it is the
correct design if Links+WWW-Auth is used.
The other option is to put the error code in the WWW-Auth header for a specific
scheme. Which scheme? Every scheme for which OAuth2 could deliver a token now
needs to be modified so its error response can include OAuth2-specific details.
That is feasible for the Bearer scheme, but not generally. There is no WWW-Auth
header to put the error code in if, say, the TLS layer is used for client
authentication (eg TLS-PSK or TLS-SRP or …).
This might be a trivial issue if OAuth2 is only ever used with the Bearer HTTP
schemes – but it does illustrate a design flaw: one more unnecessary strong
coupling between the authentication mechanism and the OAuth2
delegation/authorization flows.
--
James Manger
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, 8 April 2011 12:04 PM
To: William J. Mills; Manger, James H; OAuth WG
Subject: RE: [OAUTH-WG] OAuth2 scheme
I agree that Link headers are much better fit for relaying discovery
information than a half HTTP authentication scheme. Overall, I find James’
proposal to be too complex and not intuitive to people familiar with existing
HTTP authentication schemes (it is novel and well thought, and it does work,
just not as most people expect discovery to).
EHL
From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
William J. Mills
Sent: Thursday, April 07, 2011 7:01 PM
To: Manger, James H; OAuth WG
Subject: 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.man...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
