I need a Microsoft course on hand writing illustrations backwards! Can we just take a moment and applaud this man's presentation skill. Ok, back to the video.
This is a great high-level explanation. I wanted to find something like this that I could share with my biz dev folks. This is just technical enough. Nicely done.
That's a very nice explanation of the authentication flow used when the server manages the sign-in process. The process described here is called server directed flow or simply server flow.
Good explanation. One point though. There are signing and verification keys for digital signatures similar to private and public keys for encryption. The signing key is kept private and the verification key is the one supplied to verifiers, here the web site, that can check the signature because the keys are basically inverses of each other. So at around 3.10, the web site uses the verification key to validate the signature not the signing key that must be kept private
I think the token is returned in response to the POST request which the browser is making to the Idp . As described in the video the token should not be a part of POST body , rather the token is returned as response to the POST . The POST body contains the credentials that is required for Alice to sign in
Great explanation sir, can I ask how the website can verify token t? i.e. the website and the IdP would have to share their knowledge on token t beforehand? And shouldn't this token t be renewed/refreshed per use (i.e. nonce) to prevent replay attacks?
This video seems super simple and explains the logic but misleads the understanding the correct concept. In modern authentication code flow, token is requested and responded through the back channel. That means, Browser is actually getting the authentication code (which is for getting the token) then sending the code to the Web site. After that Web site is requesting the token from Idp with authentication code+client secret in a POST request in a back channel. Back channel means not using the Alice's browser but direct request from Web site to Idp.
How does the IdentityProvider send a POST request to the browser though? I thought AAD used a GET request, similar to redirect, with an access_token query param...
3:04 - We really need some better resources for the step required here. Finding the openid-configuration and subsequent jwk_uri was difficult as someone unfamiliar with the spec. The validation steps were also confusing given the way the public key was encoded strangely. If there are helper functions available for this step with the MSAL library it would be really appreciated. If they do exist and I just couldn't find them then the docs need some serious improvement.
K2 is a signing key, not a cookie. The cookie C should be either: * encrypted (with K2), so that Alice can't modify it (if it contains for example the username) * be just a random number (session id), with the actual information (username) saved server-side, in a database/cache, where the key is the session id and the value could be the username and other attributes. The cookie C is designed to be used multiple times, so that is not relevant for "replay attacks". The request answer that comes from the IdP has an expiry date, so it can't be used forever.
what does it mean that the website has a trust relationship with the IdP? If the IdP is in a closed network, do we need to configure firewalls to allow communication between the website and IdP? or can this relations ship be built over exchanged certification files?
Not bad, you lost me a bit when you said Alice is at her browser and he's able to get a token from the IdP as I thought you'd already said it's the website she's trying to access that attempts to do that?
@1:50 how website know Idp address or point to sent request to client browser? how server know that browser has a relation with Idp? Can any one help me with the clarification for above questions ? Please
Hey there! The website has a trust with the Identity provider, and hence has the URL it needs to redirect the client to perform authentication. This happens using HTTP redirects. The user is redirected to the IDP to get authenticated post, which the tokens are returned to the browser/application. Here are some documents for reference. msft.it/6059n1nff and msft.it/6050n1nfA
I need a Microsoft course on hand writing illustrations backwards! Can we just take a moment and applaud this man's presentation skill. Ok, back to the video.
1. Write normally on glass.
2. Flip video horizontally.
3. ???
4. Profit
Nice, such a simple solution for my over thinking LOL @@AndreiDamian
Superb explanation! Instructors like him make technology interesting...
This is a great high-level explanation. I wanted to find something like this that I could share with my biz dev folks. This is just technical enough. Nicely done.
That's a very nice explanation of the authentication flow used when the server manages the sign-in process. The process described here is called server directed flow or simply server flow.
I appreciate the whole series on this topic. helped me a lot. Thank you very much!
Wow. Awesome explanation! Thank you 😎👍
Good explanation.
One point though. There are signing and verification keys for digital signatures similar to private and public keys for encryption. The signing key is kept private and the verification key is the one supplied to verifiers, here the web site, that can check the signature because the keys are basically inverses of each other. So at around 3.10, the web site uses the verification key to validate the signature not the signing key that must be kept private
These are great videos! I believe the playlist is actually in reverse order though.
Great. Very simple explanation!
Awesome explanation
Good content. But I wanna see the Behind-the-Scenes video on how they made him write on an empty space.
Awesome explanation..... 👏👏👏
This guy is brilliant
We're glad to hear that you enjoyed the video! 😀
I think the token is returned in response to the POST request which the browser is making to the Idp . As described in the video the token should not be a part of POST body , rather the token is returned as response to the POST . The POST body contains the credentials that is required for Alice to sign in
Great explanation sir, can I ask how the website can verify token t? i.e. the website and the IdP would have to share their knowledge on token t beforehand? And shouldn't this token t be renewed/refreshed per use (i.e. nonce) to prevent replay attacks?
This video seems super simple and explains the logic but misleads the understanding the correct concept. In modern authentication code flow, token is requested and responded through the back channel. That means, Browser is actually getting the authentication code (which is for getting the token) then sending the code to the Web site. After that Web site is requesting the token from Idp with authentication code+client secret in a POST request in a back channel. Back channel means not using the Alice's browser but direct request from Web site to Idp.
How does the IdentityProvider send a POST request to the browser though? I thought AAD used a GET request, similar to redirect, with an access_token query param...
3:04 - We really need some better resources for the step required here. Finding the openid-configuration and subsequent jwk_uri was difficult as someone unfamiliar with the spec. The validation steps were also confusing given the way the public key was encoded strangely. If there are helper functions available for this step with the MSAL library it would be really appreciated. If they do exist and I just couldn't find them then the docs need some serious improvement.
what is the use of the K2 cookie ? if someone gets a hold of the encrypted cookie just sending it in the request will validate said request, no ?
Agreed, I would like to know whether it is vulnerable to replay attacks and how authentication services can avoid that
K2 is a signing key, not a cookie. The cookie C should be either:
* encrypted (with K2), so that Alice can't modify it (if it contains for example the username)
* be just a random number (session id), with the actual information (username) saved server-side, in a database/cache, where the key is the session id and the value could be the username and other attributes.
The cookie C is designed to be used multiple times, so that is not relevant for "replay attacks".
The request answer that comes from the IdP has an expiry date, so it can't be used forever.
what does it mean that the website has a trust relationship with the IdP? If the IdP is in a closed network, do we need to configure firewalls to allow communication between the website and IdP? or can this relations ship be built over exchanged certification files?
I'm curious about this as well
Thank you very much :)
Thank you :)
Not bad, you lost me a bit when you said Alice is at her browser and he's able to get a token from the IdP as I thought you'd already said it's the website she's trying to access that attempts to do that?
He is writing backward! great skill!
No he's not, he is using a lightboard: ruclips.net/video/wCOuu0-o5YI/видео.html
Wow this is absolutely cool, but how could i could not clearly find it on 🤓
@1:50 how website know Idp address or point to sent request to client browser? how server know that browser has a relation with Idp?
Can any one help me with the clarification for above questions ? Please
Hey there! The website has a trust with the Identity provider, and hence has the URL it needs to redirect the client to perform authentication. This happens using HTTP redirects. The user is redirected to the IDP to get authenticated post, which the tokens are returned to the browser/application. Here are some documents for reference. msft.it/6059n1nff and msft.it/6050n1nfA
i think he's writing with his right hand
Alice and i will get on. She shaves her head everyday like me.😊