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

William Denniss wdenniss at google.com
Sat Apr 4 00:27:12 UTC 2015


Incidentally, we do support POST on userinfo now (we enabled that to pass
the OIDC conformance test).  And I believe the tests for form-parameters on
userinfo were switched from errors to warnings to honor the MAYs in RFC6750.

On Fri, Apr 3, 2015 at 5:17 PM, Breno de Medeiros <breno at google.com> wrote:

> We attempt to ensure that our libraries always user the Authorization
> Header (and I think several of the 3rd party libraries do so) so a large
> percentage of integrations use Authorization header. Our documentation also
> highlights Header primarily, including in examples. However in our
> experience most 'hand-rolled' integrations use query parameter simply
> because it's easier. We do not block that for userinfo calls since we think
> the risk of leakage is not high (our endpoint is TLS-only).
>
> On Fri, Apr 3, 2015 at 5:02 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>> 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> 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> 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> 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>
>>>> 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
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>>
>
>
> --
> --Breno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150403/02dd4577/attachment-0001.html>


More information about the Openid-specs-ab mailing list