Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning)

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 13:28:08 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:48 PM
> To: Justin Richer
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Versioning
> 
> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "William Mills" <[email-masked]>
Date: Thu, 1 Jul 2010 14:15:02 -0700

So does this mean that supporting multiple protocols ends is in conflict
with allowing use of POST parameters? 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Eran Hammer-Lahav
> Sent: Thursday, July 01, 2010 1:28 PM
> To: Marius Scurtescu; Justin Richer
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Support for query/body parameters 
> (Was Re: Versioning)
> 
> 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:
> 
> 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
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Marius Scurtescu
> > > 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
> > > 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 
> > 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

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 14:23:23 -0700

I think that works.

POST body support can even be moved to a separate spec, if anyone
really uses it.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 01 Jul 2010 23:50:50 +0200

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:
>> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer<[email-masked]>  wrote:
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 14:54:52 -0700

That's where the error parameter will be (the only supported place in -09 for a failed protected resource response).

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 2:51 PM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; Justin Richer; [email-masked]
> 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.
> 
> > 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
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Marius Scurtescu
> >>> 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
> >> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 02 Jul 2010 00:04:43 +0200

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:
>>>>>>> OAuth tokens as a form-encoded element in a post body? Yes. Keep
>>>>>>>                
>> it.
>>      
>>>>>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 16:22:22 -0700

Good point. No error required.

EHL

> Sent: Thursday, July 01, 2010 3:05 PM
> To: Eran Hammer-Lahav
> ok sounds good. But AFAIK "authentication required" is already the meaning
> of status code 401. So why another error parameter?
> 
> regards,
> Torsten.
> 
> > That's where the error parameter will be (the only supported place in -09
> for a failed protected resource response).
> >
> > EHL
> >
> >
> >> servers to support query or post parameters as that can conflict with
> >> their existing namespace or architecture. I suggest we:
> >>
> >>> 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
> >>>
> >>>
> >>>
> >>>>>> 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?
> >>>>>>
> >>>>>>
> >>>>> 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
> >>>>> 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.
> >>>>>
> >>>>>
> >>>> 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
> >>>>