OAuth 2.0 - a dead simple explanation

preview_player
Показать описание

00:00 What is OAuth 2.0?
00:13 What problem does OAuth 2.0 solve?
02:04 OAuth 2.0 Client Registration
03:06 OAuth 2.0 Confidential vs. public clients
04:21 OAuth 2.0 Authorization Code Grant
06:43 OAuth 2.0 Access and Refresh Tokens and JWTs
08:03 OAuth 2.0 Grant types: client credentials grant, implicit grant, resource owner password grant, device grant
09:03 Outro

OAuth 2.0 is an "authorization framework [that] allows third party applications to get limited access to an HTTP service" (RFC 6749).

OAuth 2.0 is all about giving third party applications limited access to APIs. Prior to OAuth 2.0, the third party would have asked for the user's credentials and would have used these credentials on the respective API. OAuth 2.0 eliminates the need for password sharing by introducing a new entity called the OAuth 2.0 authorization server.

The OAuth 2.0 authorization server issues access and refresh tokens to third party applications thereby eliminating the need of credential sharing. The third party application is called the client in OAuth terminology. The API the third party wants to get access to is called the resource server or the protected resource.

Before a third party can get limited access to an API, it first needs to register itself with the OAuth 2.0 Authorization server. The third party application, the so called client, gets a client id upon registration with the OAuth 2.0 authorization server. If the client can keep data secret, then it will also obtain client credentials. The simplest form of a client credential would be a shared secret called the client secret. OAuth 2.0 also supports more sophisticated means auf authenticating against the OAuth 2.0 authorization server such as mutual TLS (mTLS).

Once the client is registered, the client performs one of the OAuth flows that are also known as grant types. The most popular grant types are the OAuth 2.0 authorization code grant which orchestrates an approval flow between the resource owner, the OAuth 2.0 authorization server and the protected resource.

Contrast this with the client credentials grant which is made for machine-to-machine communication. The resource owner password grant and the implicit grant are insecure according to the OAuth 2.0 Security best current practices and must not be used. Then there is also the OAuth 2.0 device grant which is built for devices that do not have a browser or where entering credentials is cumbersome such as Smart TVs.

While the OAuth 2.0 RFC does not mandate the access and refresh tokens to be structured, in most deployments they are actually JSON Web Tokens (JWTs). This has the advantage that the protected resource can validate the signature of the token locally without having to make a REST call to the authorization server to check for the validity of the token.

Рекомендации по теме
Комментарии
Автор

What do you think about this video?
Let me know in the comments below.

FYI: I had to re-upload this video because the old one had an audio issue. Sry for that.

jgoebel
Автор

Great slow and clear explanation without cutting any corners, thank you

alastairtheduke
Автор

Great video! Short and simple explanation to share with colleagues and not look like an alien trying to explain it.

Mr.Dyz
Автор

One of the best explanations about OAuth, thanks a lot!

alexpato
Автор

Thank you a lot ! I have to implement an authorization code grant for my personal project and the service doc was really confusing. Great explanation, you saved me 🤗

carolineroy
Автор

Excellent video! Not verbose and tedious like many others, and very informative. The only small nit I have: at 4:45 you say "we will learn about the response type in a minute" but then I don't think you ever talk about it. You do talk about Grant Types which are related (I think?) but not response type.

jrblackify
Автор

You are creating amazing content! Please keep doing it!

psylo
Автор

It is really really good explanation. Thank you....

talatkuyuk
Автор

Thank you very much. Your video is amazing <3.

thongtranlequoc
Автор

Welcome back! May I ask what tool you used to illustrate this video?

GigGigJigolo
Автор

amazing video.. are you planning to redo the other grant types similar to your old playlist or this is a one off update

SandeepJan
Автор

Great content, as always!
Could you please share the name of the software you used to create these animations?

k.deepak
Автор

Good video but really bad EQ, I had to really crank down 125HZ cut to keep the floor from shaking :/

pierspad
Автор

9:10 the client may get refresh token but did you miss access taken part ? When is access token granted by the authorization server ?

haidersyed
Автор

Nice video and I think of using Oauth for the project am working on now but I want to ask a question. Did I need to pay or add my credit card before I can use it?

nwaformicah
Автор

Question: what is the difference between a framework and a protocol?

johanneskingma
Автор

How does Google know that the client has a backend ? What if Google issued client secret when there is no backend ? I got confused I think client credentials part needs more elaboration

haidersyed
Автор

Dumb question not directly related to OAuth... if you can extract anything out of a mobile application for example, how would such an application communicate with its backend securely? Surely you could also just extract those authentication secrets?

jano.
Автор

2:37 "if the 3rd party application can keep data secret" what is that supposed to mean?? if it its trustworthy? if it stores data at all?? All the effort to make a video and then you throw things like that in there ... I don't understand video makers anyway

ME-bwrl