OAUTH 2.0
What is OAUTH
OAuth is a process that allows an application to access specific user data without the need of authentication or the user's password.
Basically the client gets authorized to act on your data without ever seeing your credentials.
Simple example
Imagine that you are hiring a personal chef. The chef will need access to your kitchen so that they can cook for you.
→ Without OAuth, you will need to give the chef your house keys, your kitchen keys, and access to the whole house so that they can cook for you.
→ With OAuth, the only thing that you need is to give the chef your kitchen keys through a multi-step format, which is the chef arrives at your door and knocks, they identify themselves as the chef, and they request access to the kitchen. You allow access to the kitchen by unlocking your main door and showing them where the kitchen is. They get to the kitchen, do what got them to the kitchen, and then they leave, having only access to the kitchen.
Practical example
You want Calendly to automatically check your availability and book meetings on your Google Calendar. Without OAuth, you would give Calendly your full Google email and password. Calendly can now read all your emails and access your Google Drive; they can even change your Google account settings. With OAuth, you click "connect with Google" inside Calendly; Google shows you exactly what Calendly is asking for, e.g., create events, see your calendar events. You grant these permissions by clicking allow.
OAuth was built to solve the password-sharing issue and full unrestricted access that is given to third-party applications.
How does OAuth 2.0 work?
OAuth 2.0 was originally developed as a way of sharing access to specific data between applications. It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider.
- client application—The Cook, Calendly
- Resource owner—You, my data in my Google
- Oauth service provider—YOU at the door or gate, Google
- Resource server—The kitchen, Google
OAuth has two major types
1. Authorization Code Grant Type.
This is the most secure of the two flows, and it has 7 major steps.
steps
1. Authorization Request
The client sends a request to the /authorization endpoint asking for permission to access specific data.
It contains the following parameters:
- client_id -> unique identifier for the client
- redirect uri -> where the client will be redirected to
- response type -> what the response application is expecting
- scope -> what subset of data the app wants to access
- state -> unique value tied to the current session
The chef arrives at your house, knocks on the door, and says, "Hi, I’m the chef you hired. Here’s my ID (client_id). Please let me into the kitchen only (scope). After you decide, send me back to the side door (redirect_uri). Also, here’s a secret note so we both know this is the same visit (state).”
2. user login consent
The user is presented with a login page with the specific data that the application wants to access. The user then chooses to accept or deny.
Get Kasika Ibrahim’s stories in your inbox
Join Medium for free to get updates from this writer.
You look through the peephole, confirm it’s really the chef, and decide whether to give him kitchen access or not.
3. Authorization code grant
if the user clicks accept, the browser redirects to the callback endpoint.
You accept. Instead of giving the chef the actual kitchen key right away, you hand him a temporary paper slip (the authorization code) and tell him to go to the side door.
4. Access token request
A server-to-server post request is sent in the /token endpoint. It takes place in a secure endpoint; hence, it cannot be observed.
The chef takes the paper slip to a secure back office (server-to-server) and says, "Here's the temporary slip you gave me. Please exchange it for the real kitchen key.”
5. access token grant
An access token is granted if everything is done as expected.
The back office checks the slip, confirms everything is correct, and gives the chef the real kitchen key (the access token). Sometimes they also give a spare key that lasts longer (the refresh token).
6. API call
The application fetches the user data from the resource server.
The chef uses the kitchen key to open the kitchen door and starts cooking.
7. resource grant
It verifies tokens and verifies that it belongs to the current client application
The kitchen lock checks the key. If it’s valid and belongs to this chef, it opens and lets him work only in the kitchen.
2. Implicit code grant type
It is a less secure and very simple type of OAuth.
All its communication happens via browser redirects
STEPS
- Authorization request
- user login and consent
- access token grant
- API call
- resource grant
