Aaron Parecki

Now is your chance to join and ask me your OAuth questions!

The new draft spec at OAuth.xyz outlines a potential way to completely re-think OAuth from the ground up.

tl;dr This is a good move for users in the iOS ecosystem, and is primarily designed as an alternative for apps that currently use "Sign in with [Facebook/Twitter/Google]" to avoid leaking sensitive user info.

OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.

It's been a long time coming, but I've finally published a proper IndieAuth spec!

This evening, Tantek pointed out to me that while he was logging in to the wiki via IndieAuth.com for the first time on a new computer, there was something a little strange about the IndieAuth.com flow...

While OAuth 2.0 is a good framework for building an API, the spec itself leaves many things un-specified, and it's up to the implementer to make a decision based on their own security requirements. As such, most OAuth 2.0 implementations are not interoperable, which is often cited as a failure of OAuth 2.0. On the other hand, the current state of OAuth 2.0 implementations is that they are often similar enough that developers don't need to learn too many new concepts when dealing with them.

Back in the early days of Twitter, I noticed that several tweets I was seeing showed "via _____" next to the date, which linked to the application that was used to post the tweet. I thought "hey that's a clever way to give credit to applications" and thought it would be a good way to get people to discover the Twitter app I was creating at the time.

This post describes OAuth 2 in a simplified format to help developers and service providers implement the protocol.