OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
Johnny Bufu
johnny at sxip.com
Sat Nov 18 20:14:46 UTC 2006
On 18-Nov-06, at 6:26 AM, John Kemp wrote:
> Although I agree with you about the contents of RFC2616, I don't
> see why
> there is a need to restrict OpenID to requiring POSTs of HTML forms.
>
> It's both reasonable to have a redirect profile with HTTP GET
> (especially if it's possible to restrict the message size by
> specifying
> a minimum required message that will suffice) and also to have a HTTP
> POST redirect method (see SAML 2.0 HTTP POST/Redirect bindings [1] for
> one that is deployed). It's also possible to determine from the
> user-agent string whether you're working with a limited browser, and
> should use one thing or another.
POSTs are required so that there are no size limitation for the
parameters.
HTML forms is the method chosen to pass the data; the SAML HTTP POST
binding also seems to be using forms.
> My point is still that in general, implementations should be
> tolerant of
> limited user-agents, and that means supporting functionality that
> doesn't require JS.
JS is not required; this is stated in the third paragraph of the
'Abstract' section.
The 'HTML FORM Redirection' section says that "Form submission MAY be
automated using JavaScript".
>> I see that the "MUST NOT automatically" applies to all redirects:
>> 301, 302, 303 and 307 (sections 10.3.2, 10.3.3, 10.3.4, and 10.3.8 of
>> RFC2616).
>>
> Agreed. I'm not sure how many user-agents actually comply with this
> rule
> though, as POSTed redirects seem in general quite common, and in my
> experience anyway, seem to take place without my being asked whether I
> want to accept the redirect.
Still, we wouldn't want to architect a piece of the protocol to rely
on the non-conformance of other players with the HTTP protocol, no?
>> Not to the RP directly; the user-agent would receive the IdP's
>> response, but it wouldn't have a way of POSTing it to the RP.
>>
>> (The same applies to auth request messages, in the opposite
>> direction.)
>>
> The IdP would issue a 302 redirect back to the RP, through the user-
> agent.
The redirect URL would be the RP endpoint, but again I say that the
response payload never reaches the RP; it ends up in the user-agent.
Maybe you can provide an example (headers + body) of such a HTTP
redirect, which given in response to a POST will have the user-agent
POST the payload (the OpenID message) to the redirect URL (RP) ?
>> The content (IdP's response) never reaches the RP in this case; it
>> ends up in the user-agent.
>>
> Even if the IdP issues a HTTP 302 redirect, with the Location
> header set
> to the OpenID response endpoint for the RP?
Yes.
>>> As far as I can tell, HTTP redirects are already supported in some
>>> current (pre 2.0) OpenID implementations, so I'm still not sure
>>> what the
>>> problem is with allowing HTTP redirect implementations in OpenID
>>> 2.0.
>>>
>>
>> HTTP redirects work with pre 2.0 (and 2.0), but only with GET
>> requests and the parameters encoded in the redirect URL.
>>
>> I don't see how HTTP redirects can work with POSTs, which is why I
>> believe the solution was to use POSTs and HTML FORM redirection in
>> 2.0.
>>
> The SAML 2.0 HTTP POST binding may be used with the SAML 2.0 HTTP
> Redirect binding ([1]) to offer this functionality. I imagine it's
> possible for OpenID to do something similar.
I read the HTTP Redirect binding and HTTP POST Binding sections in
the document you referenced.
- The HTTP Redirect Binding passes the parameters around encoded in
the redirect URL (subject to size limitations), similar to OpenID's
HTTP redirect + GET method.
- The HTTP POST Binding uses HTML forms to pass the data (again
similar to OpenID's HTML FORM Redirection). Furthermore, the example
from the HTTP POST Binding contains the following:
<strong>Note:</strong> Since your browser does not support JavaScript,
you must press the Continue button once to proceed.
It is mentioned that the two methods may be composed, but I still
don't see how the POST form submission can be automated (without
JavaScript). Have I missed that part?
Johnny
More information about the specs
mailing list