Need someone to lead product management at your software company? I build high-craft software and the teams that build it. I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

OAuth use case

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

Alex Barnett rhetorically asks, "OAuth is a big idea, but is it a 'solution looking for a problem to solve'?" and decides that end user problem is real. Here’s an actual use case for the problem and why OAuth solves it.

Deane got tricked by Shelfari when he let them check his Gmail contacts to see if any of them were already members of the service.

Shelfari offered to check his contact list to help him make the social service more useful. All he had to do was put in his GMail user name and password so Shelfari could see his contacts. He took the bait, and Shelfari used his juicy 900 plus member contact list as a way of virally distributing their service. They shot an email out, in Deane’s name, to everybody on his contact list. They made the email sound as if Deane was personally inviting you to join Shelfari.

In Deane’s comments, Dave says "What I don’t understand is what would possess anyone to ever provide their primary email account information to a third party service."

That’s sort of the point behind OAuth. With it, an application can define what activities a third party service can perform, and the end user can decide which of those they’d like to give someone access to.

Google could say that third party services could access your contact list in Gmail, mark items as Spam in Gmail, access your OPML file in Reader, and read your Adsense report data. A third party service named YASN (Yet Another Social Network) could build in OAuth support and ask for access to Gmail contact lists.

You come along and log into YASN, and they tell you they can check your contacts. You decide that sounds nice and you’re sent over to GMail’s site to log in. After logging into GMail, you get asked if you’d like to give YASN access to your contacts. You agree, and YASN gets an auth token they can use to see your contacts, and you end up back on YASN’s site with your contact list.

Later, YASN decides to use that auth token to buy some ads in AdWords—free advertising for them, courtesy of your wallet. But that Auth token doesn’t work for AdWords. Or for reading your email in Gmail. Or for anything else—just for reading your contact list.

You decide later that YASN isn’t for you, and you don’t want them seeing your contacts any more. You can now log into GMail and revoke that auth token they’ve got. Next time they try and get access to your contacts, they’ll be denied—that token isn’t any good now.

One thing about this particular problem of sites emailing your friends on your behalf is that they don’t actually need access to your email account to send email "from" you. That "from" line in your email program isn’t authenticated. You can put anything you want in there and the email will go out. So YASN can still take all your contacts and email them, sticking your name in the From instead of YASN’s.

One way to stop this would be for email providers not to hand over a list of your contact’s email addresses, but to hand over an anonymized hash of the email address instead. If Gmail were to publish in their OAuth spec that they’re going to provide an md5 hash of each email address, then YASN could create hashes of the email address of each of their users, and compare those hashes against the ones that Gmail provides. Now YASN can check for matches in your gmail contact list without having the actual list.

Recently Written

Think Systems, not Symptoms
Dec 15: Piecemeal process creation frustrates teams and slows work. Stop patching problems and start solving systems. Adopting a systems thinking approach helps you design processes that are efficient, aligned with goals, and truly add value.
Your Policies Aren’t Your Culture
Dec 13: Policies guide behavior, but culture is the lived norms and values of your team. Policies reflect culture -- they don’t define it. Netflix’s parental leave shift didn’t change its culture of freedom and responsibility. It clarified how to live it.
Lighten Your Process Burden
Dec 7: Everyone hates oppressive processes, but somehow we keep managing to create them.
Product Add-Ons Are An Expansion Myth
Dec 1: Add-ons can enhance your product’s appeal but won’t drive significant market growth. To expand your customer base, focus on developing standalone products.
Protecting your Product Soul when the Same Product meets New People.
Nov 23: Expand into new markets while preserving your product’s core value. Discover how to adapt and grow without losing your product’s soul.
Building the Next Big Thing: A Framework for Your Second Product
Nov 19: You need a first product sooner than you think. Here's a framework for helping you identify a winner.
A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.

Older...

What I'm Reading