Thanks to all that attended last week's webinar: OAuth: The Big Picture (slides and video here).
There were great questions - here are thoughts on those we didn't have time to discuss.
Q: Would you recommend only using oauth for passwords and usernames? What about more confidential items like card numbers? (John G)
I'm not sure I completely understand - but are you asking - if a user can authenticate to OAuth using a credit card number rather than a username/password?
That's theoretically possible but I'm not sure it's a good idea. Also, keep in mind that most credit-card...
We've implemented a couple dozen OAuth implementations in the past months, and no two have been the same. We've seen Oauth 1.0a (2-legged,3-legged), Oauth 2.0 (username password, user-agent, web-server flow) with custom token types (bearer,mac, saml). Just to name a few. We wanted to write some posts that discuss factors we see that drive these variances and their implications. We also want to compare and contrast each of these variances along with our own lessons learned.
We roll out big features with lots of fanfare, but the little ones roll out as they are ready. On Mondays we'll highlight recent changes here.
I've been posting a bit on OAuth best practices recently. But I want to take a step back and talk about why OAuth is important in the first place, why it's difficult, and how to think about it for your API.
Since we first wrote about OAuth 1.0 vs. 2.0 a while back, lots has been happening and lots has changed. The OAuth community has made progress and made changes, and an increasing number of API providers have deployed APIs that use OAuth 2.0. (Similarly, the number of new OAuth 1.0-enabled APIs doesn't seem to be growing.)
We've been busy helping our customers implement OAuth-based APIs, and we've also been watching the process develop. Here are some things that we've learned:
OAuth is a solution -- not technology.
In order for an API provider to support OAuth, a number of...
Part 1: The Web
In the beginning -- way back in the beginning -- the web was all about open access. Tim Berners-Lee and his colleagues focused on making information available, not on protecting it from unauthorized users.
But as time went on, and as Al Gore took the initiative in liberating the government-run Internet backbone for commercial use (really), the Web became about "e-commerce," and e-commerce required security. SSL matured to ensure that sensitive traffic was encrypted all the way from the client to the server and back, and various schemes emerged to allow user authentication.
In our last couple API strategy workshops, we've had good discussions on a common question for API providers - do you need to offer an SDK (software dev kit) for your API?
In this context we defined an SDK as going beyond offering an API to include platform-specific code that developers use in their apps to invoke API operations, also including the source code, and documentation that developers might need. Here's what we came up with:
Reasons to consider an SDK:
Speed adoption on a specific platform - for example Objective C SDK for iPhone. Lots of...