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
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.
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)
