[Openid-specs-ab] Why did we require POST support for authentication requests?

John Bradley ve7jtb at ve7jtb.com
Sat Apr 4 00:02:41 UTC 2015


Are you taking AT as query parameters?   That was what we were trying to discourage people from doing.

I think the logic at the time was that webservers convert post parameters to key value pairs automatically so accepting form post would allow any server that takes AT as a query parameter to take it as a form parameter.

You seem to be be exception to that logic. 

Sec 5.3 of Core probably should have been:
The UserInfo Endpoint MUST support the use of all the methods defined in Sec 2 of RFC 6 <http://openid.net/specs/openid-connect-core-1_0.html#RFC2616>750 for receiving the Authorization token.

The right thing to do from a security point of view is really to depreciate both query and post methods of sending the AT.

I take your point that you accepting post but not taking a AT as a form parameter sort of sidesteps the underlying purpose of the test, and doesn’t really accomplish anything.

At his point I guess you have found a bug in the test if the test is not sending the AT as a form parameter.   

That is the only reason for us to be testing POST on the user_info endpoint.

Simply fixing the test is probably not in your interest though.

Making you support POST on the endpoint with no benefit is also silly.

Out of curiosity what percentage of OAuth access is query parameter for you in production?

I grant you that the spec is currently unclear on why that MUST is attached to the user_info_endpoint.

That is the sort of thing testing points out.

John B.

> On Apr 3, 2015, at 8:29 PM, William Denniss <wdenniss at google.com> wrote:
> 
> Sending the AT in a form-encoded body parameter is a MAY <https://tools.ietf.org/html/rfc6750#section-2.2> though, so if that's the only reason for userinfo requiring POST, then it probably should have been a MAY too.
> 
> We don't support ATs in a form-encoded body (as is our option), but are still compelled to support POST on userinfo to be OIDC compliant.
> 
> 
> 
> On Fri, Apr 3, 2015 at 2:58 PM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
> That is because at the time it was thought that not every client could use a header to send the AT.
> We were trying to avoid clients needing to send AT as query strings.
> 
> John B.
> 
>> On Apr 3, 2015, at 5:57 PM, Breno de Medeiros <breno at google.com <mailto:breno at google.com>> wrote:
>> 
>> Another interesting case is the mandatory POST support for userinfo endpoint requests. Given it's a read-only API it is an interesting choice.
>> 
>> On Fri, Apr 3, 2015 at 12:11 PM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
>> Our requests may be larger than OAuth only requests due to the extra parameters. 
>> 
>> It is also possible that some of them may be sensitive such as the id_token hint that is better in a body than a query parameter. 
>> 
>> For interoperability having the servers support both made it simpler for clients. 
>> 
>> John B. 
>> 
>> Sent from my iPhone
>> 
>> On Apr 3, 2015, at 3:15 PM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>> 
>>> Per http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest <http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest>, POST support is mandatory for authentication requests in Connect.
>>> 
>>>  
>>> 
>>> Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) <http://openid.net/specs/openid-connect-core-1_0.html#RFC2616> [RFC2616] at the Authorization Endpoint. Clients MAY use the HTTP GET or POST methods to send the Authorization Request to the Authorization Server. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization, per Section 13.1 (Query String Serialization) <http://openid.net/specs/openid-connect-core-1_0.html#QuerySerialization>. If using the HTTP POST method, the request parameters are serialized using Form Serialization, per Section 13.2 (Form Serialization) <http://openid.net/specs/openid-connect-core-1_0.html#FormSerialization>.
>>> 
>>>  
>>> 
>>> Per https://tools.ietf.org/html/rfc6749#page-25 <https://tools.ietf.org/html/rfc6749#page-25>, POST support is optional for authorization requests in OAuth 2.0.
>>> 
>>>       The authorization server MUST support the use of the HTTP "GET"
>>>       method [RFC2616 <https://tools.ietf.org/html/rfc2616>] for the authorization endpoint and MAY support the use of the "POST" method as well.
>>>  
>>> Does anyone remember why we went beyond the OAuth 2.0 requirements in this regard?
>>> 
>>>  
>>> 
>>>                                                             -- Mike
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>> 
>> 
>> 
>> 
>> -- 
>> --Breno
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150403/d10f27ac/attachment-0001.html>


More information about the Openid-specs-ab mailing list