This video introduces the protocol flow when a user signs into a web application protected by Azure AD.
- [Narrator] Let's begin by understanding how is a web application secured by Azure AD. Now this Azure AD may be associated with your Office 365 tenancy or not. It really doesn't make a difference. In Office 365 tenancy Azure AD is just any other Azure AD. So it all starts by the user opening a browser and visiting your web application. This web application should be accessible over an HTTPS URL.
It doesn't even need to be hosted on the open Internet. As long as the user can resolve it and access it. So the user makes an anonymous request to this web application and then this web application says, "Hey, you're not authenticated." and it'll send the user a sign-in request which will redirect to the Azure AD and it includes something called the App ID URI of the application. The App ID URI of the application is a unique identifier for your application.
It's just a string but it allows Azure AD to identify your web application from somebody else's web application. Now the reason this is important is because you have to preregister your web application with it's URL inside of Azure AD. So your Azure AD knows who it provides authentication for. At this point, the user is redirected to the Azure AD authentication end point. This is just the user interface you use for signing in and if your Azure AD is configured with federation, you'll be redirected to your ADFS end point for instance but all of that is irrelevant to us developers because no matter how you authenticate, you authenticate to Azure AD using a web based user interface and then Azure AD will post back a security token to the preregistered reply URL of your web application.
Now you see why Azure AD needs to know about your application ahead of time because it needs to know where to send this token to. Think of it as a white list that it doesn't want to send the security token to somebody it doesn't trust, right. So you need to have this URL preregistered and you supply this URL when you register your application. And when this security token is sent back to your web application, at that point the web application can validate that token.
And this token allows us to set up a cookie which maintains session with the user. So, from this point onwards it is a cookie based session. So this is a cookie-based token which means the web application maintains the session based on a cookie. And the session expiration can be controlled with the lifetime of the cookie. Standard web based concepts apply. And when the session expires, in other words, the cookie expires, the user simply has to sign in again. The advantage here is if the user is signed in to Office 365 already, visiting your website will sort of give the user a single sign on like experience because all those redirects will happen but the user will not see a login URI because the user is already authenticated.
- What is Microsoft Graph?
- Registering a web application in Azure AD
- Adding authentication logic and authentication UI
- Native applications calling Graph
- Reviewing scenarios where web apps involving Graph are useful
- Web applications with application identity and delegated identity calling Graph
- Daemons calling Graph