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

William Denniss wdenniss at google.com
Fri Apr 3 23:29:16 UTC 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150403/7147bc4c/attachment.html>


More information about the Openid-specs-ab mailing list