 Even though Microsoft retired the MS600 exam and the associated Microsoft 365 Developer Certification in March 2023, you can still use the free self-paced resources that they provided to learn how to build solutions with Microsoft Identity and Azure AD. In this video, I'm giving you my entire guide that walks you through these free resources, including lectures, hands-on labs, and videos. Hi, I'm Andrew Coll, and if you're new here, be sure to hit that subscribe button to stay up to date on all my videos for web and cloud developers on Microsoft 365 and related topics. And while you're at it, make sure you subscribe to my newsletter to get insights and the latest news in the world of Microsoft 365 for web and cloud developers. I've got a link to it here and the one in the description below. Before we get started with this, I wanna set some context on what this video is going to cover. And while this only takes a moment, if you're familiar with the history of my MS600 exam prep for self-paced learning about building apps that leverage Microsoft Identity or more specifically Azure AD for self-paced learning on Office Add-In Development. I've got chapters for everything. I created an exam prep course for the MS600 exam building applications and solutions with Microsoft 365 core services that hundreds of developers had used to prepare for and pass the exam. Microsoft used the exam to measure a developer's knowledge around a few Microsoft 365 workloads, things like SharePoint, Microsoft Teams, Azure AD, Microsoft Graph and Office Add-Ins. But when Microsoft retired the exam in March 2023, I was left with this course that served as a guide for all those free self-paced study resources that developers could use to prepare for the exam. I can't sell that. No one could buy it would buy that course or more importantly, I can in good conscience sell it because the exam doesn't exist anymore. But here's the thing, the course content is all still valid. It's a self-paced guide on how to learn various things. Like what you need to know to be a qualified developer building apps that leverage Microsoft Identity and Azure AD. So I've decided to release the chapters for each of the different workloads here on my channel. That's what you're about to watch. Note that there are parts of the video where I refer to the exam. Just know that the exam, I'm referring to the MS600 exam. That's retired at this point and it's no longer available to take. Also throughout this video, I'm going to reference a lot of online resources like documentation, training modules, videos, hands on labs. The links are all in the video but I've also compiled them in a single downloadable PDF and you can get this from the link in the description below the video. It's all on my site. Okay, enough with the explanation out of the way. Let's dive into learning about the free self-paced resources for learning about building apps that leverage Microsoft Identity or more specifically, Azure AD. Microsoft Identity is the marketing label that Microsoft uses for the entire identity platform from Microsoft. And it includes the following things. It supports authentication for MSA accounts which are Microsoft personal accounts including those that you use to log in to things like Skype, Xbox and Outlook.com. Azure Active Directory, which is also referred to as Azure AD or AAD and these are commonly referred to as work and school accounts and then Azure AD B2C which is also referred to as business to consumer or business to customer. It also implements OAuth2 and OpenID Connect to help support different multiple authentication scenarios. It also includes open source libraries with multiple variations of these different open source libraries. The most current version is the Microsoft authentication library also known as MSAL. MSAL replaced the previous library which is Azure AD authentication library which we knew of as ADAL. I'll talk more about MSAL later in this chapter. The identity management portal is located at HTTPS, colon whack whack, aad.portal.azure.com and it's the same management portal for Azure AD that you've accessed to within an Azure subscription except they wanted to make it available to anyone who can manage the tenant without needing a full blown Azure subscription so they created this extra little interface. Microsoft Identity also includes an API, PowerShell Commandlets and commands in the Azure CLI that enabled the creation, management and all the configuration of Azure AD applications. And finally, Microsoft Identity also includes loads of developer content such as documentation, a glossary of terms, quick starts and plenty of tutorials used to educate developers on the platform. Now let's take a minute to explore what lessons that you're gonna find in this chapter so that you can know what to expect as you proceed through the Microsoft Identity chapter. In this current overview lesson, you've learned what the Microsoft Identity workload is all about. On the next slide, I'm gonna wrap up this lesson with some additional learning resources and be sure to check the notes on this lesson under the video below for a collection of all the external resources and references that I'm gonna use throughout this chapter. The Microsoft Identity workload is huge, but you don't need to know everything about this topic in order to pass the exam. So in the next lesson, I'm gonna call out specific things that you need to focus on as well as things that you can ignore as they aren't relevant to the exam. In the next two lessons, I'm gonna go through all the various core identity topics and authentication flows that are supported by Azure AD that you should be prepared to answer questions about on the exam. Next, we'll look at how you can create and configure Azure AD apps using the Azure AD portal. This lesson will cover how to manage who has access to the app using things like users, groups, and app roles. One component or one key component of Microsoft Identity and apps are the different types of permissions as well as the consent framework. Now I explain this in this lesson what you need to know about these different topics. And in the last lesson, you're gonna learn what you need to know when it comes to configuring custom apps and APIs that you're gonna build to be secured and leverage Azure AD at least to the extent that you're gonna be tested on the M65 exam. And just like all the other chapters in this course, I'm keeping the depth of the explanation to the level that you need to know in order to pass the exam. I'm not trying to go too deep with my explanations because this is an exam prep course. It's intended to teach you, it's not intended to teach you everything about each one of these different topics. There are plenty of other resources that are available to you that you can leverage if you are familiar with a particular topic. And when I cover something in the course, you may think, okay, I got it. I'm comfortable with my knowledge on this topic. But if you think to yourself, I don't get it. Or if you are familiar with a process or an API that I cover, then you should go read up on the official documentation or study one of the multiple resources that I'm referencing throughout this course to make sure that you are adequately familiar with the topic prior to taking the exam. Now reference specific resources throughout the course, but like I said before, be sure to check the notes for this lesson under the video below for a collection of all the external resources that I use throughout this entire chapter. But on this slide, I want to quickly run through the Microsoft learning resources that I'm providing and explain what's in each one of these things. The first group of links are around Microsoft learning and they have learning paths and modules and a learning path is a collection of modules that have been strung together. The learning path for Microsoft identity is called implement Microsoft identity associate and it contains the modules used for self-paced study to study for the exam. And then we have five modules that cover various topics that I'll reference throughout this chapter. All of these modules contain hands-on labs. So if you want to practice some of the topics like if you need to be more familiar with them prior to the exam, then that's a great place for you to use a great resources for you. These modules are as follows. Getting started with Microsoft identity, application types in Microsoft identity, permissions and consent framework, secure custom APIs with Microsoft identity and then finally work with users, groups and roles and custom apps and APIs. Now Microsoft identity contains a ton of documentation as well on their site. The two links that I want to call out here is the homepage that's titled what is the Microsoft identity platform and the glossary of terms. Okay, that wraps up the overview lesson. In this lesson, we're going to tackle some of the core identity topics. It's sort of a random grab bag of terms of things that you need to understand. You need to know the difference and the relationships between the application object and the service principle. When you create an application in Azure AD, you're creating an application object under the covers. This object resides within the Azure AD tenant where the application was registered and this is also known as the application's home tenant. The application object is used as the template to create service principles and this object describes three aspects of an application. It includes, number one, how it can issue tokens in order to access the application. Number two, resources the application might need to access and number three, actions the application can take. The application object is the global representation of your application for use across all tenants. Now, the service principle object is created in every tenant where the application is actually used. To access resources secured by Azure AD tenants, the entity that wants to access must be represented by a security principle. For users, these are user principles while applications are represented by these service principles. Now, it defines the access policy and the permissions for the application within the Azure AD tenant. A service principle is the local representation or the application instance of a global application object in a single tenant or a directory. This relationship between the application object and the service principle object can be thought of as similar to traditional OOP concepts or object oriented programming concepts. The application object is like a class while the service principle object is an instance of the class. Now, let's look at an example for a second here. Now, this picture is going to represent both a single tenant app or a multi-tenant app. So let's just focus on the single tenant app first. So that's the top part that you see there on the slide, just the boxes that are covered in like a blueish green. We're in a tenant called the addendum tenant, all right? And we have an application that we've defined called the HR app. Now, that app when it was created, got its own application object. That's like the definition of the application, the name, some permissions that it needs, et cetera, all those kinds of things and the different configuration settings on it. When I created the application inside my tenant, it automatically also created a service principle because an application can always be used by the people in the tenant where the application was actually registered. So you see there I have a service principle as well and this application is going to access the sum resource. Now, let's just say that this was a single tenant app. No other tenant or another way to say it is that no other users in any other tenant are going to be able to log in and use this application. Only users in the addendum tenant are going to be able to use it. But if when I registered this application, I registered it as a multi-tenant application, then what happens is that when I go to use the application in another tenant, like you see there at the bottom from Contoso or Fabrican, what Azure AD is going to do is that when I grant the permission access or permissions inside of my tenant, Microsoft is going to create a service principle which is like a copy of the application definition inside of these other tenants. So it's not getting a copy of the application definition, it's actually getting a service principle which is like a representation or use the application definition as the template in a way to create the service principle. The service principle is the thing that is actually going to be defining the permissions and stuff that say what we can actually do or the fact that it's been consented to be able to be used inside of this tenant. Now let's talk about OpenID Connect. This is an authentication protocol that is built on top of the OAuth2 protocol. This allows you to implement a single sign-on using OAuth. And this is made possible because the OpenID Connect extends the OAuth2 authorization protocol for use as an authentication protocol. It introduces the concept of an ID token that's used to identify a user. You should be familiar with OpenID Connect for the exam but you don't need to know all the parts of the protocol. Just understand how it fits into the picture with respect to Microsoft identity, how it's used to implement SSO and what ID tokens are. Let's take a look at the sequence diagram, the UML sequence diagram of what OpenID Connect looks like. So you see here we have the browser which think of that as like the user. I'm sitting on my laptop and I've got the browser open and I wanna go access some website. So that's at the web server on the far right. Well in the middle is Azure AD. So that's the authorization endpoint that you see there on the dotted vertical line right down the middle. So let's say I wanna use this application. So first step, I'm gonna navigate to some web app that's over on that web server. The web server is gonna notice you're not logged in. So I need to know who you are. And so what it's gonna do is it's going to send a response back to the browser that says you need to go log in which is really just a redirect back to send me back to the authorization endpoint to go log on using the Microsoft identity platform. So I enter in my username and my password and if I've got it set up, multi factor off as well. Maybe I'm using a security token, bunch of different options there. And if I've never used the app, I'm gonna have to go consent to the permissions that the app is gonna be requesting. And we'll look at that when we talk about permissions and consent in a later lesson. Once I successfully log in, Azure AD is gonna redirect, is gonna send a response back to me, back to my browser that's gonna say you need to be redirected back to the web server. But when it does that, it's gonna include the ID token. And that ID token is gonna be sent over to the web server where I'm being redirected to. The web server can then use that ID token to figure out things like what's my name, what's my email address, simple stuff like that to where I can then create an account and render a page that's a secure page back to the user. Maybe it needs additional permissions, maybe it needs additional data. That can all be done using an access token, but this is just the ID token that just identifies who the user is that they've actually signed in based on what Azure AD knows about this user. Now let's talk about resource servers and resource owners. The resource owner is an entity that is capable of granting access to a protected resource. So for example, I am the resource owner of my Microsoft 365 mailbox in Exchange Online. My mailbox in Exchange Online, that's the resource. Now resource server is gonna host the protected resource. So for example, the Microsoft Graph API is a resource server that provides access to my Exchange Online mailbox, which is the resource. That's the thing that contains my email and my calendar. Now let's talk about different types of security tokens that are involved in Azure AD applications. None of these are defined by Azure AD or Microsoft. Rather, they are all defined as part of the different authentication protocols and specifications as defined in the OAuth2 spec. Now all tokens in the Microsoft Identity Platform are implemented as JSON web tokens. This is also referred to as JWTs or Jot Tokens is how they're pronounced. These token contains claims which are assertions or name value pairs about an identity such as the resource owner. They're relied on for multiple use cases. Security tokens are relied on within Microsoft Identity for multiple things. Applications can validate tokens, identify the tenant the token is intended for, which we also refer to as the audience of the token, to display user information or to determine what the user can do. Now let's look at a few different types of tokens. Access tokens are issued by authorization servers and used by applications to determine access to a protected resource. They contain claims that define what the user has been granted and consented to do within a resource. So for example, one claim contains the scopes or permissions, a user has been granted to Microsoft Graph such as mail.read. You commonly see these referred to as user plus app or app only access tokens, depending on the scenario where they're being used. And as I previously covered, the ID token that's defined by open ID connect, it contains the claims pertaining to the authentication of an end user. And unlike an access token, these aren't used for purposes related to resource access and access control. Now a refresh token, now that's issued by an authorization server and it's used by an application to request a new access token. This is commonly done prior to the access tokens expiration date. Unlike access tokens, refresh tokens, they can be revoked. Now an authorization code, these are short-lived strings. They're created by the authorization endpoints and they're used in the authorization code flow for the OAuth2 authorization grants, something we're gonna look at in a later lesson. Now while it's not really a token, you can think of them as a kind of a token because these are short-lived strings that are returned to client apps in response to an authentication process. They indicate that the resource owner has delegated authorization to access the requested resource. The application commonly redeems this code with the token endpoint in exchange for an access token. There are two types of clients defined in the OAuth2, confidential and public clients. And the difference between the two is really defined by the client's ability to maintain the confidentiality of the app's credentials. Now Azure AD application credentials consist of an ID like a login name for a user and either a secret or certificate like a password for users. Now the most common example of a confidential client is like a web application. And in this scenario, the application code runs on a web server that's not accessible by the end user. Within server side code, the application can keep the clients or web applications credentials private. The client's ID is not necessarily a secret and it needs to be protected, but the client's secret or certificate should be. Confidential clients can keep these secrets. Well, they can keep them confidential, hence the name. Now on the other hand, public clients can't keep the app's secrets confidential. Some examples of these include single-page applications also known as desktop or mobile apps. Now the reason these are considered public clients is because the code for the application runs on the user's device. And so it's not fully protected. It's not fully secure because it can't be in full control of the device developer or the application owner. In the case of a single-page app, that's the user's browser. Or if it's a native app, that's the user's desktop or laptop or tablet or phone. Okay, so that wraps up some of the core identity topics that you're gonna need to know. In this lesson, we're gonna take a look at the OAuth 2 authorization flows supported by Azure AD. Now you should be familiar with all of these, how they work, compare and contrast them as well as what app scenarios they would make the most sense for. Now one point before I get started, remember what I said in the previous lesson that Microsoft learning modules don't cover these topics because the Microsoft Identity team didn't think developers should focus on these, rather they should focus just on the MSAL and Microsoft Identity.Web libraries. But if you weren't familiar with anything in this lesson, please refer to the links in the lesson notes for details on these topics because you will get questions that are related to the actual flows and you really should know how these flows work and the differences between them. You also need to understand about the different endpoints as well and that's what we're gonna go into on this slide. Before we dive into the OAuth 2 flows, we need to touch on these two endpoints. Now these endpoints implement the authentication flows defined in the OAuth 2 protocol specifications. There are two different endpoints. The authorization endpoint is used to interact with the resource owner to provide an authorization grant during the OAuth 2 authorization grant flow. Depending on the authorization grant flow used, the grant provided can either be an authorization code or it can be a security token. Now in most cases, this is the first stop in an interactive application authorization flow where a user authenticates with Azure AD using their credentials. The token endpoint is used by a user or an application to acquire an access token, a refresh token or an ID token. The admin consent endpoint, and this one's special, because tenant administrators are gonna be able to use this so that they can consent to the administrative permission request for an application. And I'm gonna talk more about admin consent in the lesson on permissions and consent framework later in this chapter. Now let's look at the different authentication flows. Now I'm gonna go over each one of these at a high level. Again, if you aren't familiar with them, I suggest you read up on them and the links I provide in the lesson notes. The authentication flows are the implicit flow, the authorization code grant flow, the device code flow, the client credentials flow, and then one called the on behalf of or OBO flow. Now let's take a few minutes to look at each one of these different things. The implicit flow is for single page applications and these type of applications run entirely in the browser and are considered public clients. What makes this flow unique is that the tokens, including the ID tokens and the access tokens are returned directly from the authorization endpoint that we covered previously instead of the token endpoint. Now remember, you're tested on the implicit flow, but the guidance today is to use the authorization code grant flow when you're doing a single page app. I'm gonna repeat something I said previously in this chapter. Remember that I said the implicit flow is no longer recommended by Microsoft and instead developers should implement the authorization code grant flow that has been updated to support single page apps. The reason is because the implicit flow relies on third party cookies. Many browsers are removing support for or blocking third party cookies and so because of this, the implicit flow is really no longer reliable. However, only MSalJSv2 supports the updated authorization code grant flow for single page apps. The MS600 exam at the present time still questions you on the MSalJSv1 release which still relies on the implicit flow. It doesn't understand how to use the authorization code grant flow in a single page app scenario. Now the authorization code grant flow, this code, this flow is used in apps that are installed on a device to gain access to protected APIs. These types of applications are usually considered confidential clients and this flow enables applications to securely acquire access tokens that can be used to access Azure AD secured resources, obtain refresh tokens and ID tokens for the current user. Now while you won't be tested on it due to the MSalJSv2 requirement that I mentioned with the implicit grant flow on the last slide, this flow has been updated to support something called proof key for code exchange, PKCE when this code is used in public clients such as single page apps or native client apps that is only supported in MSalJSv2. Now the next kind of flow, this is the device code grant flow. This is gonna enable an application to support a multiple device sign in process because the application using this flow runs on a user's device and this flow is commonly used only on public clients. The way that this one works, in this scenario, an application can pause for authentication to happen on another device. So like for example, when you log into the Azure CLI or input constrained devices like smart TVs or printers or IoT devices, the device will provide a URL and a code for the user to open on their phone, tablet or any other device. And while the user is going through the authentication process, the application is pulling the token endpoint for necessary tokens. If the user hasn't completed the authentication process, the token endpoint will tell the application how long it should wait before asking for the requested tokens again. But once the user completes the sign in process on the other device, the original application will receive the access token, the refresh token and the ID token. Now the next one is the client credentials grant flow. This is also referred to as two-legged OAuth which is used to access web-hosted resources by authenticating with just the identity of the application. Now unlike the other grant flows, the client credentials grant flow doesn't use an authorization endpoint, rather it goes straight to the token endpoint by providing its client ID in secret or certificate to obtain an access token. Also unlike the other flows, it only obtains an access token. You cannot get a refresh token in this scenario. This grant flow is commonly used in public clients specifically for applications that have no user interaction. For example, they are popular with primarily with services or daemon style applications. And because these applications use client credentials grant flow don't involve interactive users, they only really are only gonna really apply to application permissions, not delegated permissions. Don't worry, we'll talk about what those are and the differences between them in a later lesson. So this is what the UML sequence diagram looks like for a client credentials grant flow. You notice that it goes right past the authorization endpoint. It's not even listed here on the UML sequence diagram. You can see that it's just going straight to the token endpoint to obtain its credentials. Again, of course, it does have to go through and grant permissions and it does that using the admin consent endpoint. Something we'll talk about later when we talk about permissions, the different types of permissions. Now the last type of OAuth flow that's covered in the MS600 exam is the on behalf of flow. This flow, also referred to as OBO, addresses the scenario where an application is gonna call a service or an API that in turn needs to call another service or an API. So for example, let's say I have a web app that calls a custom API that is then gonna call Microsoft Graph. What this is gonna enable is propagating the authenticated user's identity through the entire chain of calls so the user's identity is delegated to the middle tier application or API. In order for this to work, the middle tier app request, the middle tier app requests an access token from the token endpoint using a specific grant type that's requested. And then it's gonna specify the client credentials for the middle tier app using like say a client ID and a client secret or certificate. Next, it's gonna enter the access token in the middle tier application received from the client. And then finally, it's gonna how the request should be processed. In this case here, we're specifying that it should be used on behalf of flow. Okay, so that's gonna wrap up my lesson on authentication flows that you need to know. And in this lesson, we're going to take a look at Azure AD applications, specifically the registration process, account types, securing them and how to manage access to these applications. So let's get started. Now, so far in this chapter, I've talked a lot about the different aspects with Microsoft identity core concepts related to identity and the various OAuth2 flows that Microsoft identity supports. But the centerpiece in Microsoft identity is the application. The application is what enables users or other applications to use the resource the application is associated with. Now, based on the permissions and other settings defined within the app's registration. Now applications are managed using the Azure AD management portal. And originally, this was only available to users with an Azure AD subscription through the portal. But today, you can also manage your Azure AD tenant through a limited version of the Azure AD portal. You can get it through the portal.azure.com or you can get it through aad.portal.azure.com. The second one is the more limited version of the portal of the Azure AD portal. Or really, it's just the Azure AD portal. It just doesn't include any of the other Azure resources. You need to go to the main Azure management portal to get to all of your resources there. Now, one important point that you must understand for the exam is the different application or account types. I talked a little bit about this in a previous lesson. I'm gonna go into a little more depth in it here on what the single tenant multi-tenant means. The two options relevant for Microsoft 365 and the exam are single tenant and multi-tenant. And this is the very first decision that you're gonna face when registering a new application. Well, okay, the second, the first one is what's the name of the app? It specifies if people within your organization can or can't use the application. A single tenant application is an application where only the users that belong to the same Azure AD tenant where the application is registered can use the app. The other option, multi-tenant, these are those applications that will allow any user with any Azure AD account, specifically a work and school account, can use the application, including different tenants. Remember the discussion on application objects and service principles earlier? This is where these come into play. For single tenant apps, both the application object and the service principle live in the same Azure AD tenant. But with a multi-tenant app, the application object resides in the Azure AD tenant where the application was registered, the home tenant. And then any other Azure AD tenant that has granted consent to the application is also gonna have a service principle in it that points back to the application object in the tenant where the application was registered that includes both the home tenant and any of the other tenants that are using that application. You need to be familiar with single tenant and multi-tenant accounts. The relationship of the application object and service principle with respect to the different types of accounts. The next thing you need to be familiar with is securing an app. You can secure it with a secret, which is just a string similar to a password that a custom app can use to define themselves and authenticate with Microsoft identity. I think of this like a user's password, but it's for the app. When you create the secret, you set an expiration duration for it, and then the Azure AD portal shows it just one time. If you fail to copy the secret, your only recourse is to create a new one as the secret is never shown again. The other option is to secure an application is using a certificate. And this is the recommended way that you should secure applications, especially production apps, because they can be better protected than secrets can. In addition to the client certificates, you should also be familiar with how to store and obtain certificates from Azure Key Vault. While developers can securely store secrets in Azure Key Vault, services need a way to access Azure Key Vault. Managed identities provide an automatically managed identity in Azure Active Directory for applications to use when connecting to resources that support Azure AD authentication. Applications can then use managed identities to obtain Azure AD tokens without having to manage any credentials. In the next lesson, we're gonna cover permissions and the consent framework that goes into a little bit more depth when it talks about secrets and the different types of apps. But first, let's talk about how we can manage access to your Azure AD applications with Azure AD. Microsoft Identity provides a few different ways that you can do this. So who can use the application? Let's start out there. By default, applications registered in Azure AD are available to all successfully authenticated users of the tenant where they were registered. In multi-tenant scenarios, all users in the tenant where the app is provisioned can access the application once they successfully authenticate with their respective tenants. Now administrators can limit access to the application in one of three different ways. You should be familiar with all three of these for the MS600 exam. First, administrators who are global admins in the tenant can limit the application access to specific users. This is done in the Azure AD portal and this is done by first going to the application in the Azure AD portal and then selecting the users who are permitted to use the application. If you aren't familiar with this process, refer to the Microsoft Learning Module referenced in the lesson notes for a hands-on lab that walks you through this process. Managing application access with individual users can be a very tedious process, especially if you've got a lot of users. So another option is to create a security group and grant access to that group. Using this approach, all users assigned to that group will get access to the application. Like managing access with users, if you aren't familiar with this process, refer to Microsoft Learning Modules that I referenced in the notes for this lesson for hands-on lab that walks you through the process. A popular way to also enforce authorization in an application is with role-based access control, also known as RBAC. RBAC enables an administrator to grant permissions to specific roles, not to users and groups. The roles are then assigned to users or groups to control access. And this approach enables admins to manage access to applications with much less effort instead of going and using users and groups. Now, the way this works is that you first define the roles for an application and while the Azure AD portal does contain a user experience for this, it doesn't exist when the exam was created. So you should be familiar with adding roles to the application's manifest file. If you aren't familiar with this process, refer to the Microsoft Learning Module referenced in the lesson notes for hands-on lab process that walks you through this. You then gonna assign a role to users or groups and then to leverage these roles within your application's custom code, you can check to see if the user has been assigned a specific role. While groups and app roles sound similar, there are some important differences and you should be familiar with these differences prior to taking the exam. For example, when an app registration is removed, it also removes its app roles that are assigned to users and groups. However, groups always remain intact if the app is removed. Application roles are specific to an application as they are defined within the app registration but groups, they're not related to apps, they only are associated with an Azure AD tenant. Those are two big differences. Okay, so that wraps up my lesson on Azure AD apps where we talked about app registration, securing apps, securing access to, in this lesson, we're gonna explore two more important concepts in Microsoft Identity, permissions and the consent framework. So let's get started. When it comes to permissions, there are a few simple concepts that you need to be familiar with with respect to the MS600 exam. Let's start with two different types of permissions that are supported by Microsoft Identity. The first type are delegated permissions and these are permissions that have something to do with a specific user. A delegated permission is used by an app that has a signed in user present. Think of it like if you're delegating an app to act on your behalf using your permissions. So for example, you have access to read and send emails from your mailbox. You can delegate an app, the permission mail.read to read the emails in your mailbox but not mail.send. This way, the app will only be able to read but not send emails because you've only delegated one of those permissions to the app, that's the reason why. Delegated permissions can be granted to an application by a user or an administrator can grant them on behalf of all other users in the organization. Some delegated permissions also require an administrator to grant those permissions. So think about it a little bit like this. I've got this app right here, it's a phone but let's just call it an app. So I have permissions to both send and read email. This app, when someone created this app, they said that it can do the mail.read permission. So it can't send mail but it can read mail. Now this app all by itself, it can't go access my mailbox. But what I can do is I can delegate my mail.read permission to this app. So that now once I do that, once I consent to this app being allowed to have that mail.read permission, this app can then go read my mail. When I talked about it a second ago as well an administrator can do this, an administrator can go grab this app and it can go on behalf of all the people in my organization and it can say that all of those people grant that app that permission. Sometimes that's done when you have like an enterprise based app that you wanna give, make sure that everybody in the organization can use and not have to send instructions to everybody saying, hey, you're gonna get this prompt when you first log in, you're gonna have to give it this permission. Global admins have the ability to do that. The second type of permission are application permissions. And unlike delegated permissions, an app permission can use the application permissions without a signed in user present. These types of permissions are usually used in an automated process like a service or a daemon. Application permissions can only be granted by an administrator. So again, let's use our same example. Mail.read and Mail.send, this app has those two permissions and they're administrative permissions or they're application permissions. Now by themselves, this app can't just go do those things until a administrator in your tenant goes through the administrative consent with this app and says, now you can go do that. When that happens, the app doesn't have to have a person present. It can just go do that for anybody in the organization. So application permissions are very, very sweeping. They're very wide scope and they're very permissive. So you wanna be careful about those while a lot of organizations don't allow them. Now there's another permission concept that you need to be aware of, but it's not really a permission type, it's just a concept. The effective permissions are the permissions an app has. They are best explained with a couple different examples. So when you look at a delegated permission, the effective permission an app has is the least privileged intersection of all the delegated permissions an app has been granted for a signed in user. For example, I don't have permissions to send email. If I don't have those permissions, I can't grant them to this app. Consider another example. Let's assume that your app has been granted the permission user.readwrite.all, which is a delegated permission that grants an app the ability to read and update the profile of any user in the organization. If the currently signed in user is an administrator who also has that permission, then the app can read and update profiles of any user in the org. However, if the user that is currently signed in is a normal user and the app will only be able to update that user's profile, not everybody's profile, because only that user that normal user has rights to their own profile. They don't have rights to update other people's profiles. When you look at application permissions, the effective permission is really all of those that the app has been granted to as there's no signed in user that's applicable here. Signing users are applicable to application permissions. Maybe a picture helps. So here you can see on the right-hand side, you've got all the users that have permissions for operations managed by their organization where on the left-hand side, these are all the apps that have been granted all these permissions to do all these different things. The effective permissions are the ones that is the intersection between the two. What has the app been granted access to do and what has the currently signed in user been granted access to do? But then again, that only applies to delegated permissions. Remember, application permissions doesn't need a user presence. So that right-hand side doesn't even matter. Now, to prepare for the MS-600 exam, you should be familiar with how to read permissions as well as these special open ID connect permissions or scopes, things such as open ID, email profile and offline access. These are all common scopes here. You should refer to the documentation that are provided in the notes to read up on these different scopes. Now, one more special permission that you should be familiar with is the default scope. Your application request this, can request this scope. Now, I receive all the permissions when I do this. My application receives all the permissions or all the scopes that have been assigned to the app in the Azure AD portal. So for example, a request to graph.microsoft.com slash dot default will return all Microsoft graph related scopes that have been assigned to the app. Now, this scope can only be used with any OAuth2 flow but it's required when you are using the on behalf of and client credentials flows. Okay, now let's talk about consent. The consent framework is how permissions or scopes are granted or consented to an application. There are a few aspects about the consent framework that you should be familiar with prior to taking the MS-600 exam. Individual consent is the process of prompting a user to grant or consent an app a delegated permission. While Microsoft's identity SDK is simplified this process, you should read the documentation and understand how this works in detail. But let me give you a bit of an overview. Let's say your application needs you to delegate the calendars dot read permission to it. The app would provide you the following URL. So here's what you're gonna see. This is the URL that's gonna come back to the app from the app to the browser. And then that's gonna be used to redirect back over to the authorization endpoint where you're gonna go authenticate. Let's look at this at a few of these pieces in this URL. So refer to the different OAuth2 flow documentation for details on each one of these different properties. We're just gonna pick apart a couple of them. The client ID tells Azure AD which registered app is requesting the permission. While the redirect URI, it has to match a redirect URL that is entered when the application was registered in Azure AD. This is where the user is gonna be sent after they complete the authentication and the consent process. The scope property is the space delimited list of all the scopes the app is requesting consent for. When you navigate to this URL, which is the authorization endpoint that I previously covered, you're gonna be prompted to first log in. And then if you haven't already granted this permission to the app or if an administrator hasn't consented to them on your behalf, Microsoft Identity will display a prompt with information about the application and which permission you need you to consent to. So in this case here, I've got an app called Identity Exercise 01. And it's asking for me to consent to permissions of sign in and request your profile, read your mail and maintain access to data that I've given it access to. In addition to individual user consent, an app can prompt the user to grant consent for all users in the organization. And this is useful in scenarios where an organization purchases a subscription to an application and proactively wants to set it up for everyone. And this is done by requesting delegated permissions for all users of the tenant using the admin consent endpoint, something that I've already discussed. Now, notice how the prompt looks a little bit different from the individual user consent one. Notice that it's got like that checkbox at the bottom. It says consent on behalf of your organization. So here, if I check that box, that's gonna allow me to go consent on behalf of everybody in the organization. Now, the last type of consent is the admin consent. This is used when granting delegated permissions to all users in an organization or when granting application permissions to an app. Now, refer to the previous lesson on OAuth2 authentication for the discussion on the admin endpoint. So here's what this consent looks like. Notice here that it's asking me to accept the or consent to permissions on behalf of the organization. And notice that it says things a little bit differently. Instead of saying, read your mail, it's saying, read user mail or sign in and read users profiles. And notice there's a little bit more information at the bottom of this dialogue. If you accept this, the applicant access to specified resources for all users in your organization, no one else is gonna be prompted for this. So it's giving you a pretty good warning of what this is going to do because this is a pretty big permission you're granting. Now, another concept that you should be familiar with is static versus dynamic consent. Static consent is when you specify all the permissions and application needs within the Azure AD admin portal. This is commonly done for application permissions. You can use this process for delegated permissions as well as those scenarios when your application needs the user to consent to all the permissions upfront. Dynamic consent is different in the sense that your application only requests from the user to consent to permission requests at the time the app needs them. So consider a really complicated application like a big CRM app that implements a lot of features and it each needs different permissions to access your data in Microsoft 365. A user may only be interested in 10 to 20% of the capabilities of an application, but when they log in, if the app requests the user to consent to 15 permission requests, that can cause the user to pause and wonder why they've gotta give it so many permissions to their information to the app for something that they may never use. So instead, your app can request permissions at the time the user goes to use this particular feature that it needs permissions for. Dynamic consent can complicate your application development, but it can lead to a better experience for your user. So you need to know it's an option that's supported by Microsoft Identity and just decide if it makes sense in your scenario. Okay, so that wraps up my lesson on Microsoft Identity Permissions and the Consent Framework. Now in this lesson, we're gonna take a look at addressing how developers leverage all the things that we've discussed throughout this chapter within their custom apps and APIs. So let's get started. Now, unlike the other lessons which focused on concepts, this lesson is a little bit shorter and it's gonna call out the aspects of different SDKs that you should be familiar with prior to taking the exam. Now, first and foremost, remember what I talked about in the introductory chapter of this course as well as the overview lesson in this course, in this chapter. Please make sure that you only focus on preparing for things that you're gonna be tested on, not on what you may not be tested on. Of course, if you wanna learn more, go for it. But if you're just focusing on passing the exam, I wanna focus just on what you need to know here. Now, while not something that you use to configure and implement authentication for in your apps, refer to the lesson on OAuth 2 authentication flows to make sure that you're familiar with the different endpoints. There are questions on the Microsoft Identity Pool of questions that are gonna ask about the endpoints as well as the SDKs. When it comes to the SDKs, you only really need to be familiar with two of them. You need to be familiar with the .NET implementation of MSAL and how you use it and configure it for things like ASP.NET apps, also API-based projects or web API-based projects and console apps that you would use to implement like a service or a daemon. When server-side coding is gonna be applicable, you only need to be familiar with the language C-sharp. The other implementation that you need to be familiar with is MSAL.js. The only type of application the exam is gonna test you on is a single-page app when it comes to MSAL.js. And the only languages that you need to be familiar with are JavaScript and TypeScript. So now let's look at the different things that you need to be familiar with with respect to the exam. Let's first look at MSAL.js. So as I stated previously, you only need to concern yourself with using MSAL.js in a single-page application, which is also referred to as a SPA or an SPA. When it comes to SPA, the only identity thing that you need to be familiar with is how to configure MSAL.js. Once the user is authenticated and he calls to register endpoints or monitor by MSAL.js, which will add the necessary HTTP authorization header values to the request for you when the token is obtained for the app. The configuration of MSAL.js is really simple and very straightforward. So again, refer to the links in the lesson notes below the video for documentation links in a hands-on lab and creating and setting up a single-page app that uses MSAL.js. Now let's look at MSAL.for.net. There's a good bit more you need to be familiar with when it comes to MSAL configuration and usage. A lot of the work has been simplified with the Microsoft Identity.Web Library, but again, as I mentioned previously in this chapter, that's not covered on the exam. So first let's look at when you'd use MSAL.net SDK. Think about all the different options you'd need to implement related to Microsoft 365. You could create web applications that leverage Microsoft Graph to display user data or custom components for Microsoft Teams and SharePoint or Office that maybe they need to call another API that you create. This API that you create may also need to call Microsoft Graph or another Azure AD secured endpoint. So back to when you use MSAL.net, well, Microsoft Teams apps and Office add-ins are really just web applications that you house and are surfaced in the clients within an iframe. Or like I said before, in many cases, you need to secure an API that you're gonna secure or you need to call an API that you're gonna secure. So you should be familiar about using Microsoft's identity to secure those APIs or to create scheduled services or things that need to run without interactive user contacts such as a console app or a daemon. MSAL.net configuration is probably the biggest thing you need to be familiar with because when it comes to ASP.net apps and web APIs, you need to understand how to hook up MSAL.net with the ASP.net middleware in a few different ways such as like acquiring access tokens as well. You should also be familiar with how to obtain tokens using both client secrets and client certificates. Finally, you should also be familiar with the differences between the two most common methods from obtaining access tokens, either using acquire token or the acquire token silent method. Now, let's look at a few specific implementations that you should be familiar with prior to taking the exam. The easiest one is MSAL.js for single page apps. For this, there's only one option. It's the OAuth2 implicit grant flow. Again, while the current recommendation from Microsoft has used MSAL.js v2 and the OAuth2 authorization code grant flow with PKECE support, when it comes to web applications, you should be familiar with how to configure MSAL.net for the OAuth2 authorization code grant flow. This includes both configuring it to support users logging in but also to trigger the common consent framework in obtaining the different tokens needed to identify users and call APIs. For web APIs, there are a few things needed that you need to be familiar with. This is one of the more complicated ones because you need to not only know how to secure an API with MSAL.net, but also how to implement the on behalf of OAuth2 flow so that your API can leverage the user's identity when it calls the downstream service. So this has been moved over to the Microsoft Identity Workload, even though these are exclusively Microsoft Teams-related topics. The Microsoft Learning Module on Single Sign-On for Microsoft Teams apps covers Single Sign-On, otherwise known as SSO, for both tabs and bots, including the setup process. And I wrote that module and I can assure you that it's a good prep for this topic on the exam. And I've also included links to the Microsoft Teams documentation on these two topics as well if you need more resources. And then finally, you need to be familiar with how to secure a console app using the OAuth2 client credentials flow so that the application can authenticate and obtain an access token with no signed in user. All right, so that's everything you need to know to be prepared for the Microsoft Identity Workload portion of the exam. If you have any questions about what I've covered here, please drop a comment below or let me know if you wanna see more videos about Azure AD development or something else. If you have any questions about what I've conveyed here, please drop a comment below or let me know if you wanna see more videos about Office Add-In Development. If you like this video, please give me a thumbs up and subscribe by smashing that big red subscribe button below the video so you'll see when I publish more videos for web and cloud developers on Microsoft 365 and Microsoft Azure topics. I'm Andrew Connell again, thanks for watching. I hope to see you next time.