ok sounds good. But AFAIK "authentication required" is already the
meaning of status code 401. So why another error parameter?
regards,
Torsten.
Am 01.07.2010 23:54, schrieb Eran Hammer-Lahav:
That's where the error parameter will be (the only supported place in -09 for a
failed protected resource response).
EHL
-----Original Message-----
From: Torsten Lodderstedt [mailto:[email protected]]
Sent: Thursday, July 01, 2010 2:51 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; Justin Richer; [email protected]
Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re:
Versioning)
I essentially agreed, except in 3. the server should send back status code 401
with a WWW-Authenticate header.
regards,
Torsten.
Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav:
I think all servers must support the header. I don't think we can demand all
servers to support query or post parameters as that can conflict with their
existing namespace or architecture. I suggest we:
1. Make the "Token" scheme required in all resource servers 2. Allow
resource servers to support the URI query or response body 3. Specify
that when a request comes without the header to a server only supporting
the header, the server should respond with error=authentication_required
to inform the client this form of authentication is not supported.
EHL
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Marius Scurtescu
Sent: Thursday, July 01, 2010 12:48 PM
To: Justin Richer
Cc: [email protected]
Subject: Re: [OAUTH-WG] Versioning
On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer<[email protected]> wrote:
OAuth tokens as a form-encoded element in a post body? Yes. Keep
it.
Just curious. What use case would require that the access token is
put in the post body as opposed to an http header when accessing a
protected resource?
If nothing else, it parallels the use case of a GET-style query
parameter. It makes sense to have it be valid in both ways to allow
developers to put the token in with whatever other parameters
they're passing along. I've got plenty of use cases here for the
query
parameters: it's needed for cases where your client can't get any
deeper into HTTP than "hey go fetch me this URL".
You can still use query parameters with POST.
What use case says we shouldn't do POST parameters like that? A
server wanting to do early-dispatch of a request was brought up, but
that was only in the case of handling OAuth 1 and 2 simultaneously
as I understood it. If a server's going to be doing dispatch on auth
headers and query parameters already, it seems that it's got the
wherewithal to parse a form-encoded body, too.
Parsing the body is not trivial. Some filters do not have access to
it (apache mod_redirect for example), some frameworks will allow you
to access it once and then commit to a format, a decision that cannot
be made by a filter (in Java see ServletRequest: getInputStream vs
getReader vs getParameter).
Marius
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
