What is exactly is OAuth?

While I was still young and with enough energy, I liked to surf the internet and signup for a lot of services, that I thought would be useful for me later in life. Don’t ask me how far they took me if they did take me anywhere I probably won’t be writing this post from the corner of my room but somewhere less pleasing. The services I signed up for on important thing in common when trying to communicate with another website like Google and that is what this post is about. Well then with our introduction do, let’s dive straight into the ocean of Information Security.

OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication jargon, this is known as secure, third-party, user-agent, delegated authorization.
It was created and strongly supported from the start by Twitter, Google and other companies, OAuth was released as an open standard in 2010 as RFC 5849, and quickly became widely adopted.

The simplest example of OAuth is when you go to log onto a website and it offers one or more opportunities to log on using another website’s or service’s logon. You then click on the button linked to the other website, the other website authenticates you, and the website you were originally connecting to logs you on itself afterward using permission gained from the second website.

OAuth 1.0 vs OAuth 2.0

OAuth 1.0 was the first version of OAuth that was released in April 2010. After some reviews and suggestions OAuth 2.0’s main framework was published in October 2012 with provision for specific authorizations flows for web applications, desktops applications, mobile phones and smart devices. Google and Microsoft currently supports OAuth 2.0 as their recommended authorization mechanism for most of their APIs.

The Main Differences

OAuth 1.0 Flow

3. Client app signs all OAuth requests to Twitter with its unique consumer secret

4. If any of the OAuth requests is malformed, missing data, or signed improperly the request would be rejected.

OAuth 2.0 Flow

1. Client Application registers with provider such as Twitter.

2. Twitter provides client with a “client secret” unique to that application.

3. Client Application includes ‘client secret’ with every request.

4. If any of the OAuth requests is malformed, missing data or contains the wrong secret, the request would be rejected.

So how does this OAuth thingy works

Let’s assume a user has already signed into one website or service (OAuth only works using HTTPS). The user then initiates a feature/transaction that needs to access another unrelated site or service. The following happens (greatly simplified):

1. The first website connects to the second website on behalf of the user, using OAuth, providing the user’s verified identity.
2. The second site generates a one-time token and a one-time secret unique to the transaction and parties involved.
3. The first site gives this token and secret to the initiating user’s client software.
4. The client’s software presents the request token and secret to their authorization provider (which may or may not be the second site).
5. If not already authenticated to the authorization provider, the client may be asked to authenticate. After authentication, the client is asked to approve the authorization transaction to the second website.
6. The user approves (or their software silently approves) a particular transaction type at the first website.
7. The user is given an approved access token (notice it’s no longer a request token).
8. The user gives the approved access token to the first website.
9. The first website gives the access token to the second website as proof of authentication on behalf of the user.
10. The second website lets the first website access their site on behalf of the user.
11. The user sees a successfully completed transaction occurring.

OAuth is not the first authentication/authorization system to work this way on behalf of the end-user. In fact, many authentication systems, notably Kerberos, work similarly. What is special about OAuth is its ability to work across the web and its wide adoption. It succeeded with adoption rates where previous attempts failed (for various reasons).

Although not as simple as it could be, web coders seem to readily understand the involved transactions. Making a website OAuth-compatible can be done in a few hours to a day (much faster if you’ve done it before).

Related posts:

Good day my fellow deluded Arkies! The market may be beating us over the head with a shovel, but we won’t let that keep us down. The work must continue. There are things to be done! In case you…

A good book has the ability to impact and change lives for the better. Among the ones I’ve read so far, there were a few that struck a chord with me. So, I wanted to compile a list of books to read…

As NBA Top Shot collectors around the world eagerly await the first rare and legendary pack drops of Series 3, we’re faced with an abundance of common Moments and common pack drops. After months of…