Introduction in OAuth

OAuth is an Authentication protocol this enables you, that (maybe your) a application can be integrated into a third party application. The nice one is, you must not share any secret certificate or key or password...

This here will be a maybe easy to understand introduction into OAuth.

The actors

There are three participants in the OAuth Flow.

• The user
• The consumer
• the Service provider

In this Example will the user called "Jimmy", Bitly is the consumer and finally Twitter the service provider So Twitter ensures that Joes twitter stream will be save, and no other can access it, except Joe. But Joe want's to add links from bitly, automated.

Let's go

Step 1 (The user tell what he want)

Joe (user): "Hey Bitly, I want that you add links to my twitter stream."

Bitly (consumer): "Wow fantastic! Let me ask for the access rights, please wait!."

Step 2 (The user get the permission)

Bitly: "Hey Twitter i have an user here, he want that I can adding post directly to his twitter stream. Can I get an nice cool access-token?"

Twitter (service provider): "Yes of course. Here is his token and secret."

The secret will be use to to avoid fakes. The consumer use this secret to sign the request. So the service provicer can verify then that the request will be come from a person that he can thrust.

Step 3 – (The user will be redirected to the service provider)__

Bitly: "Okay Joe. I will redirect you to twitter now, because you must approve my request by twitter. Please take this token for the transaction."

Joe: "Yes sir!"

Bitly redirects Joe to Twitter

This will be the ugly part. Let's consider that Bitly now will be a dubios corporation. He can open a browser windows that looks like twitter, but in reality it is a phishing page in which the company can store the password from Joe. So please keep attention that the redirected url will be really from (in our scenario) from twitter. Mostly you will identify this at the https certificate.

Step 4 – The User grant the required permission_

Joe: "Twitter,I want that you this request token approve, because it's from bitly"

Twitter: "Okay. But to be sure, you want really that Bitly can create posts in your twitter stream?"

Joe: "YES!"

Twitter: "Okay, you can no go to Bitly and tell him, that the request is now granted for the request token)

Twitter now mark the request token as "Granted", so that every access (signed with the shared secret) will be accepted-

Step 5 – The consumer get an accestoken

Bitly: „Twitter, can I change this token with an access token?"

Twitter: „Yes sure! Here they are, an access token and the secret for it"

Step 6 – The consumer accessing on the protected resource

Bitly: „Hey Twitter, I want to create post with this link on the Twitter-stream from Joe. Here is my access token"

Twitter: "Done!"

Conclusion

In this example there was not required to share any account data from twitter. Joe has only delegated the account, on a secure method, with OAuth. Joe can every time go into twitter and check the access and to avoid tokens. But this has no effect on other existing tokens.

So with this fact you will se, that set granular access rights. For example you can allow Bitly to post in the twitter stream, but get ready only access in LinkedIn.

#OAuth is not (at the moment) perfect!

OAuth is a good method so secure browser based applications and is a huge improvement against the HTTP base authentication. But there are some constraints and difficulties, especially on OAuth 1.0. Because it will not be so user friendly and the integration in native and mobile apps is not very well.

OAuth 2.0 is way newer and more secure version of the protocol. This will introduce different ways for web-, mobile- and desktop applications. It also introduce the Token expiration, requires SSL and also reducing the implementations complexity for the developer site. So give it a try.

When you use the OAuth? What was your first application? What do you think about OAuth? Write me in the comments below or give me general feedback about this.