Single Sign On (SSO) is a mechanism that helps create the feeling of a single ecosystem across multiple services for the end user by sharing key elements of an identity. For customers, it is a delight, as it allows them to seamlessly log into multiple services with a single set of credentials. For the app, it is a conversion rather than a lead, without any friction. It is a win-win for all stakeholders.
Additionally, using SSO can result in significant cost savings. See the following example, using Hubdoc, a service that allows users to collect all their financial documents in a single location. Hubdoc uses SSO to integrate with QuickBooks Online, resulting in a smooth user transition from documents to their QuickBooks company.
Hubdoc subscribe from QuickBooks Online Apps Tab
Cost of user registration
A typical app developer might ask “What is so complicated about implementing a user registration system?” After all, that is the most common interview question. Here is a quick look at the costs involved:
- Password management: This includes the cost of coming up with algorithms around what constitutes a “strong” password. If the app also happens to be global, then it also includes how the algorithms vary across various UTF-8 characters.
- Multi-Factor Authentication (MFA): Consider how, these days, even large organizations are being hacked easily. It is imperative that users no longer depend solely on a simple username and password. This also assumes that additional mechanisms such as “Captcha” are implemented, to make sure that humans are the only ones registering, rather than bot accounts.
- Account recovery: While mechanisms like “Captcha” are great at filtering out bots, further security measures are needed to ensure only the rightful user can regain access to the account if they forget their password, etc.
- Lead-to-sale conversion: For every action that a customer must perform before they can get started using an app, there is a potential of drop-off. Try to optimize the account setup and integration flow to retain the customer all the way until the end of the process in order to have the best chance of converting that lead to a sale.
OpenID as SSO
While there are a wide variety of SSO frameworks out there today, this post focuses solely on OpenID 2.0, and touches upon the future of login OpenID Connect in order to identify it as a different protocol, even though the two names are very similar. Intuit uses OpenID 2.0 to implement SSO so the user can enjoy a seamless integration between the two services in use.
How OpenID 2.0 works at Intuit
First, a quick clarification on terminology: the “relying party” (the app) relies on the OpenID provider (Intuit) to provide the single sign-on experience.
- Relying Party (RP) – The app
- OpenID Provider (OP) – Intuit
The following example walks through a typical flow and discusses the various aspects of it. For additional details, please refer to the specification document here.
Refer to this diagram for a standard SSO flow:
- App wants the user to sign-up / sign-in; obviously, the app has to do something. This is the “request authentication” step.
- The app and Intuit will use the UserAgent (usually the browser) as a means of communication with the user in context. This is the “indirect communication” mechanism in the OpenID spec.
- But before the app can redirect to Intuit, the app should go to Intuit and get a temporary identifier for this request. This is to verify that a specific request is coming to Intuit from a known app. This is called “association handle“.
- Then the app can redirect the end user to Intuit with that handle and the requested parameters using “extension types“.
- Intuit will then have to get consent from the user.
- After gaining user consent, the requested parameters are returned along with the handle and a primary key called “openid_claimed_id”.
- The app can then redirect to this “openid_claimed_id” URL to get a valid XRDS document.
Here is how it appears on the wire
First, the setup:
- http://localhost:8011 – Where the sample app (or the Relying Party) is found. Source code for this is here on git.
- https://vm-openid.intuit.com – Where the OpenID server is, exactly similar to openid.intuit.com (the OpenId Provider, Intuit).
Step 1: App gets an associate handle
Done by the “initialize” function: here in the sample app.
POST https://vm-openid.intuit.com/OpenId/Provider HTTP/1.1 Content-Length: 355 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Host: vm-openid.intuit.com Connection: Keep-Alive openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=associate&openid.session_type=DH-SHA256&openid.assoc_type=HMAC-SHA256&openid.dh_consumer_public=db5AEcO7V%2BQHrCHe%2B4u693uUaC9CrVP6v8Kadkz6zb%2BtBhcZL6bFUFsJT9BXn4vNzCrxYNDARYhr8nsSY2CQkO%2FqicvsHnCdMBSV%2BADiNNjGIyfBBmGVrstcC7%2Bo7dSVt%2BnXN4rcbwKegDDm%2F%2FSkk%2F5RjmCCQ17njCiPqHdsD7s%3D
HTTP/1.1 200 OK Cache-Control: private, s-maxage=0 Pragma: no-cache Content-Type: application/x-openid-kvf path=/ Access-Control-Allow-Origin: *.intuit.com Date: Mon, 11 Apr 2016 23:33:06 GMT Content-Length: 507 dh_server_public:AKPzQ4bQ2NPhffJ+l4Mu3Wk5UVozrQjzklACgO43cq/UKOB3gmVmQ1VBHGDGst2VjmEDRgqXdqT6hkERYRUn0nFew+2xqGuXamjPtmK6Fgi0v0FzCuDVHEuF3+R9Rbm/ey4wENo0M3t9yRsGyyhK9/b5vJi74VhcpK2OFNYWYd6k enc_mac_key:bpSnSYfYQgoK5aqbOxZvZhMggtPfSLV4RQEpNErA8UY= assoc_handle:EP0i!IAAAAB68uD0k0zW2ySHYPVsvjCC-g8VcuEmmxcy472UZoaOxQQAAAAFvg6JpHlxBnq5x1udeXl4940HcHZVMmjJ5Af0LEMNSSaI_7anMoCTU9Ne5rX44ZN92izQmTjRHNCcBjRI3Uc9e assoc_type:HMAC-SHA256 session_type:DH-SHA256 expires_in:1209598 ns:http://specs.openid.net/auth/2.0
Step 2: App redirects to OP with the associate handle
Done in the “initialize” function: here in the sample app.