Is OpenID too complicated?

Question

I'm beginning to seriously doubt the OpenID community despite that fact that it works.

I'm in the process of currently evaluating OpenID as an authentication service for 'this' site and while the promises are great, I just can't get it to work. And I'm really lost.

I ask of the SO community to help me out here. Give me answers and show me examples so I can leverage this in the way it was meant to be.

My scenario is very typical. I want to authenticate users through a specific Google Apps domain. If you have access to this Google Apps domain, then you have access to my web application.

Where I get lost, is all the prerequisites and dependencies involved.

1. What is XRD?
2. What is Yadis?
3. Why do I need XRD and Yadis?
4. What do I need to do to deploy OpenID authentication on my website?

Also, this is really important to me.

When I login to SO, I use my Google Account. When I click the login button I'm presented with this confirmation page. Where I'm granting SO the right to use my Google Account credentials.

Somehow, Google knows that it's "Stackoverflow.com" that's asking me if it's okay to login. And I wish to know what manner of control I have over this little text. I intend to deploy OpenID on several different domains but I would prefer if they would all work without having to be individually configured with special parameters, such as secret API keys and what not. However, I don't know for sure if this is a prerequisite of OpenID, that or the Federated Login API that Google provides.

Answer 1

It sounds like you really want to investigate RPX - it's a solution that makes it easy for developers (and users) to use their preferred authentication mechanisms, including OpenID.

Working as a proxy between third party identity providers and your website, RPX helps you effortlessly authenticate users with their existing account on Facebook, Google, Yahoo!, Twitter, MySpace, AOL, Windows Live/MSN/Hotmail, or any other OpenID provider.

Answer 2

To actually answer you question (i.e. disregarding all argumentative points) I'm as-we-speak using DotNetOpenAuth to implement OpenID authorisation for one of my sites; and it's been quite trivial.

It's just a .NET control you drop it, configure a tiny amount of things, and then let it link to Forms authentication. Quite nice.

Answer 3

Okay, you've got a lot of questions under one header there. Let me see if I can break it down.

XRD and Yadis:

"Yadis" was the name for the service discovery chunk of OpenID -- the bit that gets you from "my OpenID is example.com" to "the authoritative server for my OpenID is at openid.example.com/server and it supports v2 with AX extensions." XRDS is the XML schema that holds that information.

(The fact that OpenID (a standard we developed through no recognized standards body) depends on XRD (from another work-in-progress standard in an entirely different standards body) is perhaps regrettable. All I can say is that it seemed like a good idea at the time.)

"What do I need to do to deploy?"

See Joseph Smarr's A Recipe for OpenID-Enabling Your Site. Holy cow, that's 2+ years old already? It's still relevant, however.

How the OpenID provider identifies your site (the relying party):

That little text (e.g. "stackoverflow.com") is the OpenID "realm", which is a parameter you pass to the provider and is a strict subset of the endpoint URL you use to process their response. (So if you tell the server to send the OpenID response to server2.example.com/foobar, your realm can be example.com, or server2.example.com, or server2.example.com/foobar, but not server99.example.com.)

Secret API keys:

In general, there is no out-of-band secret API key to obtain. For general-purpose OpenID providers, keys are just issued through the standard OpenID association mechanism.

Now you've hit upon some features here which an OpenID provider might certainly consider valuable -- like "how can I tell the user in a more user-friendly way what site they're logging in to than showing them a URL excerpt" or "how can I identify this request is really coming from an RP I have some sort of contractual relationship with", but such features are not anything that's in the OpenID 2.0 standard.

Answer 4

I've actually found a solution to my problem, and surpsingly so, it was very simple. I still don't understand XRDS and Yadis but I'm leveraging it quite easily like so.

What you want, and what you're looking for is code for doing the OpenID "relaying party" stuff. That's "you" as a consumer of OpenID providers. You enter an OpenID endpoint and voila, you've OpenID enabled your site, this code illustrates that in practice.

// using DotNetOpenAuth
var openid = new OpenIdRelyingParty();
var response = openid.GetResponse();
if (response == null)
{
    // Google account end point (works fine)
    var googleID = "https://www.google.com/accounts/o8/id";
    // Google hosted account end point
    //  https://www.google.com/accounts/o8/site-xrds?hd=mydomain.com
    // I was unable to test this, but I was running my RP (this code)
    // from localhost and it's quite possible that a hosted account RP
    // has to return to the same domain.
    // It went fine, but crashed with a "Unable to resolve mydomain.com" error
    // once I logged in.
    openid.CreateRequest(googleID).RedirectToProvider();
}
else
{
    switch (response.Status)
    {
        case AuthenticationStatus.Authenticated:
            // Success
            // to allow persistance across sessions
            // you'll have to track the "claimed identifier"
            // some OpenID providers allow you to get an email address through
            // extensions but this is not always possible.
            // the claimed identifier is typically your safest bet
            // and it's a big URL which uniquely identifies the guest
            // as a specific user, however, you know very little about this user
            // which is a good thing becuase you don't have to give out personal or
            // sensitive information to start using a service.
            break;

        default:
            // Something went wrong, check Status property
            break;
    }
}

While I was figuring this out, I got the impression from every spec. out there that I was supposed to host my own "OpenID provider" that made it sound like I was supposed to handle accounts or some part of the process. In reality all I had to do was this.

Request that URL, or if you recieve a OpenID request in response. Check to see if that request contains valid login information.