How Intuit Uses OpenID 2.0 to Implement Single Sign On

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:

  1. App wants the user to sign-up / sign-in; obviously, the app has to do something. This is the “request authentication” step.
  2. 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.
  3. 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“.
  4. Then the app can redirect the end user to Intuit with that handle and the requested parameters using “extension types“.
  5. Intuit will then have to get consent from the user.
  6. After gaining user consent, the requested parameters are returned along with the handle and a primary key called “openid_claimed_id”.
  7. 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:

Step 1: App gets an associate handle

Done by the “initialize” function: here in the sample app.


Content-Length: 355
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Connection: Keep-Alive


HTTP/1.1 200 OK
Cache-Control: private, s-maxage=0
Pragma: no-cache
Content-Type: application/x-openid-kvf
Access-Control-Allow-Origin: *
Date: Mon, 11 Apr 2016 23:33:06 GMT
Content-Length: 507

Step 2: App redirects to OP with the associate handle

Done in the “initialize” function: here in the sample app.

Be sure to read the next Authentication article: Stormpath Launches Client API for Frontend Registration and Authentication