Introduction
Is your website trying to integrate more closely with another web-site or web-service to provide a mashup of your different services to increase the value you provide to end-users? The industry has added a number of new techniques for these types of mashups that are allowing much better user experiences. The purpose of this document is to describe those techniques, and then to describe how OpenID can be used to improve some of them.
Techniques
Before we describe some of the approaches, lets use an example to help describe them. For that example, imagine you run an e-commerce site called CoolShoes and you want to add a user-commenting system. You could write your own basic one, or purchase software for a basic commenting feature. However instead you try to find a 3rd party commenting service that you can integrate into your website, and you find one called AddBlurb. Now the question is to do the integration.
The following is a list of approaches from least to most sophisticated.
backend-APIs: AddBlurb might expose APIs that the CoolShoes servers can call. But then CoolShoes has to build their own frontend on top of those APIs.
SAML: AddBlurb might offer the ability to run an instance of their service for each of their partners/customer-sites. CoolShoes can then run a SAML IDP to help your users get a single-sign-on experience to the instance of AddBlurb running on AddBlurb’s servers.
3-legged-OAuth: Maybe AddBlurb has a direct relationship with a lot of users, and so CoolShoes sees value in the brand association. When users want to add a comment, CoolShoes could send them through a 3-legged-OAuth dance with AddBlurb to get the user’s permission to access their data. However this has the same limit as #1 if only server-side APIs are offered.
iFrame widgets: AddBlurb might offer iFrames that CoolShoes can just embed which offer much more advanced UI functionality. However those tend to just be “boxes on the page” and it is hard for the rest of the CoolShoes page to interact with the iFrames, and visa versa.
OAuth widgets: This is a more advanced version of 3-legged-OAuth. AddBlurb might offer JavaScript widgets that CoolShoes can integrate with its page. The user can then integrate with their AddBlurb data both on CoolShoes and on AddBlurb.
OAuth single-sign-on: The OAuth widgets option still has some downsides when compared with the SAML option. In particular, if a single computer is used by multiple people, or by the same person with multiple accounts, then it can be very tricky for the user to be redirected back and forth between CoolShoes and AddBlurb without ending up in the wrong account. One way to solve this is for CoolShoes to get rid of its login system and just rely on the AddBlurb login system. This can technically be done using a small amount of code on top of OAuth.
OAuth + E-mail identifiers: The main downside of the previous option is that CoolShoes has to outsource its login system to a single company, and in many cases CoolShoes will not be willing to do that. In most cases though both CoolShoes and AddBlurb have users login with an Email address. So they could potentially just include a user’s email address whenever they are redirecting users between sites, or making server-server API calls.
OAuth + OpenID identifiers: The Email identifier approach is not very popular because it is too frail. For example, big webmail providers like Yahoo will reassign the same email address to another person if the first owner stops using it. Also, users might have a very strong password protecting their account at CoolShoes, but a really weak password protecting their account at AddBlurb. User and website operators of CoolShoes will get unhappy if hackers start to insert spam into CoolShoes by breaking into accounts on AddBlurb. An alternative is for BOTH CoolShoes AND AddBlurb to use OpenID for their login systems. For example, the current owner of sara@yahoo.com can use the Yahoo button on CoolShoes and AddBlurb to login. Anytime CoolShoes&AddBlurb want to redirect the user between sites, or make server-server API calls about her account, they can user her OpenID which is a global machine generated ID that will NOT be reused if the sara@yahoo.com account gets recycled by Yahoo and assigned to someone else. There is one other big advantage of this approach. Lets say Sara does not have an AddBlurb account but then signs up for CoolShoes. CoolShoes can make a server-server call to AddBlurb which can then provision an account for her. Later when Sara visits AddBlurb she can “claim” the account by using her OpenID from Yahoo to prove she is the same user. There are of course some user-interface and terms-of -service issues that the two websites might want to consider, but with the OAuth based approaches by themselves this is very difficult.
OpenID Identifiers
This section explains what we mean by an OpenID identifier. If you don’t know what OpenID is, then great, read this section. If you think you know what an OpenID identifier is, then its is even more important you read this section because the term OpenID gets thrown around in a lot of ways.
The term OpenID gets used in two ways:
OpenID protocol: A technical protocol for how one website (the relying party) can log a user in based on their identity at another website (the identity provider). The latest version of the OpenID protocol is OpenID v2.
OpenID identifier: The actual number/string/URL used by the identity provider to identify the user to the relying party
It is much less important to understand the protocol then it is to understand the concept of the OpenID identifier.
What makes an OpenID identifier special goes back to when the OpenID community was started. One of the key goals was to enable a single website (like CoolShoes) to support logins from multiple identity providers (like AOL, Yahoo, MSFT, etc.). That creates a problem. Lets say AOL’s internal system refers to user tom@aol.com as AOL user 13, and Yahoo’s internal system refers to the current owner of sara@yahoo.com as Yahoo user 13 (the previous owner of sara@yahoo.com was identified with a different number at Yahoo). Earlier login protocols like SAML would generally only send the internal identifier. That would mean that CoolShoes might treat sara@aol.com and tom@yahoo.com as the same person, and obviously that would be a mistake. So in OpenID the identity provider instead sends a URL to identify a person, such as aol.com/user/13 and yahoo.com/user/13. A site like CoolShoes can easily see that those are for different people.
There are multiple protocols that could be used to exchange an OpenID user identifier including SAML, OAuth, WS-*, etc. However OpenID v2 adds the extra security features to make sure that Yahoo cannot claim that the person logging in is aol.com/user/13, and instead can only make assertions about users from Yahoo. That type of feature could be added to other protocols, and probably will eventually be added to OAuth. A sophisticated relying party like CoolShoes could use protocols like SAML and OAuth to connect to multiple identity providers, but it is easy to get the security wrong, and it takes a lot of work to add additional providers. There are some vendors like Janrain, Ping Identity, Azure, etc. that offer web-services to add that type of logic.
Two sites & one OpenID identifier
Now that we understand an OpenID identifier, lets go back to our example where sara@yahoo.com has logged into both CoolShoes and AddBlurb using her identifier from Yahoo. In both cases she was identified using a URL that looks something like yahoo.com/user13.
If Sara is logged into CoolShoes, and they need to redirect her to AddBlurb, they can include a URL parameter (preferably encrypted) with her OpenID identifier. AddBlurb can then check to see if there is already a person logged into AddBlurb, and whether their OpenID identifier is the same. If they are, then great. If not, then AddBlurb can see if the owner of that identifier
Account is fully active at AddBlurb and the browser is logged into that account - This is the easy case where she is all ready to go.
Account is fully active at AddBlurb but the browser is not logged in - AddBlurb can then redirect the user to Yahoo’s identity provider and include Sara’s OpenID identifier. In most cases Sara will then be immediately (and invisibly) logged into AddBlurb. This is the same type of single-sign-on experience that SAML provides.
Account is fully active at AddBlurb but the browser is logged into a different account - The website could just logout the current user and then treat it as the previous situation. Or it could ask before logging the user out. More sophisticated websites might allow multiple accounts to be logged in at the same time would add a new session for Sara.
Account does not exist at AddBlurb - The website could just immediately redirect the user to Yahoo to get her consent to share her identity with AddBlurb. Or it might ask the user before doing that. In either case, once the user comes back from Yahoo, it can ask for any other information needed to create her account (like agreeing to a Terms of Service), and then she should be ready to go.
We used the term “fully active” account. So what does that mean? In an earlier section we gave the following example:
Lets say Sara does not have an AddBlurb account but then signs up for CoolShoes. CoolShoes can make a server-server call to AddBlurb which can then provision an account for her. Later when Sara visits AddBlurb she can “claim” the account by using her OpenID from Yahoo to prove she is the same user.
In this case, AddBlurb would create an account for Sara, but it would not be fully active. So that adds another potential state to the list of above:
Account exists at AddBlurb but is not fully active - AddBlurb will redirect the user to Yahoo to get her consent to share her identity with AddBlurb. Or it might ask the user before doing that. In either case, once the user comes back from Yahoo, it can ask for any other information needed to turn her existing account into a “fully active” account (like agreeing to a Terms of Service), and then she should be ready to go.
Once Sara gets into her AddBlurb account, she might notice there is already there that was pushed over by CoolShoes. Or there may be data that other AddBlurb uses claimed was about her where they used her email or OpenID identifier to refer to her. Depending on AddBlurb’s policies, she could now modify/delete that data.
Users without an OpenID Identifier
This model assumes that the user has an OpenID identifier. In the examples above, we assumed that their identity provider was the same as their email provider. That assumption does tend to make it easier for a website to be a relying party, however some user’s email providers are not yet identity providers. One option for those user’s is just to say tough, you can’t use the integration feature between CoolShoes and AddBlurb until your email providers adds that feature, or you switch to another email provider. Another option, though one that requires more work by the the relying party (CoolShoes in this case) is to allow users to pick an identity provider that is not their email provider. For more information about that technique, checkout Google’s OpenID Sample Store, and more importantly read the FAQ.