Question

Can someone explain how these open ID systems work?

When a user redirects to the openid provider, and authenticates, what does the provider send back to the originating website? Is it some encrypted text that the website validates or does it have to actually communicate with the open-id provider to verify?

Answer 1

If you’re interested in all the gory details, you can check out the spec here.

On a high level though, it’s pretty simple (paraphrasing here from the 2.0 spec’s overview):

1. The site redirects the user to the OpenID provider, along with an auth request

2. The OpenID provider attempts to authenticates the user

3. The OpenID provider redirects the user to the site, along with information on whether the authentication failed or succeeded.

4. The site then verifies this information, checking some fields it got back from the response, as well as making a direct request (one that doesn’t go through the user’s browser) to the OpenID provider; all this is to prevent spoofing and the like

So steps one and two are pretty straightforward, but the latter two have some complexity. The response from step 3 in particular contains the “nonce” field, which will be unique to the request, and several fields that the site will then verify. This verification occurs in step four, where a few checks are made. Notably, the return URL and signatures.

Of course there’s a lot more going on under the hood, but if that’s the kind of information you’re after, the spec the best place to look.