Getting started with OAuth and Understanding how it works
Introduction ✨
I’m writing this due to an experience I had with implementing OAuth. The first time I implemented it in one of my projects, I got a bit confused. I didn’t know it worked because I didn’t take the time to read the docs, I just made it work 😅😁.
But things like that bother me, when I don’t know how they work. So I delved into the world of authentication and authorization, single-sign-on (SSO), OAuth, and role-based access control (RBAC).
In this article, I’ll go over OAuth, what it is, some of its advantages and how it works to clear any confusion you might have with the flow even if this is your first time exploring it.
What is OAuth?
OAuth (Open Authorization) is simply a framework for verifying a user’s identity to grant and control a third-party application’s (website) access to certain resources of the verified user.
OAuth is a way of getting a user’s data without having the user give their password.
That’s why you go to a lot of sites nowadays and see Sign Up with Google, Sign Up with LinkedIn (signing up with OAuth servers or providers), etc., with which you can create an account or sign in.
Some of its advantages 🌟
OAuth was created to protect users from third-party apps, but it has become much more useful.
One of the benefits of OAuth that I enjoy, and you most likely do too, is not having to remember a lot of passwords. I can just sign in or sign up with other accounts like Google, GitHub, or LinkedIn.
We all know what it feels like to forget a password 😭😂
thank God for the forget password feature 😂
Other advantages include
- Safer Passwords. Some people reuse passwords in multiple applications. This makes it easier for attackers, like hackers, to get access to your accounts on different applications that you might be logged into once they can hack and get your password from one application.
- As a developer, you don’t have to deal with managing users’ private credentials. You can outsource or delegate it to someone else (lol, I meant another organization or application).
Some important terms ⚡️
Here are the OAuth roles, which I’ll be using in my short explanation of how OAuth works as well. Most websites explain the OAuth with these terms, so just learn them now.
- Resource Owner: That’s you. The person or entity that authorizes access to their account information
- Client: The third-party application you are using that shows the “Sign Up with…” button. The application that wants to access your data. It can also be called the Service Provider (SP).
- Authorization Server (OAuth Server): also referred to as an Identity Provider (IdP). This is the application/server that manages access to your data. It issues an access token to the client, which the client later uses to access a user’s data.
- Resource Server: It is the server or place that hosts and protects resources (user data, et cetera). It’s designed to be accessed by clients with the proper authorization.
How it works 🚧
OAuth 2 is the prevalent version of the OAuth protocol. So, people typically refer to OAuth as OAuth2. It’ll be the same here.
Here’s a simple flow of how authorization would work with OAuth.
1. A resource owner goes to a client for the first time and is asked to create an account. This step is typically not part of the OAuth protocol itself.
2. To accept the request to create an account, you click on the “Sign in with…” button that redirects you to the authorization server.
3. The authorization server then asks if you want to allow the client to access your data (also telling you the data the client wants to get, they might need only your email at times)
4. If you accept, an access token will be passed to the client. The access token contains authorization privileges for the client to access the resource owner’s data.
5. The client can now make a request to the resource server with the access token to gain access to the resource owner’s data. Note that the access token can expire.
While the simple flow I created here from my experience with using OAuth so far captures a high-level view of the OAuth protocol, it’s essential to know that the implementations of OAuth may vary.
Here’s an abstract flow of how OAuth works
The key feature of the OAuth protocol is when a client redirects the resource owner to the OAuth server, where they would input their password, and then you’d be redirected back to the client with a token with which you could access the user’s data.
I hope this was helpful to you. And simplifies any doubt you have as to how the OAuth flow works.
Extra resources
Here are some extra resources I curated for you to learn more about OAuth and how to use it:
- The OAuth documentation [https://oauth.net/2/](https://oauth.net/2/)
- Learn more about the framework and standards at [https://datatracker.ietf.org/doc/html/rfc6749#autoid-1](https://datatracker.ietf.org/doc/html/rfc6749#autoid-1)
- OAuth 2 Simplified: [https://aaronparecki.com/oauth-2-simplified/](https://aaronparecki.com/oauth-2-simplified/)
- A Modern Guide to OAuth: [https://fusionauth.io/articles/oauth/modern-guide-to-oauth](https://fusionauth.io/articles/oauth/modern-guide-to-oauth)
- Learn about OAuth briefly: [https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2)
- Create an express/node app with OAuth: [https://auth0.com/blog/create-a-simple-and-secure-node-express-app](https://auth0.com/blog/create-a-simple-and-secure-node-express-app)
Have a great time, peace ❤️✌️