How OAuth2 Works - Simple Explanation (video, 5 minutes)
Have you ever tried wrapping your mind around OAuth 2 but ended up lost in a sea of jargon? That’s why ByteByteGo is here today. They remind us that these complex concepts can be understood with digestible explanations. Let’s start from the early days of the internet, where sharing information was straightforward. One would simply hand over their username and password to another service, allowing them access to everything. However, such a practice is frowned upon today, although we might still encounter it in certain finance software. Luckily, we have something much better now - OAuth 2. OAuth 2 is like giving someone a special key. This key allows them to access specific information in another application, and we control who gets access to our data without having to share a password. Best of all, we can revoke that key at any time.
Let’s analyze this using an example. Imagine a photo storage application, SnapStore. We use it to store our photos, and now we want to print some of them using a third-party printing service, Print Magic. Instead of manually uploading each photo to Print Magic, we ask Print Magic to do this for us. With a simple click, we grant Print Magic permission to access our photos on SnapStore. By using OAuth 2, Print Magic can then access our photos on SnapStore on our behalf, without ever knowing our SnapStore login credentials. This demonstrates the OAuth flow.
In this scenario, we are the resource owner, as we own the photos on SnapStore. SnapStore is the resource server that stores our photos. Print Magic is the client that wants to access the photos. The authorization server could be part of SnapStore or an external identity provider, and is responsible for managing the OAuth 2 process. The OAuth flow begins when we instruct Print Magic to fetch photos from SnapStore. Print Magic sends a client ID and scope, which represents the requested level of access, to SnapStore’s authorization server. As the resource owner, we authenticate directly with SnapStore and authorize Print Magic to access our photos. Once consent is granted, the authorization server sends an authorization code back to Print Magic. Print Magic then presents this authorization code, its client ID, and client secret to the authorization server.
If the authorization server verifies the authorization code, client ID, and client secret, it issues an access token to Print Magic. Finally, Print Magic uses this access token to request our photos from SnapStore’s resource server. This OAuth 2 process ensures that our SnapStore login credentials are never exposed to Print Magic, while allowing Print Magic to access only the photos we authorized it to see. It’s also important to note that the access token can be set to expire after a certain time or can be revoked by us at any point, providing an additional layer of security. OAuth 2 also supports refresh tokens, which can be used to obtain a new access token when the old one expires, without requiring our intervention. That’s OAuth 2 in a nutshell. It’s an essential piece of the web security infrastructure and the backbone of many secure seamless app interactions we use daily. At the time of writing this article, the video has achieved 642417 views and 15273 likes.
Toggle timeline summary
-
Introduction to OAuth 2 and its complexities.
-
Purpose of the discussion on explaining OAuth 2.
-
Invitation to dive deeper into the topic.
-
Overview of early internet practices regarding information sharing.
-
Contemporary practices still using outdated methods.
-
Introduction of OAuth 2 as an improved alternative.
-
Understanding OAuth 2 as a special key for access.
-
Example of using OAuth 2 with SnapStore and Print Magic.
-
Granting permission to Print Magic to access SnapStore photos.
-
Explanation of the OAuth flow in the example.
-
Identifying roles: resource owner, resource server, client.
-
Overview of the OAuth 2 flow process.
-
Authorization server issues an authorization code.
-
Access token issuance upon code verification.
-
Security measures: credentials and access control.
-
Use of refresh tokens in maintaining access.
-
Summary of OAuth 2's significance in web security.
-
Promotion of a system design newsletter.
Transcription
Have you ever tried wrapping your mind around OAuth 2 but ended up lost in a sea of jargons? That's why we're here today. We're breaking down these complex concepts into digestible explanations. Let's dive right in. Imagine the early days of the internet. Sharing info was straightforward. Just hand over your username and password to another service, and they could access anything they wanted. This practice is frowned upon these days, but we might still encounter this practice in certain personal finance software, to scrape information from crusty old banks. Luckily, we have something much better these days. Enter OAuth 2. OAuth 2 is like giving someone a special key. This key allows them to access specific information in another application. We control who gets access to our data without having to share a password. And yes, we can revoke that key at any time. Now let's play this out with an example. Consider a photo storage application, SnapStore. We've been using it to store our photos, and now we want to print some of them using a third-party printing service, Print Magic. Instead of manually uploading each photo to Print Magic, we ask Print Magic to do the job. With a simple click, we grant Print Magic permission to access our photos on SnapStore. Using OAuth 2, Print Magic can then access our SnapStore photos on our behalf, without ever knowing our SnapStore login credentials. This is an example of the OAuth flow. It's an elegant stance between us, Print Magic, and SnapStore. All orchestrated by OAuth 2. Now let's unpack this further. In this context, we are the resource owner, because we own our photos on SnapStore. SnapStore is the resource server that stores our photos. Print Magic is the client that wants to access the photos. The authorization server could be a part of SnapStore, or an external identity provider, and is responsible for handling the OAuth 2 process. Let's follow the OAuth 2 flow in this scenario. It begins when we instruct Print Magic to fetch photos from SnapStore. Print Magic sends a client ID and scope, which represent the access level requested, to SnapStore's authorization server. As the resource owner, we authenticate directly with SnapStore, and grant Print Magic the consent to access our photos. Once consent is granted, the authorization server sends an authorization code back to Print Magic. Print Magic then presents this authorization code, its client ID, and client secret to the authorization server. The client secret is a private key shared only between Print Magic and the authorization server. If the authorization server verifies the authorization code, client ID, and client secret, it issues an access token to Print Magic. Finally, Print Magic uses this access token to request our photos from SnapStore's resource server. This OAuth 2 process ensures that our SnapStore login credentials are never exposed to Print Magic, while allowing Print Magic to access only the photos we authorized it to see. It's also important to note that the access token can be set to expire after a certain time, or can be revoked by us at any point, providing an additional layer of security. OAuth 2 also supports refresh tokens, which can be used to obtain a new access token when the old one expires, without requiring our intervention. That's OAuth 2 in a nutshell. It's an essential piece of the web security infrastructure, and the backbone of many secure seamless app interactions we use daily. If you like our videos, you might like our system design newsletter as well. It covers topics and trends in large-scale system design, trusted by 400,000 readers. Subscribe at blog.bybygo.com.