Author: Denys Zherdetskyi

Millions of users daily use features that facilitate their work with web services. The companies implement them to make their websites easy to use and safe. Good examples of those are OAuth 2 and OpenID Connect because they allow them to reach it.

What we will cover in this article:

History of OAuth and flaws of prior methods
OAuth 2 and OpenID Connect (OIDC), and the differences between them
Purposes of OAuth 2 and OpenID Connect (OIDC)
Working principles of OAuth 2 and OpenID Connect
The practical example of OAuth 2 working principle with GitHub OAuth usage.

History of OAuth and flaws of prior methods

Users always prefer websites full of features that would facilitate their work website. In 2004, as we know, there weren’t any standards or protocols like OAuth 2 and OpenID Connect; that’s why even well-known companies like Yelp implemented them as they could.

This picture shows a screenshot from an old Yelp website showing us the Yelp feature “to find a friend.” You could say that it is cool till the time when you will see its implementation. You needed to give your email address and PASSWORD (!) to find a friend on Yelp because it would allow the service to log in as you and get emails you wrote often.

Some of you would say that it is insane and cannot be accurate; however, it is. In 2004, most internet users didn’t understand the basic rules that you should stick to in the “network” and could give all their data only to use a cool feature. We should notice that, luckily, on Yelp, no one was deceived, and it was the only way for developers to implement this feature at that time. However, through the years, users became more educated, so no one wanted to give their data to anyone without protection. Developers that noticed this security flaw decided to create a standard that would allow users not to worry about their data protection and use such services easily; that’s why the standard of authorization OAuth 1 was created. This standard still had some flaws, but it significantly shifted the security paradigm and allowed users to use cool features and not worry about their data. However, due to some problems of OAuth 1, like required cryptography, long-term living tokens, or complicated signatures, improved standard OAuth 2 was published in October 2012. It was created to solve all the problems of OAuth 1 and make using the OAuth standard easier and more secure.

OAuth 2 and OpenID Connect (OIDC), and the differences between them

As you already know, OAuth 2 is an authorization (!) standard. This standard’s work endpoint is an access token that allows us to manipulate or get users’ data.

Unlike OAuth 2, OpenID Connect (OIDC) is an authentication (!) standard. As you can see, the purpose of its usage differs from OAuth 2. Moreover, OpenID Connect (OIDC) is a standard built on OAuth 2. Developers of OIDC took the basics of OAuth 2 and expanded it with additional features that changed its shift on authentication from authorization.

As you read before, the main difference between these standards is the field of its usage (authentication or authorization). Some people don’t distinguish between authentication and authorization, which can cause faulty use of these standards in their projects.

Authorization is a process that gives the right to a website to access some users’ data or even change it if possible and needed.

Authentication is a process by which the website can ensure that you have access to be who you want to be and that you are not pretending to be someone.

Also, the significant difference is “party sides.” The authorization is the “third party” side, while authentication is the “first party” side. The difference lies in the purposes of these protocols. In authorization, you “authorize” someone to access and manipulate your data freely. You don’t participate directly in this process, so it’s named the “third party” side. In authentication, you prove to the website that you are someone, and it should or shouldn’t allow you to access some of your data. In this process, you participate directly; that’s why it’s the “first party” side.

Purposes of OAuth 2 and OpenID Connect (OIDC)

Imagine the website, where you would be able to see the alike subscriptions on YouTube with your friend. How would you implement this service? Of course, the best way and most secure way is to implement it with help of OAuth 2. Here we don’t need to know who the user are, or if he is, who he is or just pretending to be, however we need to access the user’s data, so receive an access to it. As we already know, this is a protocol of authorization and its endpoint is an access token. After receiving a token, the website can access only data, that we allowed it to access, so OAuth use is a brilliant way.

Most of the time clicking the button “Sign In with Social Network” on any website, you use OpenID Connect. If you don’t need any authorization, but you need only to “Sign In” or “Sign Up” you use the authorization with standard OpenID Connect (OIDC).

Working principles of OAuth 2 and OpenID Connect

To implement OAuth 2 standard on the website, the developer needs to get a client id and client secret from the service he uses ( for example, Google, GitHub, LinkedIn, Apple, etc. ). The process of OAuth 2 work is called authorization flow.

OAuth 2 is a standard that establishes the sequence of code commands that developers should write to implement the concept.

Authorization Flow

The user (Resource Owner) clicks the button “Login with ….”
Client (Developer’s website) redirects the user to a login service using a special link that consists of client id (always), scope, redirect URI (always), and request type (most equals to “code”).
The link redirects to the login service, where the user can sign in with “login service” or allow to use an already signed-in account.
After the sign-in account confirmation with “login service” (Authorization Server), it redirects the user to “redirect URI” (specified by the developer in a link), sending generated authentication code in the response body or “redirect URI.”
After receiving a code, the website sends a POST request or redirects to a link, usually consisting of the client id, client secret, and authentication code.
The developer should receive a generated access token for a particular user’s account if he did all the steps correctly.
After receiving an access token, the developer can send a POST request to “login service,” which contains a header with an “Authorization” field that equals the access token. Then after verification of the access token, the developer will be able to access data (for example, API or another allowed data).

The practical example of OAuth 2 working principle with GitHub OAuth usage

Now you will see a practical example of OAuth 2 implementation with “login service” as Github. To implement OAuth 2, developer should stick to rules established in paragraph below.

Firstly, we need to receive the client id and client secret; that's why let's register our app.
Enter https://github.com/settings/developers, log in to your GitHub account, and see a similar menu (shown below); click the "New OAuth App" button.

You'll see the form where we register our app and enter (imaginary URL).

Application name: MyApp
Homepage URL: http://myapp/
Authorization callback URL: http://myapp/callback

Then you'll receive a client id and client secret.

Then we create a link (paste all data WITHOUT SPACES, it's important), using our client id, that the user will receive after clicking the button "Login with GitHub."

https://github.com/login/oauth/authorize?client_id=your_client_id

Next, we will see the user's steps to authorize with "login service."

Paste the link below into the search line, and you'll see a GitHub login page (if you are not logged in). After account confirmation, you will be redirected to another link. The website is imaginary, and it is only an example, so you will not see a page, but you'll see the changed link in the search line, where "home page" changed to "callback" and generated access code before "?code=".

We have just received an authorization code, so the next step we need to obtain an access token.

We create a final link (paste all data WITHOUT SPACES, it's important) to receive an access token, so you need to fill it with your data:

client id
client secret
code (received during the prior step)

https://github.com/login/oauth/access_token?client_id=your_client_id&
client_secret=your_client_secret&
code=your_authorization_code

After entering this link into the search line, the txt file will download automatically. If you sticked to all the instructions and pasted all data correctly, you should receive an access token, otherwise you will receive an error.
Using this access token, we can access data using the following:

Application like Postman
Curl command In Terminal

In Postman, to access a user's data, you need to:

Enter https://api.github.com/user in the search
Choose the request method as "GET."
Open the tab "Headers."
Write in the first column "Authorization."
Write in the second column, "Bearer your_access_token."
Click "Send"

Then you'll see all user's data in the response body.

In the terminal, you need to use the "curl" command (shown below)

curl -H "Authorization: token your_access_token" https://api.github.com/user

What are OAuth 2 and OpenID Connect (OIDC)?