Microsoft 365 Community Identity platform, 22 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Optimize Authentication and Authorization in your web apps and web APIs using Microsoft Identity Web

Description

This month’s in-depth topic: Optimize Authentication and Authorization in your web apps and web APIs using Microsoft Identity Web - optimize Authentication and Authorization in your web apps and web APIs using Microsoft Identity Web. Microsoft Identity Web is a set of ASP.NET Core libraries that simplifies adding authentication and authorization support to web apps and web APIs integrating with the Microsoft identity platform. It provides a single-surface API convenience layer that ties together ASP.NET Core, its authentication middleware, and the Microsoft Authentication Library (MSAL) for .NET. Presenter Rinki Bera – Program Manager, Microsoft Identity. Recorded March 17, 2022.

Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube (Developer channel) and https://aka.ms/m365pnp/videos (Community channel)
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
• Join us for the next Microsoft Identity Platform community call on April 21st at 9:00am PT

A

So good morning and good evening, everyone this is rinky. I am a program manager in microsoft, identity, engineering, developer care team. So today I will be talking about how to optimize authentication and authorization in our web apis using microsoft, identity, web or the microsoft identity platform as well.

A

So have a quick look on the agenda. We'll talk about the app topology then followed with what microsoft identity platform is and what are the libraries available? Then we'll see how token acquisition happens with these libraries followed with a small demo. Then after that we'll talk about the permission and consent framework again, a small demand, what incremental permission is and then finally we'll wind up with the best practices.

A

So please feel free to ask any question on the chat. If I'm not able to see it because I'll be sharing the screen, I will take it up as soon as I finish the session.

A

So let's talk about the app topology to understand this: to access the data layer from any protected web hosted resources which, in other words we call apis right. Application needs to authenticate and authorize against few standard protocols, namely open id connect and or2 protocols, so once done, they can make calls to the secured apis. Here we have taken example of microsoft, graph api, which is a gateway to a huge amount of data from different workloads, especially microsoft, m365 workload.

A

So you can choose from a wide range of technologies available for building your apps and microsoft. Identity platform foundation is actually based on this app topology.

A

So, let's see for what are the libraries available in microsoft, identity platform before that? What is microsoft, identity platform?

A

It is a set of authentication services and open source libraries and application management tool with which application developers can build applications where users can log in with different identities, namely the work and school account, the personal accounts and even the social accounts, and then authorize access to secured web apis, for example, microsoft graph apis.

A

All of the architectures here are based on industry standard protocol. That is what to an open id connect. So microsoft, libraries, especially msl, is the best choice when you use microsoft, identity platform. Why? Because using msl for token acquisition ensures high level of resiliency and security from an identity standpoint for your application.

A

So let's talk about authentication. So what is authentication when your app is integrated with our libraries like msl, then what happens? It actually receives or requests for two few tokens from the microsoft identity platform. This microsoft identity platform is the sds server you can on that security, token server or aad or microsoft identity platform. You can call it anything. So your application, integrated with msl, will receive few tokens, namely id token access, token refresh token, and then what will it do with those tokens with id token?

A

Whoever is the user who is trying to sign into your app will prove his or her identity with deciding token and then with the access token, your application will make a call to the protected web hosted resource here. It is microsoft, graph api.

A

So this call is nothing but the http get request and the access token is passed as a vrro token in the authorization header of that http get request to access this api. So now this api will validate this token and it will authorize access for your application to its resource.

A

So again we recommend msl or microsoft identity web for token acquisition, because this is the most resilient and secure library as of today in microsoft, identity platform.

A

So being said that, if you already are on the older version of microsoft, identity platform, libraries like adult, then it's always recommended that you move to msl being said that, because msl comes with much more benefits over adult, just like I said you can authenticate a broader set of microsoft. Identities like you can use users with work or school accounts or personal accounts or social accounts, and your users will get the best single sign-on experience with the v2 endpoint or the msa library, and your user will be able to use incremental consent.

A

We will just talk about incremental consent in the later part of the slides, along with that, you can use conditional access. So, in short, you benefit from continuous innovation in terms of security and resilience when you are on msl.net or microsoft identity.web, so when to choose what what is microsoft identity web, we know, msl is our library right, but what is microsoft? Identity with it's a single surface, api convenience layer that ties together the asp.net core, its authentication, middleware and the msl library? So we get the benefit.

A

It's a wrapper on top of msl.net, so we get the benefit of msl.net and also the token validation part when you use microsoft, identity, web and how to decide when to use what. So, if you are on azure, ad and or azure b2c, and you are building a web app or web api or a demon app and you are on asp.net core, then go for microsoft, identity! Web! If you are just on dot net framework or dot net code, then you can use the hybrid model where we have msl.net extensions and microsoft identity web.

A

We will get the benefit of token caches, serializer and certificate loader. If you are building desktop application or mobile application, then msr.net is the best choice for you. Similarly, we have project templates when, if you are creating new applications, then you should directly you use those project templates that will be easier and if you are already on ada or the older library, then we have all the guidance available for migrating to the latest libraries of microsoft identity platform.

A

Now here this session is mostly concentrated on in cell.net or microsoft: identity, web, but msl is available in all these languages and platforms apart from msl go all are currently generally available.

A

So, let's understand how token acquisition happens in microsoft, identity platform.

A

So let's start with an app. So what we need now we need to login and user, and then I need to call an api on behalf of the user. So this is my application. This is the microsoft identity platform or the ad server, and this is the microsoft graph, api user endpoint. That's the me endpoint from where I'll get the user information profile information of the user. So what is required now, so this application needs an id token to identify the user and an access token to read the user's profile from this api.

A

On behalf of the user, so in what what will begin, a private conversation with the user will begin initially, even before it talks to the web api, and this is where her cookie stations the session starts. So this is the core of single sign-on. So once the cookie session starts, the app will receive an id token.

A

This is how an id token looks like, so this is the header claim of the id token, which gives you what is the token type like this is json web token. What's what is the algorithm used and the kid kit is a a string that specifies the thumb print for the public key that can be used for validating the token signature and also the version from which the token has been emitted from here? It's the payload claim starts, so the payload claim has the issuer issuer.

A

This is having the microsoft online.com, that is, the ad server uri followed with the tenant id the tenant id for which the user is being authenticated. For so this is that tenant id and if it is emitted, this id token is emitted from the v2 endpoint. Then this will be at the end of the uri.

A

Similarly, we have the audience claim so audience same in case of id token. It is the application id of the application which has been registered in the portal. So once you register your application in the portal, a unique identifier will be created. That is the app id, and that is what the audience is here in case of the id token. So this id token has to this value should be validated because the token should reject if it fails to match your app's app id.

A

Then we have the expiry and issue that time and not before time, and this version talks about the user himself, the name of the user, his username, and what will we use usually is this object id which is unique for that particular user in that particular tenant? This object, id dot tid will give the unique identification of the user who is trying to login to your application.

A

So when you validate the token id token, this is something will help you validating the identifying the user. So now id token has done the authentication, but now the app will receive an access token. So what is an access? Token access token looks something like this. We have already always passed it with jwt dot, io or ms, but it is always recommended that you do not attempt to validate or read tokens or any api.

A

You don't own as a developer, because tokens from microsoft can use a special format that will not validate as a jwt. It may also be encrypted for consumer accounts like microsoft accounts. So, while reading tokens is beneficial for debugging purpose, we understand that, but it should not take dependencies on this on your code, so tokens are meant to be read and validated only by its audience. That is the api that is consuming it so moving to the next slide now the app has been authenticated.

A

It has an authenticated user and also an access token to call the api. So now the app will make the request to the api endpoint and in its authorization header of the get http get request. It will pass the access token as a bearer token.

A

Now it is the work of this api microsoft graph api to validate the token to pass the token and validate and make sure that the token is from the particular application who is who is trying to access whether they can authorize or not. Once this api validates the token it will authorize access to the application on behalf of the user?

A

Let's look into a small demo, so this application signs in and users and then make a call to microsoft, graph v, endpoint to read the profile information of the user. This is an asp.net core, mvc application. Here I have used microsoft, identity, web and also graph sdk.

A

So let me explain by adding microsoft identity web, but I have enabled my application to sign in user from different identities, as I already said, from work or school accounts and microsoft. Personal accounts, if needed. So in these two lines, what is happening? Msl.Net is actually connecting with open id connect events to redeem the authorization code from the asp.net code middleware and then make obtaining the token from the token endpoint. So once the token is obtained, it is stored in in memory token cache you can uh for the use of the controller.

A

You can also use distributed token cache where you'll get advantage of sql server, cache or redis cache, depending upon your application needs here for in this application, I have you used in memory token cache.

A

So now in this two lines, what we are doing, we are adding the support to microsoft graph here the graph service benefits from the optimized http client management of asp.net core. In these two lines, let's go to the controller. Now, if you see here in the controller, we are making a call to the microsoft graph api me endpoint, where the user information resides.

A

So for this call, I have defined the scope user dot read so user dot read, scope is what is needed for getting access to this me endpoint. Now, if in case the token cannot be acquired, then a challenge is attempted to resign in the user and the user have to consent to the requested scopes. These scopes are declared expressively in this authorized for scope attribute.

A

This is something in microsoft: identity, web, which actually manages the incremental consent framework. So as and when the an application needs to perform a functionality or read a particular data from the particular resource, it will go ahead and request for that particular scope.

A

So this is what is authorized for scope attribute, which is a part of microsoft, identity, web and it helps managing the incremental consent. We will talk about incremental consent in more details in the later part of the slide, and then, let's see where I have declared the details of the application before going to this, let me take you to the portal one second, so this is my application. I have registered my application in azure active directory and once I registered this application application id, which is the unique identifier of my application got created.

A

This is what is needed and that the tenant id tenant id is same for all applications residing in my tenant. This is my tenant name, rinke cosmos. If you can see so once I register this application, I'll go to the certificates and secret plate and create a secret for my application. Secret is nothing but the application password. It is not recommended to use client secrets for production apps.

A

This is my test application, I'm using it for demo purpose, hence I'm using client secret, but it's always recommended that you go ahead and upload certificate for your production application.

A

So once I have done that, let me go back to my application here. I have declared the client id or the application id the tenant id. The client secrets I'll delete this after this call, because I'm not supposed to show this openly- and this is the authorization server that's login.microsoft.com and my domain.

A

Once I have declared all the application parameters, then I have to declare the graph. Ap means the api, where I am making that call to and the scope for it. So here is where the scope is declared the user.3 to read the profile information of the user. So if I run my application.

A

And I sign in with an user to this application for the first time.

A

Rl, for the first time is trying to access this application. She will be prompted for this request. This is the request or the permission that is requested by your app when you declare user dot, read scope. So as an user, I am accepting this and I am signed in as adult in this application.

A

Now I will try to hit the vn point of the graph api and that will give me the details of the user profile.

A

So what we did here is we signed in a new user in my application using microsoft identity web and then I made a call to graph api endpoint on behalf of the user and got to know the user profile information.

A

So let's go back to the day, okay. So what? If my application needs to call another api, so I have got an access token for graph api.

A

Now I need to call another api which is named as catalog api, so I cannot use the token that is issued for graph for another api for obvious reasons, so I'll need an access token to read the catalog as a user. So now again, a private conversation will start. Similarly, the application will receive another access token on behalf of the same user or different user. If it is a different user, then again we have to prove his identity.

A

If the same user app will receive an access token for this particular api and then in a similar way, it will make a call to this api with the access token, as a bearer token, in the authorization header of the http request, and then once this catalog api validates this token, it will give access to the it will authorize access to the application on behalf of the user.

A

So this is how token acquisition and accessing api happens in microsoft, identity platform.

A

So moving on to the permission and consent framework, which is another important aspect of microsoft, identity platform, so authentication we just spoke about authentication is where the user proves its identity to the application.

A

Now the user is connected to the apps with authentication and then what is authorization applications that integrate with microsoft, identity platform, follow an authorization model that gives the user and administrators control over how much data the app can access either on behalf of itself or on behalf of an user depending upon that microsoft, identity platform has bucketize the permissions into two broad categories: the other delegated permissions and application permissions, and by consenting to these permissions, admins and users feel confident that their applications are not being used with any malicious intent.

A

So what is this authorization model? If you want to talk in detail, then microsoft identity platform implements the what to authorization protocol for this model. This protocol is a method by which a third party app can access an api on behalf of an user. So api can define a set of permissions that, as a developer, you can use to implement functionalities in your app in smaller chunks.

A

So the api may expose any amount of data, but an app should request only for those which is required only for those permissions that are at most required for the application to function. So the recommendation is to always abide by the least privileged approach. Only ask for those that is absolutely required for my application to function. I should not ask for any permission for which I do not have any functionality in my application at all, so the recommendation is to abide by the law of least privilege approach.

A

Okay, so there are two types of permissions.

A

So when an application accesses an api on behalf of an user, then the permission which is required is termed, as delegated permission, so for any application which has signed in user in front of it, for example, single page apps, web apps, mobile or desktop app and application with middle tier web api for those kind of application, the permissions that will be required are delegated permissions and, as there is a sign-in user present in front of this kind of application, these permissions can be consented either by the users or by the admin, and that is completely on the api developer on who can actually grant consent to these permissions as an app developer.

A

We are not worried about who can consent. If my application requires this permission, I will go ahead and request for it.

A

On the other hand, if an application accesses a service on behalf of itself, for example, service, backend services or daemon app, then the permission that is required are termed as application permissions and as there is no signed in user in front of these kind of applications. So we obviously only add. Admin can consent for these kind of permissions.

A

So now the intersection of delegated permission and application permission is what we call as effective permission, and that is the permission which an application has. Finally, when it is making a call to the targeted resource, so a user will have some privilege or restriction depending upon the organization's tenant restrictions or rules and an application will be granted consent for its permission, its range of operations, but the effective permission will be always the intersection of both of the type of permissions.

A

So, moving on to the next slide, how we call an api and how an app request, foreign for a scope we just saw in the demo how we make a call to the token endpoint or with the scope with microsoft, identity web.

A

So here what we do is we'll first try to acquire the token silently and in case we receive an ui required exception, then we'll go ahead and acquire the token interactively and the scope is defined as user or read when we need to read the assigning the user and read the profile information of the signed in user. So for a regular user. If the permission requires user consent, not admin consent, then for a regular user. This is what the experience will be.

A

He or she can accept or deny this permission, just as I did in my demo. So if a permission requires admin consent, then for a regular user. This will be the experience, because the regular user will not be able to consent. For that particular permission, and if it is an admin user, then he or she will be able to accept the permission on behalf of it himself or also he can consent on behalf of the entire organization.

A

So this is very beneficial for lob applications where an admin can consent on behalf of the organization and any users using the this application will not be prompted again for the request. This can be done while running the application. This can be done from the portal. Also, if you go to the portal, you can click here and it will be on behalf as an admin. Then, on behalf of all the users, the consent will be granted once the particular scope is accepted, then the app will receive an access token.

A

So this is the access token, but if the user or admin rejects the permission, then the app will not receive any access token, and it will be said that a consent has been denied. So here what is happening? A basic transaction happens here that I'm asking for a token. Can I have an access token to call this api with a scope for a particular range of operations?

A

Tab apps request is either granted or denied, based on that the app will receive a token or it will not. So again, permissions are of three types like dynamic permissions, which is very new to the v2 endpoint. Here the developer has control on what permissions the user will be prompted for which consent is required.

A

Unlike the old experience where it was already defined in the portal suppose there are 10 permissions available in the portal, but my application needs only three or four of it. Then I will go ahead and request only those three and four of it. I will not go ahead and request for all the 10 that is available in the portal, so this is what is dynamic consent and this can be combined with incremental consent where what we do.

A

We combine the dynamic consent with incremental user consent, which allows you, as an application developer, to add another consent on the way, for example, just to read the profile information, I need user dot read okay but in course of time my application needs to set an invite on the user's calendar. For that reason, it has to go and ask for the user. Look. I need to get access to a calendar. Please give me access.

A

If he gives access, then I can go ahead and put up an invite in his calendar and then I need calendar dot, read right for that purpose and again, after a few more days, I need to go and manage the files in his one drive my I means the application so again I'll go ahead and ask for that particular scope, so as and when the application needs to perform some functionality, for which a particular scope is required.

A

At that point of time, it can request for the scope, no need to go ahead and request for all the scope at the beginning of signing in an user to that particular application.

A

So this is what is incremental permissions, so this is how we make the request, within incremental consent for incremental permissions, while making a call to acquire token and the static permission. The final one, which we already used with the older version of library. Also this is the slash dot default, and here what is happening I want to use once the application want to use everything. That's already been declared in the portal for me and I'm not going to manage incrementally or dynamically the consent that my applications are going to use.

A

So this is the slash or default permissions. This is used for for demand, services or back-end services where there is no sign in users. So already whatever is available in the portal is what is available for that particular applications.

A

But it's not recommended for where there is a sign in user present to use this kind of a permission. Let's do another small demo or understanding how incremental consent work. So this is an application developed by kyle thanks to kyle, and this is a desktop application where we are using microsoft, identity, client that is msal.net and we are making calls to three different microsoft graph apis with three different scopes. Okay, first is, as we spoke about user.readscope, so for this scope: api developer, api developer.

A

In the sense microsoft rough developers had designed the api in such a way that this permission does not require admin consent. How it is decided is based on how much data it is exposing the user dot read, exposes low, privileged data.

A

It is exposing the information of the user on behalf of the signed in user, so this is a low, privileged data. That's why the api developer has made this this scope available for the users to give consent to admin. Consent is not required for this. Similarly, for people api, this is an intelligent api from microsoft graph, and this actually gives you the list of people you are currently interacting with.

A

It has a relevant score based on which it determines whom you have recently shared a file with whom you had recently contacted over teams or whom you chat with daily. Who are your teammates? You are working with closely and with that relevance. Code provides a list of people, and this api is useful for that purpose.

A

So when you try to type a name on the address part of the email, you will see that you will get a prompt of few people whom you are already working with, so that is where this api comes into picture, just an example.

A

So even this api does not expose high privilege data so for this api also admin consent is not required.

A

Then we are making call uh to the groups api, and here we are requesting for a scope group.treat.all, which will allow the application to read the all the groups, information for all the users on behalf of the signed in user. So in this case it is exposing a high privilege, higher privilege data which might not be relevant for the signed end user to know. So that's the reason this particular permission requires admin consent, and that is how it is designed by the api developer.

A

So with all these calls, we are actually making call to the graph endpoint with the access token and with the scope here. So let's run the application application is running, it seems so when we try to sign in and user I'll, just sign out the current user.

A

Again, we just saw that, because user dot read I have addel is a regular user and she's trying to access this app. So this doesn't require admin consent. So she will get this kind of a prompt and she'll be able to access the application.

A

So now, if, when I'm making the call to the people endpoint again with the same user along with reading the user profile, now that the request is that this is what is, we call an incremental consent now the application is requesting for another consent that I uh want to go and read the people information. Are you allowing me so this? This is what we call the incremental consent. If you see in my app here right now application permissions, you will see only the user.read permission has been granted.

A

It will keep on increasing, as and when I go ahead and consent for the other requests.

A

So now let me go to the result app you will. You will be able to see the people information. This is a dummy application and I do not have so many relevance. People remember which this dummy application has bought, of which this user had worked with. So that's the reason I'm not seeing much details, but it is, it has the capability of showing all the relevant people. You are recently working with so going back to the portal.

A

Now you see, people.read is added to it, so it's incrementally adding all the permissions as and when it's required by the application. Let's make a call to the group api with the regular user.

A

Now you see, you will not be able to consent means the regular user will not be able to consent. For this permission, because this permission requires admin consent. This is a new experience where you can go ahead and request for approval. I want access to this resource, for example, you can go ahead and request for this and it will go and sit in the user consent in your portal.

A

So, but if I use an admin to login.

A

Or to make a call to this endpoint, I will be allowed to consent for it see I am an admin and I will be allowed to consent for it either. On behalf of myself or on behalf of the entire organization.

A

So this is how now, if you see here, groups will also be added to it. So this is what is incremental. Consent is.

A

This permission got added to it, so you see the permissions are getting incrementally. Initially, you do not require all the permissions, so that is what is incremental consent in the interest of time. Let me go back to the deck.

A

Let's talk about few of the best practices of using microsoft identity platform, so the golden rules for tokens use tokens only for their intended functions. Do not try to use a token which is intended for particular resource for another resource. Id tokens identify the user to the application access tokens, authorize the apps for a range of operations for an api, never mess with someone else's tokens.

A

Apps do not look at the access token, as we already discussed, you are not supposed to parse an access token and look into it. If you are not the one who is consuming it, apis, never use id tokens for authorization, apis, never accept access tokens for other apis and cache tokens appropriately, use proper token caches for storing the tokens.

A

Msl handle this automatically, so it is always recommended that you use emcell or microsoft identity web, which does all this at the back end for you and you do not do not have to worry check the error classes instead of search for specific error codes.

A

So now the best practice for single sign-on always try to acquire the token silently before attempting the interactive token acquisition. We spoke about these two in few slides above. This is the simple pattern that enables sso and handles id policies, so best practices for secure authentication build your solutions by using libraries. As we said, msal and dot net middleware do not store login names and passwords use, msl or b2c apps shouldn't handle raw passwords, avoid the resource owner password credentials, confidential clients, like demons and web services, should use certificates.

A

As we said, we should not be using client secrets maintain redirect uri hygiene for your application. We have a blog talking about the hygiene, how we can use redirective array in a appropriate way. You can go through this for more details and we have an article for the best practices. Also, please look into it if you are interested so best practices for updating to msl write your new apps using msl or microsoft, identity webs.

A

If you are already on adult, if you are already on microsoft, older version of library, then it's recommended that you move to msl and that will make your application more resilient to any of the outages that is happening and more secure.

A

We have the guidance available for all the platforms, all the languages and the platforms you can choose, depending upon on which platform you're building your app. So the next steps.

B

Thank you, rinky uh thanks a lot for the session. uh The next steps. Folks, uh you know, go to ak dot. Ms slash msid platform, you know, get started there and we have our monthly community call every third week, thursday, uh you can download the calendar and pretty much uh you know, join all our calls. We have some exciting calls lined up for the upcoming months.

B

You can always ask a question in the you know: stack overflow, microsoft, identity, category all right, so this recording will be available in microsoft, 365 pnp, slash videos, you can get the full schedule of the upcoming sessions and all the recordings on these twitter channels. Please do a follow and we have our next call coming up on april. 21St, like I said, exciting calls lined up and uh you know we would love to have you here, and it would be great if you could take some time to not take more than a minute to.

B

You know film, a survey for us, but I do see there are some questions on the chat. Let me see, all of them are answered. You see, kyle, taking up a lot of them.

A

Okay for the single sign-off, I think one question is there yeah go ahead, but I will be sharing with a link for a single sign-off. We have not covered it in this session. The interest of time but I'll be sharing the link here.

C

Hello, this is ambassador, I I think kyle answer my question, but I still have a question right um and I would like to clarify my question right, um which has to do with administrative consent for specific application permissions for specific api that are validated on the tenant right, uh I'm part of the team that is basically the director administrator, so global administrators of the tenant, and we get a lot of requests from our application teams to consent to api specific permissions. Where again, the requirements don't have a clue.

C

What those grant the owner of the api is the one that knows what those grant to the api right. This is a custom, build api, of course, so there's no ui today for application owners, so folks that are granted the owner role on the application registration to adding consent to their own scopes right.

C

You can do that, be a power show we kind of documented that internally and are sharing that every time we get one of those, but we still get it off those because the app owners developers don't know how to do that via powershell right now. The question is: is there any plans to you know, build a ui on the portal where I'm being consent for specific applications can be granted by the application owner? Not the director administrator.

A

Okay, if I understand that for your custom apis, whatever scope, you are exposing. For example, if you can see my screen.

C

Yep, those that is that's.

A

This is my custom api and I have added these permissions here. So as an administrator, I can run consent for my tenant. Well,.

C

I'm talking about application permissions right that require an inconsent right.

A

C

Those those that you either are delegated and don't require any consent. Okay, so all application permissions, regardless of the api, require earning consent right.

D

Yes, I think that's fair feedback that we have a way for you know, because right now you would go to the admin consent endpoint, but I think we would need an admin to sign in there, not a user, not an application.

A

D

You could make someone an app owner here which, in theory, should give them uh the right to go ahead and well you actually app owner. We would read the application administrator role to to be able to grant these admin consent to something other.

E

Than microsoft,.

D

Graph, so you can use powershot to do it right. Okay,.

C

D

Here, yes, okay, correct another ui right, that's right! But when you go.

A

D

The admin consent endpoint, I think we need admins to sign in there. So I think that's fair feedback that we don't have. You can do it with powershell. You could do it with your own uh use of microsoft graph, um but we don't have an eui built for that. So I think it's it's good feedback for us to take. As we look at you know, improvements we can make to to this area of the ap of the ui.

D

Thank you thank you for that. Yeah.

A

Thank you for the feedback.

F

And it was only a quick question: I'd put into the um chat there um so for systems where we need finer, grained details and so maybe not suitable for going into a token. um It's like an abac style approach. um Is that something that you can see fitting into this framework? Would you say that there was any sort of preferred ways of implementing that.

D

We don't have any guidance for that today, although it's certainly looking uh like it's certainly something we're investigating right now uh and what kind of of abac systems and so on today we don't have any specific guidance. um All we have today is that the token you know will apply, especially you know. Obviously, in the resource provider, the api implementation side.

D

You know we can get the token to your api, obviously via the the client app, but we don't provide yet tools for how you can go to that next step, especially when you start thinking about okay. How do I actually do effective permissions? How do I know what this user is allowed to do, etc, we're looking at how we can plug into those systems or or or provide something we just don't have any generic guidance at the moment. Okay, thank you.

A

D

There's a question here uh about the use of as web authentication session. um My concern is when asking that you're you're you're going ahead and doing the protocol level work on your own. I would prefer you see you use msol in that situation, since we have work in msol to do things well there. There are issues around things like, uh especially now that azure ad b2c does have conditional access support, uh there's issue, whereas around timing and making sure all those things work, uh background tasks etc.

D

Given the specific uh architecture in uh ios today, there's there's issues with uh you know, background worker tasks, etc uh that are going on that need to be going on. The only advice I would give you is: if you want the you know our best practices, if you will, we don't really talk about this? uh uh Implementing things at the protocol level is something we think should be your last resort.

D

You should use msul if you're targeting microsoft identity as you are with azure b2c, otherwise, a well-maintained, open id connect library would probably have these items solved. uh The only guidance I could have with within two you know what is to look at our msol implementation and so ios. It is open source. We have all of that source available and take a good, solid look at how we're using that as web authentication session.

D

There are definitely some gotchas in that respect, as I mentioned, especially depending upon the time frame that a uh an open id connect request can happen, given conditional access uh requirements that need to be met where I have seen developers who are off trying to do their own protocol, uh implementation have to do some extra work because of the nature of how ios puts your session. You know and stop start starving your session for cycles. uh There's definitely some work there. You need to look at so take a look at the msol ios.

G

For how we do that thanks marsh, we'll do that. I wasn't sure why uh why or how this was implemented before so I'm just I'm getting you onto the project, so probably I'll find out more about this yeah. um It is tricky I will. I will say.

D

That right, because it's it's very ios specific by the way right, it's how ios deals with when yours is because, especially when you're using the the the broker etc, it's definitely something you should take a look at in in our source.

D

Okay, thank you.

B

There's one more question: is there a place that you users can see a list of what they have consented to.

D

Sure they can go to my app stopmicrosoft.com for either your corporate or personal accounts. You can get a sense, a list if you will- and you could even go in and revoke those permissions without revoke consent. If you had granted it, you can revoke it for there too,.

B

Perfect there's another question on: how do the admin owner provide consent using powershell? I think we have a dock for this right.

D

Yeah, I assume I haven't looked at it myself, though, but I think that was something that uh uh uh mentioned so maybe he has a pointer to the dock. For us. Maybe he's still here.

E

uh Question uh I'd like to dig a little bit deeper into that that discussion that was later earlier with the admin owner that is able to provide admin content. Is that really true, because that, in my mind, would be a huge security risk.

A

E

An administrator I'm definitely not interested in the developer to decide which data he is granting access to. So uh here's some.

D

Different things, uh first off for any microsoft graph api, a tenant admin is the only in only a role person. Who's allowed to grant a consent to admin, consent required items in microsoft graph because of the nature of the data that you're getting access to the the tech, the the it's not actually a developer. The application owner role doesn't give you the right to grant permission to your client application.

D

However, the application owner role for the api uh that application owner could grant permission uh to to you know they're they're allowed to grant permission to request to that particular api, but that particular api only.

E

So, in this case,.

D

If that individual is the same right, although I would actually point out ricky, can you bring up the the app registration uh api registration page? If I was really doing this, I'm developing uh the frozen api.

A

Yeah yeah here.

D

We have the ability to add, as you see here, add a client application. So if I'm really the owner of the api and I'm an owner of that application, it sounds to me like. I have a close coupling between a front and a back end here and that's really what this is meant to pervade right. I've got a, I can add my client application to my app ap, my api registration and say this client application shouldn't need consent effectively saying these two are closely coupled.

D

So if I really was the api applicati api owner and the application owner, I'd probably use this.

E

Okay, so it's only consent to the data within that particular api.

D

E

Access to the backend data.

D

Not to the yeah, certainly not to anything in azure ad, specifically, the azure ad part of microsoft graph requires tenant admin to consent because of the nature of what that could be right. So, as you were concerned, hey, I don't want some random application, granting itself access to tenant admin, capabilities and microsoft graph. We we wouldn't like that either right, so that's not allowed. If you have a microsoft graph, where all of your directory information is where all of your information from microsoft 365 is those require real tenant.

D

Admins like global tenant, admins, to approve to grant.

E

Yeah, so it's you, the administrator cannot say. Okay. Now I want my api to have access to all emails in all mailboxes.

D

For instance, not the app admin it would have to that would require a tenant admin.

E

Yes, okay, thank you.

C

Yeah- and that was my question right me- I mean I mean I don't want to be approving api scopes for specific apps, like if you, if you go here to the uh what is it uh app roles right where you defined what scopes you want for your api, uh and I I don't know where those are right for each and every app on the tenant. So yeah, I don't know, and as an.

D

Element shouldn't be approving that yeah, as you mentioned, we'll, let you off the hook for that for you, these custom apis. We won't let you off the hook for that as a tenant, admin for grant.

C

I I completely agree with that right. We we control that and we, you know, tightly manage. Who gets those successes? Yes, of course, that would be a huge security concern. Exactly you're the only people.

D

Who could grant that position right? Yeah only gas can do that and nobody else.

C

A

And as kyle said, this is where you can go ahead and revoke permissions from your my my apps manage your accounts, manage your applications.

A

I do not for this one. I do not have anything, but you can always go ahead and revoke permissions from it.

A

From the my apps, so thank you. Everyone, any other questions here on time.

B

We have one more question uh with owen and amsar.: when user authentication expires, cookie expires, the cookie authentication handle will force the user to go through oidc login flow. Are there any thoughts for an extension where msl token cache could be checked for a refresh token being valid and using that to relock in the user? Avoiding the redirect slash white flashes in the browser.

D

The problem there is, you know, effectively two different components, doing the work there, um the always so, and you know, to a certain extent, I guess we're showing a little bit of organizational structure. The msol.net. uh You know we we provide, but the owen is part of uh uh net core itself or net right. So the the fact that you know you've gone ahead and done an authentication with amsoil uh to get access tokens well, the uh which, which can have refresh tokens uh the the core.net component. Isn't aware of so.

D

I don't think we have any plans to change that. That would be something that we would look at through the microsoft identity web that rinky had talked about earlier.

A

B

Perfect, I think, we're good. I think we've covered all the questions thanks a lot drinky thanks a lot kyle and thank you everyone for joining. If you could take a minute to fill in the survey. That would be really helpful. Our next call is going to be on april 21, looking forward to all of you on the call thanks a lot.

A

Thank you. Everyone thanks nanesh thanks, guys have a nice day. All of you bye,.