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
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.
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
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.
this video explains SAML and OAuth in a simple way, thank you.
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.
Great explanation. I've always had difficulties when it came to explaining to someone the differences.
You made it simple and clear
Thanks a lot. These topics have never been so easy and simple before I watched this video.
I would be clueless without people like you! thank you!
Best! Best!! Best!!! Explanation!!!! Thanks a lot for this!!!
This is concise and easy to understand! Thank you!
With basics cleared by you, I can explore more...
That was very well explained, thank you.
Good Explanation. Keep go Mike.
Very nicely explained. Thank you !
Nicely explained !! Thank you
thank you so much!!!!!!
Amazing Video. Thank you so much
Thanks a lot very well explained
Hi Michael, like the way you simplify things. Could you bring in JWT too please.
Thank you from S.Korea
Got it!! Thanks
Thanks! that cleared out some basic stuff so I can go to deeper stufff
It made things more clear bro. good video
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?
thank you sir.. it was very beneficial to a beginner like me..
Whats the meaning of NWA?
Does it mean Network wide area????
Thank you, this is what I was searching for 👍
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
very clear. Thanks!
Thanks for the great explanation!
short and simple
Thank you for sharing, great content!
Nice thankyou
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.
MUITO BOM!
Great Explanation! Thank you!
Nice clear into. Thanks for putting this together. Do you have a play list on each of these?
very easy and well explained , Thank u :)
Thanks! Good video!
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
Perfect, thank you
Good explanation!
gold mind here
well explained
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.
java code for SSO setup
are you sure that the user know the terms of service? lol
ok
ssio, nutööö