OAuth 2.0: the protocol at the center of the universe
I am writing this article on the iPad Mini using the Editorial app. This app is connected to my Dropbox account and automatically synchronizes my work. When I come home I can continue editing on my computer where this file will be waiting for me in my Dropbox folder.
When I take and share photos using Instagram, I am able to cross-post them to my Facebook and Tumblr accounts. IFTTT automatically updates my LinkedIn status when I post on Twitter. When I am reading news using Flipboard I can comment and share on Twitter. Adobe Lightroom CC that I use for my photography hobby allows me to upload and organize photos on Flickr. These interconnected cloud apps use each other’s APIs without knowing my passwords.
OAuth 2.0 is at the heart of all succesful and secure cloud API mash-ups:
OAuth 2.0 defines a relationship between the authorization server, the resource server, the resource owner and the third-party application. Aaron Parecki does a great job explaining OAuth 2.0 flow.
You, as the resource owner, own your data stored on the resource server. A third-party app that you use requests authorization from you to access your data on your behalf. It directs you to the authorization server. The authorization server asks you for your credentials and consent to grant the app access to your data. The authorization servers redirects you back to the app. The app now has an authorization code it can use to get a token from the authorization server. Using that token the app can now operate on your data within the constraints you control. In this entire process you did not have to disclose your user name and password to the app.
I own the resources I stored in my Dropbox. I authorized Editorial to operate on my files in Dropbox. Editorial app itself is unaware of my Dropbox credentials. I can revoke its access to my files at any time through Dropbox settings.
As a resource owner you can manage which applications can access your data. Facebook has it under the Apps page in the Settings. Microsoft Office365 lets the domain administrator control what apps users can grant access to. The OAuth 2.0 specification leaves it up to the implementer to decide which third party apps can use the API.
Contrast this with how Mint connects to your bank account. They ask you to enter the credentials you use to access your bank into the app. Mint stores passwords on their servers and then uses them to authenticate into your bank on your behalf. Despite Intuit’s reassurances, this is a security breach waiting to happen. The reason for that is that each bank has proprietary API. A team of Mint engineers must come together to update integration scripts each time a bank updates their API:
Standard API can become a revenue driver if done right. George Collins and David Sisk, write for Deloitte University Press:
Public APIs are becoming a crucial business asset. A strong API strategy depends on openness and standardization. A support for the OAuth 2.0 specification is the first step towards a successful and secure API model.
This article was originally published at my "Cloud Power" blog with Computerworld on Nov 24, 2015
When I take and share photos using Instagram, I am able to cross-post them to my Facebook and Tumblr accounts. IFTTT automatically updates my LinkedIn status when I post on Twitter. When I am reading news using Flipboard I can comment and share on Twitter. Adobe Lightroom CC that I use for my photography hobby allows me to upload and organize photos on Flickr. These interconnected cloud apps use each other’s APIs without knowing my passwords.
OAuth 2.0 is at the heart of all succesful and secure cloud API mash-ups:
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
OAuth 2.0 defines a relationship between the authorization server, the resource server, the resource owner and the third-party application. Aaron Parecki does a great job explaining OAuth 2.0 flow.
You, as the resource owner, own your data stored on the resource server. A third-party app that you use requests authorization from you to access your data on your behalf. It directs you to the authorization server. The authorization server asks you for your credentials and consent to grant the app access to your data. The authorization servers redirects you back to the app. The app now has an authorization code it can use to get a token from the authorization server. Using that token the app can now operate on your data within the constraints you control. In this entire process you did not have to disclose your user name and password to the app.
I own the resources I stored in my Dropbox. I authorized Editorial to operate on my files in Dropbox. Editorial app itself is unaware of my Dropbox credentials. I can revoke its access to my files at any time through Dropbox settings.
As a resource owner you can manage which applications can access your data. Facebook has it under the Apps page in the Settings. Microsoft Office365 lets the domain administrator control what apps users can grant access to. The OAuth 2.0 specification leaves it up to the implementer to decide which third party apps can use the API.
Contrast this with how Mint connects to your bank account. They ask you to enter the credentials you use to access your bank into the app. Mint stores passwords on their servers and then uses them to authenticate into your bank on your behalf. Despite Intuit’s reassurances, this is a security breach waiting to happen. The reason for that is that each bank has proprietary API. A team of Mint engineers must come together to update integration scripts each time a bank updates their API:
When a financial institution updates their system, our engineers have to rewrite the script on our end to match so that we can continue supporting them. Typically, they are notified when this is going to happen and can get it updated pretty quickly. However, please open a ticket by filling out our Contact Mint form to make sure this is on their radar and they can get the script updated as soon as possible.
Standard API can become a revenue driver if done right. George Collins and David Sisk, write for Deloitte University Press:
Application programming interfaces (APIs) have been elevated from a development technique to a business model driver and boardroom consideration. An organization’s core assets can be reused, shared, and monetized through APIs that can extend the reach of existing services or provide new revenue streams. APIs should be managed like a product — one built on top of a potentially complex technical footprint that includes legacy and third-party systems and data.
Public APIs are becoming a crucial business asset. A strong API strategy depends on openness and standardization. A support for the OAuth 2.0 specification is the first step towards a successful and secure API model.
This article was originally published at my "Cloud Power" blog with Computerworld on Nov 24, 2015