It seems like not a week goes by where we don't read about another corporate hack or security breach. In the age of 'innovation by integration' and 'self-service data,' how can we be sure our usernames and passwords are safe when one system asks for our credentials to another system just so it can fetch some data for us?
What exactly am I talking about here? Well, as data integrations become easier and don't require IT to code and setup, business users are able to tie their applications together on their own using the credentials they already have. For example, to bring customer case data from my Salesforce account into my QuickBase project management app so I can better track what's going on in my customer engagements, all I need to know is my Salesforce login. Now, that's pretty powerful because it gives folks like us power to solve our own business problems, but the more applications that know our credentials, the higher our risk of being compromised.
Luckily some smart folks from Twitter, Google and the Internet Engineering Task Force have been thinking about this problem for a while. The result is a secure and standard way for us to give one of our applications access to another so they can share data. This standard is called OAuth, and it is increasingly used by our web applications, mobile phones and even our living room devices to help our apps talk to one another on our behalf.
OAuth is special because it doesn't require sharing our credentials with multiple applications. For example, to bring that Salesforce data into QuickBase, QuickBase doesn't need to know or store my Salesforce credentials. QuickBase is registered with Salesforce as a trusted consumer of Salesforce data, which means Salesforce knows and trusts QuickBase. Then, when I ask QuickBase to connect with Salesforce so I can get some data, QuickBase delegates the authentication process to Salesforce, who accepts and checks my credentials without me ever having to give them to QuickBase.
I don't want to go through this process every time I want more Salesforce data, so Salesforce gives QuickBase a special token, one defined only for use by QuickBase so it can't be compromised even if stolen, that allows it to access Salesforce on my behalf. Very convenient. But, what if something happens and I want to stop QuickBase from accessing my Salesforce data? Do I need to change my password? I don't know about you, but I don't like changing my passwords. Luckily, OAuth takes this into consideration. I can tell Salesforce to stop giving my data to QuickBase, and Salesforce will revoke this special token. If I change my mind, I can re-authorize my Salesforce connection and Salesforce will issue a new token. OAuth's got me covered.
QuickBase Sync, the data integration feature built into QuickBase, supports OAuth. Actually, it supports both versions of OAuth, OAuth 1.0 and OAuth 2.0. And, technically, QuickBase is an OAuth consumer, which means it uses OAuth by default to access a service provider like Salesforce when it also supports OAuth.
While many of today's applications support OAuth, not all do. When they don't, QuickBase Sync needs to store our credentials to the data service provider. Be assured, when QuickBase has to do this, our credentials are encrypted, secured and stored in Intuit's data centers protected by the same security and privacy controls as our QuickBase data.
So, how can I be sure my corporate credentials are safe when I want one app to talk to another on my behalf? Make sure those apps support OAuth, or be sure your credentials are stored securely, like in the same data centers that protect the nation's taxes!
Learn more about QuickBase Sync
Image courtesy of i0.wp.com.