outstanding playlist ! I struggled to understand this OAuth flows and OpenId during 2017. I wish this video was there at that time. The original website has too many technical terms to understand easily.
Fantastic video. I never understood the difference between the two and now it makes more sense... OIDC is just OAuth with additional scopes. A video request: How does SAML differ from this? Why don't companies and applications using SSO just use OIDC instead of SAML?
in principle yes. SAML is similar, but it is XML based. I haven't really used it before. SAML is supported for SSO for example in Azure Active Directory. It is supported because it came before OIDC
Thank you very much for this video. Very precise. Have doubt when we ask for ID token what is the next work flow looks like ?.. I know for access token client application send it with each request to resource sevrer in order to get the resource of a usser. But with ID token how client application react? Is it going to ask the client information from resource sevrer or it will directly use the iD token for storing users info . Thanks
The id token contains identity information of the end user for example email etc. It is a JWT, so base64 url encoded. I.e. you would decode the base64 url encoded token and get the identity information for your app
So you're saying it's just for displaying something immediately on the callback UI to reduce API calls? seems pretty pointless unless it's does something else.
great video, but a question: what if my app uses stateless authentication with jwt, and has single sign on feature that uses gmail to authenticate, i just don't know, does the app use the gmail's generated jwt instead of its own jwt ? and how do i keep the user signed in, do i store the access token in a cookie ? or is that even safe ?
it depends how you use the Login with Google functionality and whether you have a backend. If you don't have a backend, well then you need to store the JWT somewhere in the FE, even though that's less secure. Most of the time you will probably have a backend. Theoretically you could put the ID token in an in an HTTPOnly, Secure cookie and pass it to the FE and then validate the signature when the cookie comes to the backend. Putting it in a cookie is certainly more secure than just returning it as a response. However, validating the signature with the Google public key on your backend would not be enough, you would also need to validate the aud claim for example. Otherwise anyone who would have a valid ID token for a user (e.g. a third party app) could impersonate the user. There are also a couple of other issues: 1. JWTs do not make good session tokens and you would need server side state on your app or you would need to hit the token introspection endpoint for every request to make sure that you can log someone out from the server side. I made a dedicated video why JWTs do not make good session tokens. 2. you do not have control over how long the ID token is valid 3. If you use the ID token as session token, you would not be able to add any session data in the token because only Google has the private key. If you want to add your own data, then you would need to sign your own JWT. But again, JWT are actually not well suited for session tokens. If you have your own session storage or issues JWTs from your server, you can make the session as long as you want. If you actually need to access a specific Google API, then you need a refresh token, but if you use Google to only get the email address of the user (thereby avoiding that you need to store a password), then you probably don't need a refresh token
I'm a little confused with your explanation. Typically, authentication precedes authorization. I cannot authorize someone unless I know who they are, i.e. authenticated.
You can authorize actions without knowing who the person is. E.g. if you have a hotel card that gives you access to the gym or the spa, then the door you hold the card against does not know who you are, it just knows that you have access to this room. Now ideally the door would also log who you are, but strictly speaking not required. I.e. you can enforce authorization without authentication and this is what OAuth does (OAuth = Open Authorization)
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
I've been in the game 23 years and find these concepts truly difficult to understand but you do a great job. Thanks
Glad to help!
outstanding playlist ! I struggled to understand this OAuth flows and OpenId during 2017. I wish this video was there at that time. The original website has too many technical terms to understand easily.
thx, I'm glad you found it useful
I have an interview that requires this implementation
Thank you
Great explanation and very useful for no.coders PMs and POs. Thank you for sharing!
Fantastic video. I never understood the difference between the two and now it makes more sense... OIDC is just OAuth with additional scopes.
A video request: How does SAML differ from this? Why don't companies and applications using SSO just use OIDC instead of SAML?
in principle yes.
SAML is similar, but it is XML based. I haven't really used it before. SAML is supported for SSO for example in Azure Active Directory. It is supported because it came before OIDC
Thank you very much for this video. Very precise. Have doubt when we ask for ID token what is the next work flow looks like ?.. I know for access token client application send it with each request to resource sevrer in order to get the resource of a usser. But with ID token how client application react? Is it going to ask the client information from resource sevrer or it will directly use the iD token for storing users info . Thanks
The id token contains identity information of the end user for example email etc. It is a JWT, so base64 url encoded. I.e. you would decode the base64 url encoded token and get the identity information for your app
Great explanation. Thanks
Thanks for the simple explanation.
Glad it was helpful!
Brilliant and very simple explanation ☺️
Glad it helped!
Great explanation.
Glad you liked it
Excellent video and amazing content details explanation, it really helped a lot in clarifying the concepts.
Glad you enjoyed it!
Very good explained!!!
Glad you liked it
i got basic idea, but not so clear, i need the example of open id authorization
Great Video 🙂
Thanks! 🙂
So you're saying it's just for displaying something immediately on the callback UI to reduce API calls? seems pretty pointless unless it's does something else.
It tells you who the end user is. OAuth only tells you what the end user can do
great video, but a question:
what if my app uses stateless authentication with jwt, and has single sign on feature that uses gmail to authenticate, i just don't know, does the app use the gmail's generated jwt instead of its own jwt ?
and how do i keep the user signed in, do i store the access token in a cookie ? or is that even safe ?
it depends how you use the Login with Google functionality and whether you have a backend. If you don't have a backend, well then you need to store the JWT somewhere in the FE, even though that's less secure.
Most of the time you will probably have a backend. Theoretically you could put the ID token in an in an HTTPOnly, Secure cookie and pass it to the FE and then validate the signature when the cookie comes to the backend. Putting it in a cookie is certainly more secure than just returning it as a response. However, validating the signature with the Google public key on your backend would not be enough, you would also need to validate the aud claim for example. Otherwise anyone who would have a valid ID token for a user (e.g. a third party app) could impersonate the user. There are also a couple of other issues:
1. JWTs do not make good session tokens and you would need server side state on your app or you would need to hit the token introspection endpoint for every request to make sure that you can log someone out from the server side. I made a dedicated video why JWTs do not make good session tokens.
2. you do not have control over how long the ID token is valid
3. If you use the ID token as session token, you would not be able to add any session data in the token because only Google has the private key. If you want to add your own data, then you would need to sign your own JWT. But again, JWT are actually not well suited for session tokens.
If you have your own session storage or issues JWTs from your server, you can make the session as long as you want. If you actually need to access a specific Google API, then you need a refresh token, but if you use Google to only get the email address of the user (thereby avoiding that you need to store a password), then you probably don't need a refresh token
I'm a little confused with your explanation. Typically, authentication precedes authorization. I cannot authorize someone unless I know who they are, i.e. authenticated.
You can authorize actions without knowing who the person is. E.g. if you have a hotel card that gives you access to the gym or the spa, then the door you hold the card against does not know who you are, it just knows that you have access to this room. Now ideally the door would also log who you are, but strictly speaking not required. I.e. you can enforce authorization without authentication and this is what OAuth does (OAuth = Open Authorization)
Help me
Open id