An Intro to OAuth with a real-world example.
I'm sure at some point in time, every developer has written a demo login application.
We all start with the simple user-defined ID and password. We then try to implement something like a social login as seen in the above cover picture with say Google or Twitter.
There is obviously a more complex process involved in setting up a social login but for a user it’s as simple as clicking a button to log in.
The ease of not having to remember an ID/password and just being able to signup/login with a click of a button is extremely beneficial to the user.
Social Logins are More Secure😉
Social logins help us achieve the following:
- Support for multiple devices;
- Single Sign-On;
- Simple to implement;
- The ability to share data for users without having to release personal information;
- Ability revoke an active session i.e not allow third-party access to the login and data;
- There are no long-lasting credentials being exchanged.
So What Drives This Technology? 🤔
The underlying protocol used is something called OAuth. It is defined by this website as:
“An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.”
With the basic understanding of social logins and the above definition, we gain some insight into what QAuth is about, but allow me to provide this simple analogy:
I remember my friend Sumedh describing QAuth as an interaction between a “Mother, Father and their Son.” Imagine that the mother wants some groceries from the market and she wants the son to buy them for her.
Before I go any further, allow me to clarify what the analogy represents:
Mother: The user of the application
Son: The third party client or in technical terms ‘the OAuth Client’
Father: The Social Account or in technical terms the ‘OAuth Provider’
The conversation may unfold in the following way:
Mother: Hey son, go to market and bring me some coffee powder. Take the required money from your father.
Son: Okay.
Son (OAuth client) goes to father (OAuth provider)
Son: Hey dad, mom told me to take some money from you since she wants some things from market.
Father (OAuth provider) asks mother (User) about the permission to give money to their son (OAuth client)
Father: Hey, shall I give him the money and how much?
(Authorization of your application takes place here.)
Mother: Yes, please give it to him.
Permission grant by mother (User)
Son (OAuth client) gets the required things from market and returns them to mother (User). Here, returning things to mother (User) can be thought of redirecting the user (or logging him) to the third party site.
For a more technical understanding of how this works on a coding level, Richard Schneeman has the below video to help you understand it:
Let’s Put all of This Into Context
Let's take the example from the DEV Community. If you wanted to create an account in the DEV Community using Twitter, this is what would happen:
-
Basically, if the ‘Signup with Twitter’ button exists then the initial setup between the OAuth Client (Dev.to) and the OAuth Provider (Twitter) has already been set up.
-
The Client triggers a ‘permission to grant page’ from the OAuth Provider based on the credentials it received from the initial setup. This looks something like the image below:
-
Once you login, thus granting the permission to access, the OAuth Provider redirects you back to the client and the client gets a token to access your information from the OAuth Provider. This access token enables the client to get specific data from the provider.
-
Based on that data the client then creates an account and logs you in.
What Happens on the Successive Login?
That’s a good question.
Now OAuth has multiple grant types and based on that we have different ways to get an access token from the OAuth Provider. For all subsequent logins the OAuth Client will hit the provider and generate a new access token to get access to the data and do the login.
Thus this enables us to achieve Single Sign-On, aka the ability to share data for users without having to release personal information as well as the ability to revoke access, plus the ability to not have long-lasting credentials exchanged.
Conclusion
I hope this short blog post helps you understand why social logins are more secure than the traditional username/password. I will be writing about the different OAuth Grant types in the future and will be providing code examples as well.
Thanks for reading! I really hope that you find this article useful. If you think this post was useful, please like the post to help to promote this piece to others.