Last year, as part of the lead up to "Scaling New Heights," I wrote an article titled, "QBO vs. QBD – An Application and Database Perspective," which featured several tables that differentiates the Safeguards and Limitations of QuickBooks Online and QuickBooks Desktop. Every ProAdvisor supporting either QuickBooks product line should be aware of these differences.
Scaling 2017 Look Ahead
In that article, and during last year's "QBO Errors" course, we discussed how the design of QuickBooks Online was streamlined so that the two APIs (Accounting and Payments) for QuickBooks Online could provide a simplified link to the open platform.
The whole concept was built on providing easier access to the data so that more and more integrated applications could work with QBO.
At the same time, Intuit's internal security measures related to access and application compliance were strengthened to insure conformity to a far greater level than ever was associated with the SDK for QuickBooks Desktop products.
While developers for years had access to QB Desktop data, it was a bit of a guess as if a developer fully complied with all the guidelines associated with product access. From a technical standpoint, the way that some developers chose to implement third-party applications via the SDK was severely lacking in terms of the "prescribed way."
Don't get me wrong, there have been plenty of really good SDK applications for QuickBooks desktop. But there have been some really problem applications as well, because developers took shortcuts, rather than strictly follow the SDK's step-by-step "QuickBooks Way."
One of the expanded concepts we'll talk about this year in my course for ProAdvisors supporting QuickBooks Online is the process whereby Intuit safeguards QBO data and helps insure developer compliance so that apps connecting to QuickBooks Online are less likely to create complications.
That entire process begins with the way apps "connect" to your QBO data.
OAuth
Intuit's strict approach to QuickBooks Online integration via the App Center connectivity routines was intended to preclude "problem applications" from mucking up your QuickBooks Online database.
In order to accomplish this, Intuit implemented, among other criteria, the use of the OAuth authentication standard for QBO. This requires authenticating applications to interact with QuickBooks Online to authorize permissions for each connection.
OAuth is an open standard for authorization that provides client applications with secure delegated access to server resources on behalf of the resource owner. It defines a strict process for resource owners to authorize third-party access without sharing their own credentials.
All third party apps registered with the Intuit App Center will have their own OAuth Auth credentials, because an app cannot be connected to QBO without being recognized as an OAuth app.
About now, you're saying, "But I know there are apps that work with QBO that don't appear in the App Center?"
That's true, in fact, you can even design and configure your own app to work with QBO. But you still have to "credential" that app via an Intuit developer account.
As part of the process of using either a credentialed application or establishing an app, the necessary OAuthClientID, OAuthClientSecret and CallbackURL data establishes the necessary credentials with which you can then connect to your established QuickBooks Online account(s).
Below is an example of a behind the scenes interface for an app that has configured the necessary connectivity standards:
QBO OAuthAppConfiguration
The OAuthClientID is configured to match with the consumer key in the app settings, while the OAuthClientSecret is configured to match to the consumer section. When the QBO account (which is standardized using what Intuit terms the Realm ID) has these associations, the app can connect.
Below is an example of the credentials associated with a third-party app connectivity to QuickBooks Online (for purposes of security the Realm ID associated with the QBO account has been redacted.)
QBO OAuth Credentials
Some app users, skilled in technical issues, may not wish to always use the "app" identities of the original developer. In such cases, they may want to substitute the OAuth credentials included in the app with their own OAuth credentials.
It's possible to accomplish this by creating and obtaining the OAuth client credentials, consumer key and consumer secret via an Intuit developer account.
So, if you're a ProAdvisor whose Yeti is the "technical mumbo-jumbo" associated with QuickBooks, know that I'm here to help you conquer your fears.
We will examine these concepts more deeply in a "frighten-away-the-Yeti" kind of way without frightening you away. Join me for the "QuickBooks Online Troubleshooting" course, which is being held Monday, June 5, at 1:30 p.m. (EST) during this year's "Scaling New Heights" conference.
I hope to see you there.
PS: If you haven't already registered for the conference, you can do via this link.