Adventures with Inuit OpenID

Embracing Challenges and Assessing Security Risks in Intuit’s OAuth2 and OpenID Implementation

Here at Crafty Penguins, sometimes it’s good to go against the flow. We value challenging norms and finding the gems available in uncharted waters. Leaning into challenges is a core part of our ethos.

However, when it comes to standardized workflows for RFC-based protocols and standardized methods, this kind of opinionated thinking and design can become a security hole that creates opportunities for people to take advantage. After all, the standard is there for a reason, right?

Yes, I’m talking about the deviations of Intuit’s Oauth2 and OpenID implementation from the OIC standard.

Now, if you aren’t familiar with these protocols and how to implement them, Intuit has been graciously busy creating libraries in many different languages to try and make it easy for you to incorporate them into your awesome apps. This allows you to take advantage of the “easy button” authentication and access that OpenID promises to deliver in a very secure way.

However, if you step outside of the homegrown libraries written by the same people who wrote the backend implementation, you will be in for a world of surprise encounters and adventures, which could even prove costly from a security point of view.

Putting aside the maze of misleading error code responses which pop up when running through their “we know better” gamut and the documented non-standard way of endpoint publication, some very important security features are just plain missing.

Understanding the Role of the Nonce in Secure Authentication and Its Absence in Intuit’s Protocol

For example, the use of a nonce for security hardening is a significant improvement to the older auth workflows and its usage is well documented in the protocol definitions. But, Intuit, being Intuit, decided they had a better idea on how it should be implemented.

Nonce is designed to link an access code session with an ID token. This critical security component prevents 3rd party replay attacks. It can only do so if both sides of the exchange (provider and client) check that the nonce used to get the auth code is the same as delivered with the id token.

To simplify the example I am referring to, the protocol mandates that if your app’s original authorization request contains a nonce string, the provider is required to include this randomized string in the id token responses and in validation endpoint responses when it submits a validation request. The nonce code should only ever be known to the provider and your application server so it isn’t readily accessible to the user.

The spec contains plenty of methods on how this is achieved. There are strict definitions for each of the four workflow types. You can read about it [here], if you are so inclined.

The reasoning for this component is that you are trusting this token authority to tell your app that the token you have stored for this user is still valid and that the token was created for your app server only and should match the nonce code stored in the server session for that user.

This is baked into the code logic for every OpenID programming library designed to support the protocol.

Building an App with QBO API: An Insight into Unforeseen Security Challenges

We recently were building an app to leverage the QBO API. To my genuine surprise, the nonce code is omitted from Intuit’s token validity checking endpoint responses when requesting if an access token is good to use. It took a long tedious debugging session to figure this out.

It turns out, the absence of this is the topic of many support requests from users of the service.

It’s a clear deviation, and the fact that we had to build bridging logic in the base OIC python library around the validation logic indicates just how far off this is.

If using Intuit OpenID, there is no way to know if this user is a bad actor leveraging a replay attack. It’s fine for Intuit’s own web apps like QuickBooks online and TurboTax since they are both client and provider. But for your own app, you just cannot tell.

That said, we still wanted to use their QuickBooks online API. And if you want to use that, it’s a necessary step to use their Oauth2.

Choosing Self-Hosted Keycloak over Intuit: A Step Towards Enhanced Security

We originally considered using Intuit to authenticate our users since the target internal app was only used by staff with accounts, but this was scrapped after learning about this security flaw. Needless to say, our system is behind a self-hosted Keycloak installation which was a breeze to set up and configure. Oh, and yes, responses from the token validator endpoint provide a matching nonce.

Final Thoughts: The Importance of Adhering to Authentication Standards for User Protection

In conclusion, I could not recommend, in good conscience, using the green Intuit easy button if you want to authenticate users for your app. Stick to other options that respect the standards and protocols put in place to protect user information from getting into the wrong hands.