views:

24

answers:

2

I thought I understood how Open ID works, but now I'm confused...

FYI, I'm not trying to understand how to use Open ID as a developer, but rather the actual actions it uses to authenticate via the client's browser.

As I understood, the user (for example) choose Google as their Open ID provider. The server then requests a pre-determined URL provided by Open ID third party. This request is sent via the client's browser and the response is returned to the server. If response equals "signed in", the user is unaware of any of the activity on his browser other than getting to a "welcome back" page on the main site. If response equals "no one signed in", the browser opens a new window with a log in screen for the third party.

So how does the Open ID log-in page actually send the request to the third party to get the response? Does the request need to always initiate via client-side script, i.e. javascript/ajax, or can requests be pushed from the server to the browser without any javascript at all?

+2  A: 

I suggest you read the spec.

In short (this isn't entirely accurate, but most of the flow is there) the relying party (aka RP: the site the user is trying to log into) constructs a URL that contains a message the RP wants to send to the OpenID Provider (OP), which describes the RP itself and what kind of login it wants the user to go through. The RP sends a 301 Redirect message to the browser so the browser will be directed to this URL that the RP constructed. The browser will send that URL to the OP, so the OP gets the message. The OPs response to the browser will either be an HTML page so the user can log into the OP, or a 301 redirect of its own with a carefully crafted URL that sends the browser back to the RP with a message telling the RP "yes, this user is logged in as x".

The RP verifies that the message from the OP is geniune either by verifying a signature the OP included in the message using a shared secret between the RP and OP, or by sending a direct HTTP message from the RP to the OP asking "did you send this?"

Notice that AJAX or any form of scripting is not involved here.

Now, in some advanced scenarios AJAX can be used, but in all cases the overall flow of information between RP and OP and browser is the same. It's just a matter of whether some of those "redirects" take place in hidden iframes via Javascript or not. And the hidden iframes will of course fail if the user hasn't authorized the OP to automatically log the user into this RP in the past.

Andrew Arnott
I was just thinking "I should read the spec more carefully" before I saw your response. Thank you! Re-directs, pre-authorization, hidden iFrames. These are the components I was not getting at all. I thought everything was happening server-side via some pre-built libraries and that the server was somehow talking straight to the browser. I definitely am still lost on the real-world version, but this is a great start.
Anthony
+1  A: 

The openidenabled library actually spits out a very simple html page consisting of a form with some javascript to auto submit the form and redirect. When javascript is not in use, the form is printed out and a user can click a submit button.

jmoz