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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
