I'm sorry, but you are truly a genius. Your ability to explain all these various different topics and technologies is absolutely remarkable. It is very clear and comprehensible. You are extremely extremely talented, not only in your grasp of technology but in your ability to communicate and convey your knowledge in a manner that others can easily consume and comprehend. Bravo! Bravo! Once again, one of the most talented individuals I have ever seen on the internet.
Great tutorial! It's worth mentioning that there are two types of bearer tokens: Identifier-based and Self-contained. You explained the self-contained bearer token in this tutorial. Self-contained bearer tokens are easy to scale with distributed applications as they do not require the resource server to validate the token with the authorization server. On the other hand, an Identifier-based token is a hard-to-guess string, which the resource server needs to validate by making a call to the authorisation server's introspection endpoint, which adds latency and makes it difficult to scale with distributed applications.
Thanks for pointing that out! You're absolutely right-there are two types of bearer tokens. I focused on the self-contained token in this tutorial since it’s easier to scale in distributed systems due to the lack of dependency on the authorization server for validation. Identifier-based tokens, while secure, do introduce additional latency because they require the resource server to call the authorization server for validation. It’s a trade-off between ease of scalability and real-time validation. Appreciate you adding that clarification!
Great content, thanks for posting this. You have a gift to explain the stuff without overcomplication, but also going deeper than just scratching the surface.
a minor audio improvement suggestion for your videos. Applying an EQ which removes frequencies below 80 Hz or 90 Hz (High pass filter), will remove the boominess in your voice and give more clarity and comfortable listening experience.
Great question! How the resource server checks the token depends on the type of token. If it’s a JWT, the resource server doesn’t need to talk to the authorization server again. The JWT has everything it needs, like user info and expiration time, and it’s signed, so the resource server can verify the signature and ensure it hasn’t been tampered with. However, if it’s an identifier-based token, then yes, the resource server typically has to reach out to the authorization server's introspection endpoint to confirm that the token is still valid. This adds a bit of latency but ensures the token is actively verified. So, for JWTs, no extra server call; for identifier-based tokens, the resource server usually needs to check with the auth server.
Ok, thank you so much for the response. Nevertheless it is still not 100% clear how the resource validates the JWT. I could just pass it a valid JWT from another random application, together with the client Id and Secret, maybe the resource server has to have some private key or some tool to check that the signature is actually one made by its auth server ?
at time 5:07 you mentioned, OAuth2.0 is used to authenticate with google. Please correct me on this "OAuth is for authorization, not for authentication". OpenID Connect is used to authenticate the user which is build on top of OAuth2.0
How the resource-server will validate the token? Do the resource server still need to connect to authoriztionserver to get the token validated, once get validated it will fetch the access/permission details from the token?
what if i wanted to authorize which does not uses application of the authorization server i.e, you said in the example that google authorization to access google calendar in an app but what if my app doesn't uses any of those?
This is an awesome video, very detailed. Thanks for sharing !!!
5 месяцев назад
4:00 Does the Resource server communicate with Authorization Server when validating the Access Token? I assume it should have...
5 месяцев назад
Hmm, maybe it does not. AI gave me this response: "The Resource Server can validate the JWT independently, without contacting the Authorization Server, by: a. Verifying the signature using the public key of the Authorization Server. b. Checking the expiration time (exp claim) of the token. c. Validating other claims in the token (e.g., issuer, audience, scope)."
This error typically occurs when the OAuth 2.0 protocol is being used incorrectly, particularly with how parameters are being handled in requests. In OAuth 2.0, certain parameters, like scope, are expected to have only a single value or a single list of values. This error usually happens if you have Multiple Values for Single-Value Parameter So, ensure that your request is formatted correctly. For scope, you should provide a single string with space-separated values (e.g., scope="read write"). Avoid sending scope multiple times or in conflicting formats.Verify the OAuth 2.0 API documentation for the correct parameter usage. And If you have control over the server-side implementation, make sure the server correctly parses and handles OAuth 2.0 parameters. The server should be able to process a single scope parameter with a space-separated list of values.
@@abimanoharan2378 i got it. Token provided by authorization server has the information that resource server needs to contact authrization server. So when resource server receives token, it parses it and then uses that info to connect to auth server and validates the authenticity of token.
hello currently i worked with django application & i have one query about authentications is oauth2.0 is more secure then session ?? because currently i using session authentication flow that return session key when we pass user name or password
The Access token is not generated the way it has been represented. First an Authorization Code is generated and sent to the client app via the user agent. The authorization code is then sent by the client app directly with the the AS to generate the access token which is then used to access the resources.
Thanks man for the explanation, I have one request do you have any research papers related to 0auth 1.0 and 0auth 2.0, any reference would work also, I would be very helpful to you, Thanks again.
Thank you! Its primarily based on my previous experience with OAuth and SSO in general. Unfortunately I did not maintain the list of papers and articles I went thru to make this video.
@ByteMonk, just a small piece of feedback: when listening to your videos with headphones, the music at the end is noticeably louder than your voice. The difference in volume makes it uncomfortable for the ears. It would be helpful if the music volume was lower, or at least not louder than your voice, for a more comfortable listening experience. Thank you!
but once the client app has that token, it can request any information Google stores about the user??? it can consult his emails? his calendar? his maps history??? so instead of signing up in that web app filling a basic form with basic personal data, we use Oauth with Google (in this example) so the wep app can retrieve A LOT MORE INFORMATION about the user??!
Good tutorial but I feel there should be some spaces while you speak, so that we can digest what you have explained. Your voice is continuously running and we are unable to grasp and comprehend.
I understand what you were expecting. The video focused on Google OAuth 2.0 as an example to illustrate the overall OAuth 2.0 flow. That said, I can see how a deeper dive into custom OAuth 2.0 implementation would be more helpful for some viewers. The main difference between Google OAuth 2.0 and custom OAuth 2.0 comes down to the provider and how the flow is implemented: In case of Google OAuth 2.0: Google is the authorization provider. It handles user authentication and issues access tokens.This is Often used for allowing users to log into third-party applications (like a website or mobile app) using their Google account. In Custom OAuth 2.0 you build and maintain your own authorization server or use a third-party provider tailored to your application’s specific needs.So you have more control over the entire flow and can define your own scopes, tokens, and permissions Hope this helps
Access token will be sent in request header which we can see in the browser network tab. So, any user can pick this access token from the network tab and make a request using postman? Then, how can we say that it’s safe? Can anyone please explain!
if someone has access to your laptop then it's not safe they can read the access token but usually the token is stored in httponly cokie which cannot be directly read and we're using https so the requests in encrypted in transit
Bro just casually terminated my sufferings... thanks for the simple and comprehensible way to explain things
Just found this channel and it's amazing. Keep it up man, you're providing tons of value to the software design industry.
Been searching for an easy to understand visual of OAuth...and this is one of the best videos by far! Thank you!
Same here...I needed the visuals for clarity.
I'm sorry, but you are truly a genius. Your ability to explain all these various different topics and technologies is absolutely remarkable. It is very clear and comprehensible. You are extremely extremely talented, not only in your grasp of technology but in your ability to communicate and convey your knowledge in a manner that others can easily consume and comprehend. Bravo! Bravo! Once again, one of the most talented individuals I have ever seen on the internet.
Thank you so much for this lovely comment and your support 🙏
+100
@@ByteMonk You are really good most of my doubts got cleared .
why are you sorry for a compliment 😀
@@rpvaghasiyais it not a criminal offence to compliment? 😅
Great tutorial! It's worth mentioning that there are two types of bearer tokens: Identifier-based and Self-contained. You explained the self-contained bearer token in this tutorial. Self-contained bearer tokens are easy to scale with distributed applications as they do not require the resource server to validate the token with the authorization server. On the other hand, an Identifier-based token is a hard-to-guess string, which the resource server needs to validate by making a call to the authorisation server's introspection endpoint, which adds latency and makes it difficult to scale with distributed applications.
Thanks for pointing that out! You're absolutely right-there are two types of bearer tokens. I focused on the self-contained token in this tutorial since it’s easier to scale in distributed systems due to the lack of dependency on the authorization server for validation. Identifier-based tokens, while secure, do introduce additional latency because they require the resource server to call the authorization server for validation. It’s a trade-off between ease of scalability and real-time validation. Appreciate you adding that clarification!
Great content, thanks for posting this. You have a gift to explain the stuff without overcomplication, but also going deeper than just scratching the surface.
Underrated channel. You'll be having thousands of views in no time. Keep it up.
This channel deserves 100k subscribers. Its that good
Maybe one day!
Nice and elegant explanation. Thanks 👍
you’re one of the best at what you do, you give the perfect level of depth, wide variety of subjects, and often include answers to follow up questions
I just recently founded your channel andI'm amazed! Keep up the great work! God bless!
Thanks a lot. You explanation is very clear and easy to understand.
Brilliant explanation that even a layman like me can understand these concepts to some extent atleast .. thank you so much 🙏
Excellent explanation on OAuth concepts in plain language to reach broader audiences. Thank you!
Great explanation with nice animation showing all the steps!! Thanks!
a minor audio improvement suggestion for your videos. Applying an EQ which removes frequencies below 80 Hz or 90 Hz (High pass filter), will remove the boominess in your voice and give more clarity and comfortable listening experience.
Thanks for the tips!
Would love to connect with you sometime to ensure my audio processing is correct
Oauth 2.0 is very well explained in this video. Thank you!
Your video editing skills are amazed brother and colors are great
Best channel So far in terms of explanation in short duration on basic topics… kudos🔥
very precise nice expalnation thanku so much
Hello,
How would the resources server interprets the authorization token to know it is valid and ok. Does it talk with the Auth Server again ?
Great question! How the resource server checks the token depends on the type of token. If it’s a JWT, the resource server doesn’t need to talk to the authorization server again. The JWT has everything it needs, like user info and expiration time, and it’s signed, so the resource server can verify the signature and ensure it hasn’t been tampered with.
However, if it’s an identifier-based token, then yes, the resource server typically has to reach out to the authorization server's introspection endpoint to confirm that the token is still valid. This adds a bit of latency but ensures the token is actively verified. So, for JWTs, no extra server call; for identifier-based tokens, the resource server usually needs to check with the auth server.
Ok, thank you so much for the response.
Nevertheless it is still not 100% clear how the resource validates the JWT. I could just pass it a valid JWT from another random application, together with the client Id and Secret, maybe the resource server has to have some private key or some tool to check that the signature is actually one made by its auth server ?
This was a well done and well documented video. Thanks very much.
@0:22 - OAuth was never a authentication protocol (its a authorization protocol)
Yup. Now I don't know if I should keep watching.
at time 5:07 you mentioned, OAuth2.0 is used to authenticate with google. Please correct me on this "OAuth is for authorization, not for authentication". OpenID Connect is used to authenticate the user which is build on top of OAuth2.0
How the resource-server will validate the token? Do the resource server still need to connect to authoriztionserver to get the token validated, once get validated it will fetch the access/permission details from the token?
Am very gratefully for the easy understandable
knowledge about OAuth20... Thanks Bro, God bless you
Appreciate the support, thank you :)
what if i wanted to authorize which does not uses application of the authorization server i.e, you said in the example that google authorization to access google calendar in an app but what if my app doesn't uses any of those?
This is an awesome video, very detailed. Thanks for sharing !!!
4:00 Does the Resource server communicate with Authorization Server when validating the Access Token?
I assume it should have...
Hmm, maybe it does not. AI gave me this response:
"The Resource Server can validate the JWT independently, without contacting the Authorization Server, by:
a. Verifying the signature using the public key of the Authorization Server.
b. Checking the expiration time (exp claim) of the token.
c. Validating other claims in the token (e.g., issuer, audience, scope)."
The ressources server validate by either a public key or forwarding to authorization server but mostly by public key
Great explanation! Thank you!
Hi, do you know why this error occur? "OAuth 2 parameters can only have a single value: scope"
This error typically occurs when the OAuth 2.0 protocol is being used incorrectly, particularly with how parameters are being handled in requests. In OAuth 2.0, certain parameters, like scope, are expected to have only a single value or a single list of values. This error usually happens if you have Multiple Values for Single-Value Parameter
So, ensure that your request is formatted correctly. For scope, you should provide a single string with space-separated values (e.g., scope="read write"). Avoid sending scope multiple times or in conflicting formats.Verify the OAuth 2.0 API documentation for the correct parameter usage. And If you have control over the server-side implementation, make sure the server correctly parses and handles OAuth 2.0 parameters. The server should be able to process a single scope parameter with a space-separated list of values.
@@ByteMonk Thanks for answer, I finally solved it
This is too good! Subscribed 😊
Thank you so much 😁
How does the resource server variefies/validates the access/jwt token?
Thank you it was clear and concis.
I am not clear how does resource server validates token. Video doesnt mention any interaction between resource server and authorization server.
this is my confusion as well
@@abimanoharan2378 i got it. Token provided by authorization server has the information that resource server needs to contact authrization server. So when resource server receives token, it parses it and then uses that info to connect to auth server and validates the authenticity of token.
Don't have to
How did you creat the OAuth 2.0 flows?
Excellent video on OAuth 2.0, but small confusion at 5:15 convert access token encodes to JWT
hello
currently i worked with django application & i have one query about authentications
is oauth2.0 is more secure then session ??
because currently i using session authentication flow that return session key when we pass user name or password
that was soo good!
precise and well explained with well animations👍
excellent, thank you
very good video bro , thanks for sharing us
Should there be an arrow or two between auth and resource servers?
i want to utilize the oauth with jwt can u plz give me any example repo to refer
Great Explanation !!!
What tool using to built presentations?
The Access token is not generated the way it has been represented. First an Authorization Code is generated and sent to the client app via the user agent. The authorization code is then sent by the client app directly with the the AS to generate the access token which is then used to access the resources.
I love the animations explaining how it works. May I know what app you use for these?
FCP, Adobe, Photoshop, Ppro. Takes about 10 hours for a 5-10 minutes video :)
@@ByteMonk I'd say it's worth it.
Thanks man for the explanation, I have one request do you have any research papers related to 0auth 1.0 and 0auth 2.0, any reference would work also, I would be very helpful to you, Thanks again.
Thank you! Its primarily based on my previous experience with OAuth and SSO in general. Unfortunately I did not maintain the list of papers and articles I went thru to make this video.
Please can I use this to reset password in my web application
Nice video. You mentioned that there were 4 OAuth flows but I'm mistaken you only described 3 of the 4 in the video. Was that intentional?
thank you, I will look into this
nice explanation
Great Thank you
@ByteMonk, just a small piece of feedback: when listening to your videos with headphones, the music at the end is noticeably louder than your voice. The difference in volume makes it uncomfortable for the ears. It would be helpful if the music volume was lower, or at least not louder than your voice, for a more comfortable listening experience. Thank you!
Thank you 🙏
good explanation
Hey can you make one for macaroons as well. There aren't enough resources for it online
Thanks! Good explanation. Could you do a video on CA certificates or self-signed certificates?
Here :) ruclips.net/video/BQwKZ6zfyk0/видео.html You may also checkout relevant videos in the playlist in description.
How is client id secret created . I did not hear this word Sr all
@3:24 u made a mistake saying google's APIs . the correct one is Resource Server.
Thank you 🙏
but once the client app has that token, it can request any information Google stores about the user??? it can consult his emails? his calendar? his maps history??? so instead of signing up in that web app filling a basic form with basic personal data, we use Oauth with Google (in this example) so the wep app can retrieve A LOT MORE INFORMATION about the user??!
Whenever you grant it access it shows what information the app wants to access. It doesn't get everything
JWT is not a protocol. OAuth2.0 is protocol. JWT is used like access card which holds the required information for authorization.
Thank you sir. Unfortunately I am here 1 year too late
Better late than never!
Can you do 1 video on SAML?
SAML video just released!
@@ByteMonk awesome.
👍🏾
Good tutorial but I feel there should be some spaces while you speak, so that we can digest what you have explained. Your voice is continuously running and we are unable to grasp and comprehend.
The ping is so freaking loud. My gosh.
When your title is OAuth 2.0 explained you should not be explaining google OAuth 2.0 ! I expected a taqnice for implementing customer OAuth 2.0
I understand what you were expecting. The video focused on Google OAuth 2.0 as an example to illustrate the overall OAuth 2.0 flow. That said, I can see how a deeper dive into custom OAuth 2.0 implementation would be more helpful for some viewers.
The main difference between Google OAuth 2.0 and custom OAuth 2.0 comes down to the provider and how the flow is implemented:
In case of Google OAuth 2.0: Google is the authorization provider. It handles user authentication and issues access tokens.This is Often used for allowing users to log into third-party applications (like a website or mobile app) using their Google account.
In Custom OAuth 2.0 you build and maintain your own authorization server or use a third-party provider tailored to your application’s specific needs.So you have more control over the entire flow and can define your own scopes, tokens, and permissions
Hope this helps
All the topics are covered....but the animations are poor.
Thanks for your feedback. Please let me know what to be improved and if you have any reference animated videos.
Access token will be sent in request header which we can see in the browser network tab.
So, any user can pick this access token from the network tab and make a request using postman?
Then, how can we say that it’s safe? Can anyone please explain!
if someone has access to your laptop then it's not safe they can read the access token but usually the token is stored in httponly cokie which cannot be directly read
and we're using https so the requests in encrypted in transit