OAuth & PKI for Dummies

I’ve been programming for a few years and I’ve heard of PKI and OAuth for a while. I’ve read about it in SSL certificates for servers and even installed certificates. I’ve signed many apps with certificates and I’ve granted access to many others for Facebook or Twitter interaction.

I’ve looked around for definitions or explanations lately and came up empty handed. So I’ve put together this article to not only explain it but to try and make sure I DO understand as much as I think I do and point out the parts I DONT!

What OAuth is and what isn’t!

It’s not a login replacement. Logging into apps is still dome through usernames and passwords as surely you’ve noticed. What it is, is a safer way to grant partial, more fine grain access to data.

Surely you’ve noticed how authorizing an app to access your Facebook asks for your consent to specific parts of your data and only some tasks.

Examples

Facebook and Twitter are probably the most common examples of a third party app requesting access to your data.

Ground Zero

Here is what the field looks like. A user, a third party app and a webservice with data. That app wants access to your data and boy is it gonna have to work hard to get it:

To do so it will resort to a secret handshake. A few actually…well it’s a whole ritual really. Let’s review something called encryption. We all had secret decoder rings, right?! That’s the foundation for simple or symmetric encryption.

Along comes PKI or Public Key Infrastructure for Encryption and it basically splits up the decoder ring into two rings. One is public and the other is private. This is basically what it looks like:

Take a look at these great videos for a better understanding of PKI:

The tennis ball & lego ones remind me of that riddle of how to get a chicken, a sack of seeds and a wolf across a river on a boat. You cross the chicken first, cause the wolf has no interest in the seeds. Then you take over the seeds but bring back the chicken. Now you take the wolf over while leaving the chicken alone. Finally you go back for the chicken!

Ok so how does this fit into OAuth? Well I think this is what happens:

The user runs the third party app which will try to talk to Facebook on his behalf. So it must first do a PKI dance to prove that IT (the 3rd party app) is speaking on the user’s behalf. To do so it uses a consumer key & consumer secret to gain an UN-authorized Request Token.

Now the user is presented with a Consent Form and if the user accepts, that token is now converted into an Authorized Request Token. I’m not sure if this requires another PKI dance but let’s say it does cause 3 is a nice number!

Finally, with that Authorized Request Token in hand, the 3rd party app makes a new request to the webservice for a shiny new Access Token which contains the specifics of what this 3rd party app Can and Cannot do! After this final PKI dance, that Access Token can be used to make API calls on the server.

I’ll post back with edits when I clear up the details!