[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