[security] "AJAX"-style setups?

Martin Atkins mart at degeneration.co.uk
Wed Nov 1 18:20:03 UTC 2006


Johannes Berg wrote:
 >
> The draft says:
> 
>> While nothing in the protocol requires JavaScript or modern browsers,
>> the authentication scheme plays nicely with "AJAX"-style setups, so an
>> End User can prove their Identity to a Relying Party without having to
>> leave the page they are on.
> 
> At first I thought this was to imply that, for example, a RP could
> handle authentication inside of an (i)frame or similar and the user
> authenticates to his IdP in there, so never visibly leaving the RP's
> site. That, however, has the major flaw of not allowing the user to
> verify that the credentials she's entering are really sent to IdP. It of
> course would work when she authenticates to the IdP by way of an
> existing session cookie because that cookie would only be sent to the
> real IdP. But then again, except for showing a blank page for a short
> period of time this is the same when not using (i)frames.
> 

You are correct that this only works in the presence of an existing 
session and, for most IdPs, only if the user has allowed that site to 
authenticate without express permission.

The way you do it is to have an AJAX endpoint on your server and have 
the browser ask it to do an OpenID request. It then does the request as 
if it were the browser; two things can then happen:
  * The AJAX endpoint gets back a redirect to its return_url
  * The AJAX endpoint (acting as client) gets back some random web page, 
or a redirect some other URL that is not the return_to URL.

In the former case, it must then instruct the browser to send the user 
to the endpoint URL, and we're no longer using AJAX: authentication 
proceeds as normal.

In the latter case, the endpoint can parse the query string of the URL 
it got back in the Location: header of the redirect response and deal 
with it as if it had recieved this from the browser, sending an "Okay" 
message to the AJAX code on the browser.

In most cases, you're going to end up sending the user away to the IdP 
anyway, because most IdPs will not respond directly to the RP without 
user intervention.

(In OpenID 1.1 there is a special mode for doing the above, this special 
case is probably going to be removed in OpenID 2. I've described above 
the behavior in the absense of this special mode, but as far as the 
end-user is concerned the process is the same either way.)




More information about the security mailing list