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

Breno de Medeiros breno at google.com
Sat Apr 4 00:17:52 UTC 2015


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/ef4d5fc7/attachment.html>


More information about the Openid-specs-ab mailing list