Right people often get confused between terminologies. SSO is one of the security/access feature/application which uses OAuth/SAML for it's implementation. Also OAuth- is basically an AuthoriZATION protocol! The IDP simply shares a secret key called *token* for the 3rd party API to use it to get access to the requested resources. OAuth just like a proxy, like you give your house key to one of your friends and ask her to get something from your living room, but rest of all other bed rooms are locked and the keys are not shared. OAuth doesn't share user info to the API. Authorization is grated to the API which has the *token* but rest assured it's has signature verification to see it's not tampered with. SSO is much more serious w.r.t security and detailed access control. SSO- works as AuthoriZATION, Identity and ACCESS. IDP shares a kind of CLAIM/CERTIFICATE which has UserInfo, Services he/she has access to, things he/she can do according to the roles. This video explains things and it's differences in plain English for people to understand it easily.
00:26 SSO is an agreement between 3 different entities 00:32 people 0:34 the applications that they are trying to access 0:36 the governing body - identity provider, or the IDP 00:56 the very minimum: you should be able to change your own password, and the password should work everywhere *1:03** the IDP is the place that takes the information, holds on really tightly and really securely **1:12** adds additional information about your identity **1:22** then then combination of user information and idp information is then securely passed on to aSERVICE PROVIDER* 1:31 service provider is an application generally 1:58 one of the places we get tripped up a lot of time 2:02 confusion on the concept of SSO and the different kinds of protocols we can use 2:10 to create a SSO experience 2:12 3 main ways of logging into the system: 2:16 Basic Auth 2:23 OAuth 2:31 SAML 4:06 OAuth in the API world 8:14 what is IDP
MFA is part of the identity authentication layer. It's not part of OAuth or SAML but rather part of identity access management challenges that prove you are you before a SAML assertion or OAuth token is issued. IAM systems may be queried over an API by the service providers to find out when you proved you were you and with what method (password, OTP, or a combination for MFA) but that's outside of the spec. Regardless, MFA is always just a way to double-check identity, but really has nothing to do with enforcement
About a purpose of IdP: as I understand in a minimal schema it should only verify the entity identity (authentication) and authorization can be on the service provider side. But in the video IdP does both: authentication and authorization, which looks strange: imagine that we have 10 applications and they have different roles, in such case IdP needs to manage that all, then more, what if I decide to add a new role to one of my applications? Please comment, thanks in advance!
Actually the IDP does not do authorization. I know the video makes it look like it does but what happens is the Gateway or the application itself asks the IDP for the information that it needs to make that assertion. You can't do authorization without Authentication, and authentication provides the information, the actual details required for authorization
05:33 and every single time that web application makes a call to that API the API will verify that key against the IDP against the keystore and see if it's still valid and it should get scopes back with that... the whole point of a token is that you don't have to communicate with 3rd party each time API call is made.
The typical Oauth flow you describe on 4:52 seems to be of public client, then later when u introduced API, then you kinda switched to confidential client. You should not mix these 2 use cases together.
That' a good callout -- the presentation is, of course, more of a high-level about SSO, not OAuth spec, but if I were to redo it today, I would also want to talk about informing JWTs and how confidential clients (trusted entities) might have elevated interactions with the Identity flow.
Right people often get confused between terminologies.
SSO is one of the security/access feature/application which uses OAuth/SAML for it's implementation.
Also OAuth- is basically an AuthoriZATION protocol! The IDP simply shares a secret key called *token* for the 3rd party API to use it to get access to the requested resources. OAuth just like a proxy, like you give your house key to one of your friends and ask her to get something from your living room, but rest of all other bed rooms are locked and the keys are not shared. OAuth doesn't share user info to the API. Authorization is grated to the API which has the *token* but rest assured it's has signature verification to see it's not tampered with.
SSO is much more serious w.r.t security and detailed access control. SSO- works as AuthoriZATION, Identity and ACCESS. IDP shares a kind of CLAIM/CERTIFICATE which has UserInfo, Services he/she has access to, things he/she can do according to the roles.
This video explains things and it's differences in plain English for people to understand it easily.
00:26 SSO is an agreement between 3 different entities
00:32 people 0:34 the applications that they are trying to access 0:36 the governing body - identity provider, or the IDP
00:56 the very minimum: you should be able to change your own password, and the password should work everywhere *1:03** the IDP is the place that takes the information, holds on really tightly and really securely **1:12** adds additional information about your identity **1:22** then then combination of user information and idp information is then securely passed on to aSERVICE PROVIDER*
1:31 service provider is an application generally
1:58 one of the places we get tripped up a lot of time 2:02 confusion on the concept of SSO and the different kinds of protocols we can use 2:10 to create a SSO experience
2:12 3 main ways of logging into the system:
2:16 Basic Auth
2:23 OAuth
2:31 SAML
4:06 OAuth in the API world
8:14 what is IDP
Wonderful! Thanks mate.
this video explains SAML and OAuth in a simple way, thank you.
Great explanation. I've always had difficulties when it came to explaining to someone the differences.
You made it simple and clear
I would be clueless without people like you! thank you!
Thanks a lot. These topics have never been so easy and simple before I watched this video.
Best! Best!! Best!!! Explanation!!!! Thanks a lot for this!!!
With basics cleared by you, I can explore more...
This is concise and easy to understand! Thank you!
Hi Michael, like the way you simplify things. Could you bring in JWT too please.
That was very well explained, thank you.
Good Explanation. Keep go Mike.
Very nicely explained. Thank you !
Thanks a lot very well explained
thank you so much!!!!!!
Amazing Video. Thank you so much
Nicely explained !! Thank you
Thank you from S.Korea
Got it!! Thanks
thank you sir.. it was very beneficial to a beginner like me..
Nice clear into. Thanks for putting this together. Do you have a play list on each of these?
Thanks! that cleared out some basic stuff so I can go to deeper stufff
Great tutorial. Thanks.
02:25 OAuth is API based, not intended only for web application.
so OAuth can be used for other non-web client/applications for SSO purpose?
short and simple
It made things more clear bro. good video
Nice thankyou
very clear. Thanks!
Thank you for sharing. Just curious where does MFA fall in? Oauth or SAML
MFA is part of the identity authentication layer. It's not part of OAuth or SAML but rather part of identity access management challenges that prove you are you before a SAML assertion or OAuth token is issued.
IAM systems may be queried over an API by the service providers to find out when you proved you were you and with what method (password, OTP, or a combination for MFA) but that's outside of the spec. Regardless, MFA is always just a way to double-check identity, but really has nothing to do with enforcement
MUITO BOM!
About a purpose of IdP: as I understand in a minimal schema it should only verify the entity identity (authentication) and authorization can be on the service provider side. But in the video IdP does both: authentication and authorization, which looks strange: imagine that we have 10 applications and they have different roles, in such case IdP needs to manage that all, then more, what if I decide to add a new role to one of my applications? Please comment, thanks in advance!
Actually the IDP does not do authorization. I know the video makes it look like it does but what happens is the Gateway or the application itself asks the IDP for the information that it needs to make that assertion. You can't do authorization without Authentication, and authentication provides the information, the actual details required for authorization
Whats the meaning of NWA?
Does it mean Network wide area????
Thanks for the great explanation!
Thank you, this is what I was searching for 👍
Thank you for sharing, great content!
very easy and well explained , Thank u :)
Great Explanation! Thank you!
gold mind here
Thanks! Good video!
Good explanation!
Perfect, thank you
well explained
05:33 and every single time that web application makes a call to that API the API will verify that key
against the IDP against the keystore and see if it's still valid and it should get scopes back with that...
the whole point of a token is that you don't have to communicate with 3rd party each time API call is made.
In OIDC you can validate the JWT locally, but in traditional OAuth the bearer token is just a key that needs to be verified by the API gateway.
The typical Oauth flow you describe on 4:52 seems to be of public client, then later when u introduced API, then you kinda switched to confidential client. You should not mix these 2 use cases together.
That' a good callout -- the presentation is, of course, more of a high-level about SSO, not OAuth spec, but if I were to redo it today, I would also want to talk about informing JWTs and how confidential clients (trusted entities) might have elevated interactions with the Identity flow.
ssio, nutööö
java code for SSO setup
ok
are you sure that the user know the terms of service? lol