oAuth and OpenID connect | Most confusing topic in plain english

hello guys how are you doing i hope everyone's doing good okay after i released my last video i got like uh 10 15 questions most of those are kind of a close kind of a similar i'm not surprised by that because that was a topic kind of a topic most abused most misunderstood and most confused topic kind of in the last decade so i'm not surprised by you asking that question from me so what was that question what is o and what is open id connect how these two connect together and what is the difference and what are the use cases when to use what okay so in this video we are going to talk about that in very simple english right not two technical jargons but i'm going to explain why and when and how also what is the difference why this open id connect and or two both are in the game okay so before that i must tell you uh you guys are really good awesome you are giving me now likes comments and i saw a few people sharing my videos too thank you very much for everything because that is a way you silently can help me to the things what i am giving you right i'm getting content for you to teach something where you probably don't know probably um didn't understand or something like that whatever so if you're interesting on this video please click on thumbs up and also if you have something to tell put a comment and share this video in the community also subscribe if you're not subscribed even though you subscribe if you're not click on the bell icon go ahead and click that right google says remind this to you on every video so i'm doing that okay i'm listening to google okay so what is this oh and open id connect story right so let me to tell you uh history little bit right uh i started coding almost in 20 since 20 3-4 that was my graduation years and like those since then i am doing coding and almost since 20 2007 8 i was doing some production system and everything ever since then i am on this field so i have seen this transition from uh very beginning to what we are here right now so i can explain so before like in like 26 7 8 those uh i mean 2016 2008 six uh those uh days we use something called phone right form authentication what does mean we keep username and password in our database of course in the hash format and then users in the username and password we verify that the problem is when you do that now if you think now you have maybe accounted at 20 30 websites right so you have to use 20 30 different username and password to all those website if you don't use uh you if you use the same account if one website compromise your entire account all the website get compromised right so to solve this problem that there i mean there was a need or some solution to solve this problem for example uh in like early days you had something like hi-fi and kind of those social media before the facebook right so now facebook but before the facebook there was a few um social media website so when they wants to when they want you to like communicate uh to your friends for example let's say you are creating a account on an abc website right let's say hi-fi right hi-fi didn't do that but let's say high-five so if you're creating a profile on a hi-fi if you want like to invite your friends what the hi-fi do is they're asking your uh gmail username and password just believe me yes they did ask your gmail i mean not the hifi exactly right so they ask your email and the password of the email right so what they do is they just log into your account and then they get your contact and then they send invite across the board right so that's what they did so i mean that's not wrong right i mean it's wrong when when you look at the today but those days it's not a big deal but today if your account if you give username and password of your email account that kind of end of the world right because your banking account detail so your health information detail your insurance detail everything probably your romantic life and everything is in your gmail account right so you don't like to give that to anyone else so today to today well that's not going to fit so now uh in like uh so now people were using like different different workaround but o came in to solve this problem right so the first question was over zero or one or whatever you call right but i'm not going to talk about that because that is dead now okay so we are going to talk about o2 right so how old to solve this problem right so i have a small um diagram for you right so so this will uh easy to uh understand right so o2 is a token based authorization protocol right so this is very important authorization protocol so we are going to talk about this uh later right i'm not going to talk about this uh technical theoretical stuff right you can stop the screen and you can watch those but rather i'm going to explain you how uh this exactly work right so before we go into these diagrams and everything we need to understand why o came and what is the problem it going to solve okay the problem we already discussed right so i create a profile on my hifi website right the hi-fi needs to send email to my friend saying hey kris is on hi-fi please come around and hang around his profile right so hi-fi website wants to send email to my friend on behalf of me right that mean hi-fi wants to access my account on behalf of me but i don't like to give my password to high five right so that is the problem or going to solve right so how it's going to solve this problem so earth in the old world or paradigm we have someone called razorsona right resource only in our example is me right so and we have an authorization server right we don't know what is that yet for so keep it side and we have a client who is the client client is hi-fi the website the social media website right and then we have something called something called resource server right we don't know that yet but keep that for a sign okay so now what it does is resource owner right so give a consent to authorization uh server right we're granting the client to the hifi website to access the resource server right in that case let's say my gmail contact right so now the resource server verifying that access with the authorization server and then give the access so in this uh entire cycle we are going to go in more detail that's not the abstract one right we have few uh terminologies that's what you made confused in my last video right so one is access token access token is the uh is the token which tells about you and what little bit about your uh what you can do for example you have probably your roles and your permission and stuff right and there's a refresh token the refresh token is a token where you can use to exchange right you can get new access token when the access token is expired right usually access token lifetime probably like 30 minutes or 60 minutes right so they do that to make sure uh if someone is stolen right hijack your access token they don't get access to your account right so whenever access token is expiring that you can use a refresh token to obtain a new access token right that's where access to refresh token comes right so then we have something called client id secret uh i'm not going to go in deep into that and scope i mean i'm going to explain but not now and there's something called jot or what's known as a jwt json web token so that is a token uh where we put all those information and encoders it's just a basics for encoded string you can decode it at any point okay so now let's see the general flow of this entire process right so now we have a client clients in the request to the resource owner right for example let's say now i logged into my hifi account i create my i mean you can think hi if i oel for anything right this is social media website and you can go to hifi website and create your profile and now you are saying hey i want to invite to my friends right so now client my hi-fi is sending a request to the resource order to me hey um can i access your uh gmail contact or something like that okay so now me automatically getting redirected to my authorization server in that case let's say probably gmail server right so gmail server now validate my username and password i'm okay to give my username and password to gmail because that is their username and password right i can give my username and password of facebook account to facebook right i'm not scared to do that i can give my twitter username and password to twitter right because it's their account right so anyway they have it so i'm going to give that and then the authorization server issue a token right to the client keep in mind this is not the exact flow right this is again abstract flow i'm going to the exact point next next slide right so talking to the client so now the client does this client send the token to the resource owner okay the resource server sorry not the reserves owner is your server right resource server send this uh token to authorization server to validate it's asking hey did you show this token right so resource authorization yes i showed this token right so now um the resource server delivered in the resource to client right so put this uh into the real example we are going to do that in the next slide right okay so then there are few grant types authorization code grant type client credential grant type implicit password and device code right authorization code grant type is the widely used grant type right i probably do have another video about that because uh in the last video i did a part one of the security in sj's right i'm going to do the part two probably in a few days right so then client credential client credential is one other flow right implicit it's a flow i'm going to explain that in the next slide because you need to learn about the back channel and the front channel to talk about the implicit right and the password password run type you should we don't use but it was for you sometime right but i'll explain that too right here's the real use case right so let's say now client send the request to authorization server right let's say client is a hi-fi my website and send the authorization uh request to google authorization server now we are going to send emails right so now authorization server pop up me and like dialog box and say hey hi-fi is going to access your contact list right are you okay with this right so now it so i have so many things with the gmail i have my contacts my calendar my email my chats and everything but out of that hi-fi asking to access only my contact this is very important right so so if i give my username and password they get access to everything but here they're only getting access to my contact okay that's the important point okay so now i'm saying yeah it's okay right so now authorization server send the code important right important right put in red line important it is not token it's in the code right i'll explain why so now the token the the client against in the or token request to authorization server right first it's in the code now clients say hey i don't need this send me the token it's into the authorization server keep in mind it's a dashed line okay pay attention over there and then authorization servers and the token right so now client does is clients in the token to resource server right so when the clients in the token resource server resource will validate this token against authorization server right if it is a vr token if it is just access token uh they have to talk to authorization server and get their profile or whatever their claims and everything if it is a jot jwt token um it depends how the architecture design right probably you may have everything certificates and the keys with you to validate the token right if they don't have you have to talk to authorization server get the certificate or their keys right if not if you have that already in your application you don't have to talk to authorization at all you can verify the key yourself okay so now that is done so now you've added the token so token is validated um now you are delivering a resource to the client okay if we apply this to our use case now hi-fi is going to send the email on behalf of me hi-fi and the request to authorization server hey can i access krish's email authorizers are asking me that is what consent screen right uh they are going to access your email uh contact list are you okay with it i'm saying yes right so now authorizing server send the code to the hi-fi right hi-fi says no i need a token so it come back to authorization server right so now authorization will give the token right so now uh hi-fi send the token to my uh the google contacts uh server either where wherever the contact is hosted right and then it deliver the contact right so what are the confusing point here's the thing google contact is google and you are asking the password and the username sorry token also from google so now a lot of people get confused authorization server and resource server are safe no it's not same right for now just think authorizing server is some sort of a server what google has where you your all the user accounts right the contact server is a different server they are hosted in a different location probably right so they don't talk to each other okay so now what you do is you talk to google's authorization server and get your credentials validated and get token and you give that token back to contact and asking hey can you give this to me okay right so now everything is fine right so what are the these different uh flows right so what are these different grant types okay so here's how it works so now what we discuss is here is the authorization code flow this is ideal when client as i mean me the resource owner don't trust the client right for example let's say in my company there is something like a rave application i can i can appreciate someone right i can actually i can send a rave to someone saying hey you did a great job right but if they ask my facebook uh profile to login to rave application i don't like to give it right i don't want to give my facebook username and password to my this my office application because i don't trust these people like they may save that in the database right how how i know that so in that case i don't trust as a resource owner i don't trust the client so i'm not giving my credential to my office application because facebook is my personal account in other hand right in other hand my office let's say they have the same same wave application i can send the rails so they're asking my office email and office account password right my my corporate uh user credentials right so now i can give it because why because those account is belongs to my office this application also developed by uh office right is the responsibility is office so it is okay to give my username and password to that application so as a resource owner i can trust this application the client right so in that case you can use a password grant type right in that case you can use the password grant type in the previous example when i as a resource owner mean i don't trust the client i cannot use password grant type i should use authorization code grant type so how let's say the wave application use authorization code grant type then they will have a button called login with the facebook now they don't ask my facebook username and password instead of that they redirect me to facebook right and now facebook asking my username and password when i say yes they turn they send the token or a code back to that wave application right so keep in mind credentials are never transmitted over the wire or anywhere right you your clients never see the credentials of the resource order if i give my username and password to facebook facebook never send my password back to uh my web application right so now you know the use cases right when the resource owner plus your client your you mean your application right they don't hesitate to give the credentials you can use the password run type when they don't trust you need to use authorization code grant type right so now the other question usually ask why you have a token request separately why you just send the code first and then using the code back to me and again send the token right doesn't make sense authorization service in the code to the client clients in the code back to authorization server otherwise it was in the token right why are we doing this why you can't directly send the token first right so here's a problem now most of the time we are dealing these with the web applications right you know if anything in the web application you can right click and go to a view source and you can see everything what they use right and there are tricks and you can see all the javascript codes and everything because it's in the client side so if you give the token if you go with the token directly um if you get the token directly from the front end right then the problem is someone can see your credentials credentials mean when you register client with your authorization server right so what happens internally so the authorization server register your client your app and give you a client id and a secret right they give you a client id and a secret to obtain the code you only need to give your client id right in the first request using the request check with the resource owner get the consent and then send the code to this flow you only need to give the client id right but to obtain the token you need to provide the client secret so what usually do is when we get the code some back-end service talk to authorization server again and exchange this code with the token right front-end do not send uh this token request why because token request is kind of a secured it's it's asking your client credentials whether i mean that your the applications client id and the secret as well right we call is a back channel so we have a front channel in the back channel right so that's why we i i created like a straight line with the front channel and the dotted line the dash line with the back channel okay so but sometimes you may don't have a backing you may only have a front end right so in that case you don't have anyone to send this uh token request right secure request so in that case you can use implicit flow um you can directly ask token right so first request uh you go to the consent and uh as a number four you won't get the code you will directly get access token okay so that is the way uh uh this is why this code and token comes because i have seen developers uh take in the code and then again the front end itself obtaining access token that is wrong right because uh that is secure anyone can take your client id and secret then they can act like you right okay i'll give example so let's say for somehow i am getting no getting to know facebook messenger apps client id and a secret right let's say for some some way i'm getting it i i know my i know the facebook messenger apps client id and the secret then what i can do is i can create a different app and i can send this request to facebook authorization server sending hey and this client so when i provide the client id in a secret facebook authorization server understand my application as a messenger and granting whatever the resources it's supposed to grant right it's really dangerous so do not expose your clients secret at any manner to outside okay so i hope you understand that so now the next question okay next question is what is the oibz open id connect and what is the role of oidc in this entire drama or in that is overflow right so the simple answer is none but then why it is exist okay so let me to explain so um as i explained before uh oath oath came in to solve the problem where i don't need to disclose my uh credentials to strange application to access my resources right so now the uh so what they have done the face with the google and um some other providers what they have done is when this uh oauth came into the picture they realized oh this is nice we can get this to give the signing with feature right sign in with facebook right sign in with google or something like that so if you experience that little button what you see in the website that is that one right but ooh is not mean to or not designed to handle authentication right it is authorization protocol right because if you remember why it is came because hi if i want to access my google contacts to send emails right if i cannot give my username and password because then they can do whatever they want with my gmail account right my google account right they can access my photos they can access my contact calendar everything but i want to limit i want to limit what they can do so that mean authorization right authentication means who you are authorization is um what you can do right one millionth time in my videos right so um so now they came to solve authorization problem right so they want to tell they want me to tell what hi-fi can do on my gmail account it is not authentication but uh they google the facebook and other the giant tech companies they were using uh oh to handle the authentication as well right but it's not mean to do that so oidc came in to solve this problem and make this misuse is kind of a formal use right so what they have done is they put open id connect like as as you see this in the in picture is a very small portion of this entire uh old paradigm right what they do is they handle authentication part right there is no magic happening here right so um oh i owe you something called scope what i'm going to explain next and oidc has a separate scope called open id right so that we can use to authenticate users right so along with that bundling oidc and o2 together you can use uh these two authentication and authorization both right so if someone asks what is o2 o2 is authorization protocol right can it handle uh authentication no it cannot but with open id connect it can handle authentication as well so then what is automatic open id connect oidc oh it is a protocol we are uh talk about the authentication and support or to to handle the authentication before the authorization okay who you are and what you can do okay how they do this so they have something called scope right they have something called scope okay so let's jump from uh 2006 to 2021 with the latest stack right so let's say i'm going to design uh to do application okay i'm going to design to do application in my to do application we have a create read update delete operations you can do right so now i have my application so now some other company want to implement a mobile app for this mic to do a system right to do application system so in that mobile lab they mainly want to give the view to do feature right so in that case a user can wake up in the morning and say hey what other to do for my day okay so now there is a user who registered with my application and he has a tons of to-do list okay so now same time he use that mobile application okay so now he don't want to give his credential to the mobile application because a third-party application right so this is to-do list is maintained by my company let's say code labs but that is the other company xyz company they have the mobile application right so user don't want to give my credentials uh my the codelab account credential into that third-party company application right so they have a button called sign in with codelabs right they redirect them to me right so now before this happen that's a user perspective before this happened this particular company need to uh talk to me hey i want to integrate with you then say okay good let us create a client right so i'm creating a client on my authorization server and i give them a client id and a secret right client id and a secret to that mobile app company right so now when whenever the user come and want to sign in with code labs they are going to redirect the user to my authorization server providing their client id right providing their client id so now this to do application has a four operations to do we call these are the four scopes scopes are nothing but what you can do right so you can say uh to do read to do uh create to do update to do delete those are the four permissions also known as oath world scopes right sometimes we say scope is a collection of claims but in general scopes is kind of a permission it's easy to understand when you map like that right so now that mobile app asking a permission to read the to-do right so whenever he direct i am saying my authorizer was sending a request to consent screen to the users hey this mobile application want to read your to-do are you allowing to do that right so that is the same thing when you sign into facebook right they give you a notification right sometimes you don't read that right it says um this application this game i want to access your public profile email address friend list and so and so right so you have to read that and then you have to give the consent right so now my authorization server give a token to that mobile app where they have permission to read the to-do's okay so now i have a separate my to-do server right the hosted server they send the token to the redo server and asking hey can you give me a to-do list which belong to this server right so now a to-do server will extract the token and see who the user is and then okay he is asking to read the to-do and his scope is has a read so it delivers now this one of the developer or someone is still in this token they are trying to delete the to-do right so now they send the request to the authorization my resource server or as my to-do server saying hey i want to delete this to do right now my resource server check the token token has only scope for read right so therefore this request will denied the request will not complete why because this token carrying only permission authorization what they can do for only to read to do's right if they want to delete the to-do they need to get a new token from the authorization server which has a permission or a scope for a delete to do okay so i'm sorry i didn't have any any diagrams or any animation no any fancy things you to explain that but it's it's simple to demonstrate okay but i hope you understand scope is not a fancy thing it's just a permission right it's it's it's how old uh tells the application what they can do okay so this is i was thinking this is like a 10 minutes video but looks like it went um over 30 minutes i'm sorry about it but i hope you learn a lot then we'll see you in the next video make sure you subscribe and click on the bell icon as well don't forget to share the video stay safe take care until we see again

Channel: Krish Dinesh

Views: 1,211

Keywords: oauth2 explained, oauth2 authorization code flow, oauth2 vs jwt, oauth 2.0, oauth2 and openid connect, oauth2 authentication, oauth2 api authentication tutorial, oauth2 basics, oauth2 client credentials flow, oauth2 code flow, oauth2 example, oauth2 flows, oauth2 how it works, oauth2 jwt, oauth2 latest version, oauth2 microservices, oauth2 multiple scopes, oauth2 openid connect, oauth2 openid, oauth2 oidc, oauth2 overview, oauth2 oidc flow, krish, krish dinesh, codelabs

Id: GTT-hg-F1Zo

Length: 31min 11sec (1871 seconds)

Published: Sun Oct 03 2021