Microsoft 365 Community Identity platform, 26 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Microsoft Identity platform – Do’s and Don’ts - March 2021

Description

This month’s in-depth topic: Microsoft Identity platform – Do’s and Don’t. Covers Microsoft Identity platform for developers (build applications and integrate identity with one unified toolkit), Microsoft Authentication Libraries (JS, .NET, Android, iOS, Python, Java, Angular, Microsoft Identity Web), and top developer mistakes seen on the Microsoft Identity platform. Microsoft Program Manager presenters - Harish Suresh | @harish_suresh and Sahil Malik | @sahilmalik. This session was delivered and recorded on March 18, 2021. Q&A in chat throughout call.

Stay connected:
• Twitter https://twitter.com/microsoft365dev
• YouTube https://aka.ms/M365DevYouTube
• Blogs https://aka.ms/M365DevBlog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar

A

Both of us are program managers in the microsoft identity group in our day and day our jobs, our job is to you know, look for the complex problems that developers run into when they use our platform, so I'd like to hand it over to harish, so he has an opportunity to introduce himself as well harish.

B

Thanks sahil, thanks for that and as I mentioned, we work with enterprise customers, isvs partners and help on integrating the applications and making sure they get the best use case. So, let's get started and uh off to your side.

A

Thank you. So it's interesting, I'm looking at the attendee list and I see a lot of familiar names uh so before, before being in this role and before joining microsoft, I was an mvp and I was also on the external. uh You know: advisors, network myself. So it's very interesting to me on both sides of the equation. So uh what we're doing here is you know we we work with developers uh that really push the boundaries on our identity platform.

A

So I'd like to start with a little bit of an introduction to our platform uh and then we'll talk about the most common mistakes we see developers make when they work with our platform. That's just based on our experience of what we've seen so starting with a little bit of an introduction.

A

You know our tagline is we build applications and integrate identity with one unified toolkit? It all starts with an app registration. So when azure ad wants to give you authentication services to your application, uh you know you need to tell us about hey. This is my application, and this is what I intend to do that process. We called as app registration, and you can do this in the portal, or you can do this through the microsoft graph api. You can automate this if you wish and then to support the working with this particular app registration.

A

We have a number of libraries. Typically, we like to call them microsoft, authentication, libraries. It is worth mentioning that our endpoints are oidc certified, so they follow an industry standard protocol and you're welcome to use any other library as well as long as it works with oidc.

A

Now, of course, if there is an m cell that we provide for the platform, we recommend you use that, but if there is a platform that is not on our radar and you must use it with the microsoft indy platform with standards compliant, so you're welcome to use that as well.

A

So we also say I have a rich ecosystem of web apis. uh Microsoft graph is a combination of a lot of interesting capabilities all across the microsoft ecosystem. You can manage parts of azure through management.azure.com. There are many other apis and, of course, you're. Welcome to author, your own apis that live in this ecosystem. As well- and we support all of this with a number of different kinds of identities- and we follow- uh you know the important industry standards such as skim for provisioning and saml, and so on so forth when we talk of emcell.

A

Currently we offer emcell on the following platform, so there's a wide variety of platforms that we work with, and this is actually one of the most exciting things about you know. Working with identity is that you get to put your fingers on all of these platforms, so that makes the job very very interesting.

A

Why do we recommend you use themselves, because uh you know working with the at protocol level can get complicated uh following best practices can be difficult, and sometimes we offer some optimizations like reaching out to the closest data center et cetera, managing your token cash for you, etc. So we help you a lot when you use the library.

A

Of course, you can do it by hand yourself, but we highly recommend that if there is a library available for the platform that you use that instead so with that basic introduction, now I'd like to dive into the top developer mistakes that we see developers commit on the microsoft identity platform. Now this is just based on our experience. You know when we talk with look at our various channels: github stack, overflow, one-on-one engagements, etc.

A

This is a large percentage of the mistakes we see so as I'm reading these one by one I'll just go through them one by one through slides, so we can talk about them, starting with putting secrets in your code.

A

So let me first define by what we mean by putting secrets in your code here, I'm referring to like client secrets or client credentials, uh so by client credentials. I mean that long string in an app registration or their x509 cert that you upload those kinds of secrets putting them in code is usually a bad idea, so a good practice is to use things like credit scan, etc.

A

So when you check the code into your source code repositories uh that your code is scanned for those problems, so a common say problem or scenario that we run into is when developers who are otherwise very good at their own fields of work. So let's say somebody is very good at machine learning, but they're, not identity is not the main thing that they work on, so they frequently get confused about the nuances of different kinds of applications from an identity perspective.

A

So from an identity perspective, we see three different kinds of applications: public clients that live on surfaces that you don't control like a windows, application running on your windows, pc for example, and many others, or a mobile app on your ios device. So it's living on a surface that we have no control on so naturally we trust it less.

A

Then there is confidential client, which is like a web application running on a web server that you have some control on. So we trust that a little bit more. We call that confidential client and then you have service principles. Service principles are typically used for background tasks and they don't have refresh tokens and they use only a client, id and client secret by secret I mean a string or an x 509 cert to get an access token, and they must rely on the client secret now.

A

The difference between these three is that the confidential client and the service principal are the only kind of applications where you should involve a secret and even in service principles. I'll talk about this shortly, you should properties manage identities in public client applications. You should never put a secret in the application itself. So what's the solution? Well, as I said in public clients, don't use secrets in the client embedded in the client itself.

A

Of course it shouldn't be in code anyway, uh but not even in the web.config or or you know, plist or anywhere don't put secrets there confidential clients. You should prefer using secrets to keys, and you should leverage key vault and manage identity to read those secrets. So our code, samples for sake of simplicity, show putting the secrets in dot config, and that is okay. It's a good start. At least it's not in your code, but there's still the risk of accidentally checking the secret into your code, wrapper so use credit, scan, etc.

A

But the best approach is to leverage manage identity. What is a managed identity, managed identity is an identity where azure manages the secret for you, it'll automatically roll it over. You never get to know the password. You don't care what the password is. There is azure sdk, which has got development paradigms, so things work without a managed identity on your local machine and with a managed id in the cloud right and again, if you are using secrets, remember to roll them over frequently for service principles.

A

Currently, we support managed identity working in a single tenant. Only of course, we know that managed identities working in multi-tenant environments is not something that works currently, but still you can provision a managed identity in the other tenant for now, and you can use try to use key vault in the other. Tenant to you know, read secrets if necessary, where you must use a service principle. Of course.

A

This is a limitation that we're aware of, uh and it is on, our radar, so I don't have any specifics to share with you know how we intend to solve this, but it is definitely something on our radar so having a managed identity reach across tenants. For example. That's what I'm talking about so I see that there's a lively chat going on as well you're welcome to ask questions there. So when harish is talking I'll, try and moderate the questions, and vice versa and I'll move on to the second topic, which is consent prompt.

A

So in this topic, let me first talk about what consent really is. Consent is the process of a user granting authorization to an application to access protected resources on their behalf. For example, an application, a is granted consent to have access to user's calendar or application b is consented to read one drive.

A

Of course, an admin can also grant consent on behalf of users in the organization, so that is what consent is so coming back to this problem. We're talking about here. The issue is that the user is shown unnecessary, consent prompts and signing into the applications. So, of course, there are some normal reasons why consent may be shown. uh The set of permissions may have changed that the application requires. So you need to ask for consent or the application is using incremental or dynamic consent, or maybe the consent was revoked.

A

So there are some absolutely normal scenarios where the user can see the consent dialogue, and there are a lot of things that we're doing like consent policies to smooth out that pain as well. But there is one abnormal scenario that we strongly recommend our developers to stay away from, and that is the usage of prompt equals consent. Query parameter in the authorized, endpoint call when they make this call to azure 80..

A

So now, let's take a slightly deeper dive into this problem, so, as I said that sometimes developers will use prompt equal consent. As the highlighted portion you see in the authorized request going to the authorized endpoint and that will cause the user to see a consent dialogue for no reason. In fact, this is a root cause for almost 10 percent of the developer issues we see related to the consent framework across all our platforms.

A

In fact, what happens sometimes is that we saw this as one of our top customers is that they've disabled user consent from a manageability perspective and enabled only admin consents, but because the developer had this prompt equals consent? Users are shown this consent dialogue that they can't consent to. So they hit a roadblock.

A

So it's surprising because hey I thought I had already consented and it's very confusing for the user sake. I thought this was already consented. Why I'm being asked to consent again, so it can be very challenging. So what's the solution?

A

Well, the solution is very, very simple: prompt equals consent. You should just avoid it. Azure ad has a capability to handle consent, behavior intelligently and prompt for consent only if it is not provided already so developers should always try to have like the minimal sign-in experience, and there are scenarios where you will have to show the consent dialogue right. For example, you want to inform the user with the permissions. They need right, but, generally speaking, just avoid prompt equals consent. This is about 10 of the consent related issues. We.

C

A

So we just recommend that you don't use prompt equals consent, there's almost never a good reason to do that. Moving forward reply, urls! So again before I dive into the problem. Let me set the stage: what is a reply? Url in modern authentication, we work with tokens assertions, packets being sent, etc. So when azure ad is sending you a token, it needs to trust that that token is being sent to a url. It knows about.

A

So when you do an app registration as a part of that app registration, you inform azure ad that only send the tokens or the post request to such and such white listed urls right. This is any good identity provider would have this. This is not specific to just azure 80., so these white listed urls, you know azure needs to know the list of urls that are okay to send. The token to the problem happens is sometimes in your request.

A

Let's say the authorized endpoint as you see over here, I'm requesting that the token we sent to localhost 888 right, whereas the redirect uri is 8080.. So there is a mismatch. So we are saying that send me the request or the response to this at a url different than the white listed list of urls, that I have informed as ready about right. So that is the challenge you're running into the azure. 80 will obviously say: nope sorry not going to do this because I don't know who runs on localhost 8888 right.

A

So this is a problem. So, for example, when you use visual studio to you know, point click configure an azure id application. It registers a redirect uri for you, then you right click deploy to azure and you didn't update your app registration, but the url on which the site is running has changed so you'll run into this problem. So what's the solution? Well, the solution. Is you just need to make the reply urls match?

A

So if you see this particular error message, the simple answer is just look at the request that you're sending to the authorized endpoint.

A

You need to see what redirect uri you have specified there, which is shown as that shaded portion over there, and then you just see hey. Does that match my app registration and if it doesn't, then either you are asking the reply to be sent to the wrong url or you have forgotten to register that redirect uri in the app registration.

A

This is a very simple issue, but you'd be amazed how frequently we run into this so again just match the reply. Urls and you'll be good.

A

One thing I also would like to mention is we don't support wild card uris and that's for some very good reasons, and this is something that uh you know we realize there's certain platforms where you may not know what url your application is running on like sharepoint wordpress jubla like it's, it's a web part can run anywhere.

A

There are some well-defined patterns around that using state that we can use to get around that problem as well. But, yes, we do not allow wild card through our eyes.

A

Moving on to the next problem, where you have incorrect response handling leading to throttling failures. So what do I mean by that? This issue happens when the customer's application receives the http 429 too many requests response code, but then it continues to make more requests. So four to nine status code is a standard status code. Where the end point is trying to throttle you down. It is telling you that you are sending requests too fast, and the idea here is that uh you know this is a throttling mechanism that is standard across the industry.

A

It's not just for identity and for microsoft. Graph, for example, we have maximum number of requests that any endpoint would receive and anything beyond that you're going to get start you're going to start getting throttled in the case of identity, endpoints you're getting you're going to get a combination of four to nines, but sometimes to protect from ddos effects.

A

You may not even get a reply right, because if you just keep sending four to nine, there's still a possibility of somebody trying to like on an attack scenario, then we may just stop sending you replies right. So the question is: what is the best way to handle these four two nines?

A

Well, it's actually quite simple. When you receive a four to nine in the header of the reply, you will see a retry after header make use of that header, the idea being that just wait for the time specified in the retry header and then try and make a request again.

A

If you don't do that, you're going to get exponentially throttled down, so the retry after just increases exponentially to protect itself from ddos attacks so from for the identity endpoints additionally receiving a four to nine response is often an indication that the application is not caching and reusing tokens incorrectly.

A

So another thing I recommend is that you set up log analytics and try and identify if there is an application that you have. That is asking for tokens too frequently. An access token is valid for about an hour an hour and five minutes. So is there an application requesting a new access token, every five minutes or one minute, the log analytics, will tell you and you should look into that- to try and identify poorly written applications on your platform and again, if you use m cell m cell, will do a lot of this token.

A

Caching, for you token, refresh and retry mechanisms are built into msl. So these are things you don't have to worry about when using m cell, but if you're using some other oid c compliant library or if you're working at the protocol level, then you may have to worry about that. So again, just to summarize this point, customers applications resiliency will be impacted if they don't handle four to nine requests, gracefully and they should look for retry after header and wait for that amount of time before sending more requests.

A

So with that I'd like to hand it over to harish for the next four problems, we see on the microsoft iot developer platform over to you, harish.

B

Thank you sal, thanks for that. So, as I was talking about a couple of things related to it, I would like to go ahead and continue from there in terms of the next set of issues that we generally see are been interfacing with common applications. What are the ways in which we can make the experience better so before that I would like to go ahead and touch upon the types of tokens that we have in the identity platform. That is id token access token and refresh token. Now these are not specific to identity platform.

B

From a microsoft standpoint, these are oauth and open id connect, specific frameworks, and when we go ahead and leverage these tokens, this needs to be a certain understanding in terms of what these artifacts are. So id tokens are ones that are used to validate who a user claims to be.

B

So uh that's the primary use case for an id token, access tokens are the main ones that are used to go ahead and perform authorization, decisions to securely access, a resource, and, finally, the refresh tokens are the ones that are used as an artifact to exchange access. Token pairs in a long running transaction or an application that is designed to go ahead and run continuously so with that default expectation set.

B

Let's move on to the problems that we generally see with these implementations, so id token, as you mentioned, is from an authentication standpoint and not to be used from an authorization standpoint. Do not go ahead and leverage an id token in a javascript application or, let's say even an asp.net application and say that hey the user has given the id token I'm going to go ahead and accept that as an artifact and I'm going to allow him login and perform all the operations.

B

No, you cannot go ahead and use that and you will need to go ahead and enforce for an access token, or ideally, an authorization code grant flow so that a code can be exchanged by the web application for an access token now coming on towards the access token scenario, so, in terms of the whole access token itself right, we have seen scenarios where the customers go ahead and build one application.

B

Let's say from a test standpoint or from a primary application standpoint or from an api gateway standpoint and then host multiple applications behind that layer and reuse, a single application, registration or maybe, let's say, reuse, an access token that was issued for one application and just to perform the signature, validation and reuse. The token that hey the user has authenticated to azure id and got this token to access app one.

B

Let's reuse, that, because, anyway, that's a proof that the user has authenticated, let's validate the access token and grant him access to our service as well, no not recommended from a security standpoint.

B

Second, in terms of going ahead and fetching a lot of critical information, let's say it: let it be profile, let it be profile picture, let it be user details or even let's say we are going ahead and talking about advanced scenarios such as fetching files, calendar and so on, and you're leveraging microsoft graph in your application again leveraging the access token that we have received for graph to make the authentication slash authorization decisions.

B

Again, it's going to be a chart token or a jwt token, which is something that could be decoded and then going ahead and using that to actually make the authorization decisions again is not the right valid use case. And finally, this is something uh that we have been trying to go ahead and reiterate, and we have documented a lot of scenarios around this, relying on undocumented claims in the application logic.

B

There are scenarios where, let's say you're getting a token for microsoft graph or there are scenarios where you're going ahead and getting a token for your own web api, and you are the opening the access token you're, looking into it and you're trying to go ahead and use certain values. In that token, to take business decisions again, the values that we go ahead and recommend you to use should not be undocumented. Once again, why are we going ahead and saying all of this? Let's go ahead and look at that.

B

So the id token, as we are saying when an application goes ahead and authenticates a user or offloads the authentication to the idp idp issues, the id token as a validation that the user is authenticated and it gives you the details: hey did the user authenticate using mfa? How did he authenticate what was the standard? When did he authenticate?

B

That is what you can go ahead and leverage, and maybe you can use things like display, name profile, picture and use it for ui elements at the end, if at all, if you're having a public client, let's, let's talk about a mobile mobile based application, let's talk about an application that does not have any client-side logic and it only acts as a ui to let the user log in and access backend components, then again id token can be used in those scenarios, but any access to any data needs to be protected behind an access token.

B

Now, moving on to the access token, so we said that do not go ahead and reuse, the access token and the logic for that comes in these values. Officially, the guidance from an over standpoint is whenever you go ahead and get an access token, the issuer and the audience needs to be validated at the bare minimum. We want to make sure that hey the user or the issuer who's coming from is someone that we understand, because we need to know whether our application is a single tenant application or a multi-rent application.

B

Whether do we want to allow users from other tenant or not, and if at all they are coming from other tenant, how do you know that they are coming from other tenant? That is where the issuer value is going to help out where you are going to have the tenant id that is going to be called out inside the token. That is the access token in the issuer field.

B

Similarly, the audience value is an indication that says that hey as a client, he has explicitly requested for a token to access a specific resource, and that is a resource that you have defined yourself as an identifier.

B

So these are basic scenarios, or these are basic validations that needs to be done by a web application or a web api, irrespective from a sanity standpoint to make sure that hey the access token that I'm getting is coming from the intended user and two it's for me: I'm not going ahead and using an access token that was issued for another application and finally refresh tokens. Again. As I said, these are opaque blogs. You cannot decode them. These are only decodable by the azure active directory, authentication system or the identity platform.

B

So, therefore the idea is to go ahead and cache it and use it in desktop applications or applications that goes ahead and have a long running transactions where, when your access token is going to expire, leverage, the refresh token and use it to exchange for an access token, silently so that you don't need to perform an authentication again now, in spite of calling out all of these scenarios, one thing that we would like to highlight is: if you use our msl sdks or the microsoft identity.web libraries that we have for asp.net core.

B

All of these things are taken care by default, the for the valid use case of id token, in an authorization code grant plus hybrid scenario, the valid caching and the valid validation of the access token based on the issuer and the audience fields and the effective management of the token cache using refresh token, is taken care and is obscured from the application developer, where you don't need to go ahead and worry about any of these things, and that reiterates the point you reuse or go ahead and try to see if we can leverage our sdks, because these are the basic constraints, if you take any platform, be it.net, be it javascript or anything else.

B

Let's move on to the next use case scenario, so clock on acquisition. So we said that hey. These are the three kinds of tokens. Then these are the right ways in which we want to go ahead and use the tokens and then finally, we also said that please use msl now that we have told use msal now, how do you make sure that you use our m cell sdks and make the effective use of the token caching mechanism that we have available?

B

So in that, when we are going ahead and leveraging our msl sdks, we have seen scenarios or we have seen implementations where either the developer goes ahead and puts in scenarios that goes ahead and requests for authentication every single time one or goes ahead and puts in scenarios into the application where certain scenarios, such as step-up authentication, mfa or conditional access or device control are things that are actually not handled or it's. Those are things that are not being taken care of when the application is being built.

B

Maybe from a testing standpoint, the the application works perfectly fine with the test user account because it's not protected the id team has not enforced any uh security policies on top of it and things just work. Fine but the the moment we move that application to prod. Then that's when things starts failing, or maybe let's say we start getting issues or notifications- that a subset of users alone are not being able to go ahead and access the application. Now. Why does that happen?

B

That's either due to let's say going ahead and putting in token execution or token acquiring mechanisms in m cell and using the interactive options every single time or, let's say you're you're, not using any m salary implementation you're using a custom implementation, as sahel I mentioned in earlier, and in that you're again going ahead and not implementing an effective caching mechanism, you're again going ahead and doing an interactive request and without going ahead and using the refresh tokens or you're basically going ahead and performing an inefficient experience.

B

Where you, you might be a web application and there might be thousands of users hitting your web application and you want to go ahead and call some backend resource on behalf of the user and then you're, not caching, the user's token at the web application layer, something called as a token serialization on a per user basis.

B

So these are some of the things that let's say, even if you're using msr libraries that we have seen causing ineffective behavior and the example on the right is like you're using an acquire token interactive function that is available in dotnet. Equivalent uh function.

B

For this is available in most of the platforms that you have exposed via m cell now, when you're going ahead and doing an explicit function that says interactive, you are telling the library please go ahead and ignore the cache we want to go ahead and trigger a ui based login, which is against the recommendation that we say if you have the cache, let's use the cache. Let's do a silent, login or let's acquire a token silently.

B

So let's not do that, but at the same time we are not saying don't use interactive at all using something called as acquire token silent or silent. Token acquisition mechanism alone is also not going to be enough to handle all the scenarios like ca, conditional access policies, mfa and so on. So why is that? Or what exactly is the best way to go ahead then? So that's where always start with a silent token acquisition.

B

The reason being you are trying to enumerate the cash that you have from a client standpoint and see that whether there is an existing session for the user who is logged in and if an existing session exists, use that session and try to acquire a token for the scope that you want, get an access token for the resource that you want silently and if it works, you can go ahead and proceed with your application logic.

B

But if, at all, if you are failing- and we actually get an exception or an msl exception, then we go ahead and capture it in a catch scenario and then use an acquire token interactive or the reason that we have marked it as x. Axis aqua token. Silent is a common functionality, whereas on a platform basis there are differences in terms of going ahead and using a quite often interactive, acquired token, using windows, integrated auth, acquire token using broker mechanisms acquire token using windows, authentication module on windows 10.

B

There are lots of variables in terms of how you can go ahead and acquire a token when a silent mechanism fails depending on the platform. But the paradigm is similar across all try for silent if at all, if you're getting an exception, let's go ahead and catch that exception and reuse. It or, let's say, use an interactive flow or use another flow.

B

That is not silent to go ahead and acquire a token, and this is something that is going to be the same paradigm, that we will go ahead and encourage developers to make sure that your application supports conditional access, device-based authorization and cae conditional access evaluation as well or continuous access evaluation uh as well, that we are going ahead and having in the previous state at this point of time. So that's about it in terms of the right usage of msa libraries in itself, so with that, let's move on to the next issue.

B

So so this is. This is boiling down to the use case of the right scenario for your application, so in oauth and open id connect and even the hybrid flow. There are scenarios where you use the authorization code grant. There are scenarios where you're going to use the hybrid flow and there are scenarios where you're going to the implicit grant or even the client credentials flow.

B

So these are some of the issues, or these are some of the problems that we have seen that can actually cause issues to the application, either from a usability standpoint or even from a security standpoint. So to begin with, let's take implicit flow for that aspect. Our msal js libraries v1 supports implicit flow. Our msal js v2, libraries that we have for react and angular which are in beta at this point of time, supports auth code with pkc proof code, uh proof of code, key exchange.

B

Now the reason why we go ahead and say that we don't want to go ahead and recommend using implicit flow is one is due to the implicit nature wherein the iframe based mechanism and the silent token acquisition systems that comes into play from an implicit flow use case number one number two certain browsers have already stopped supporting third-party cookies.

B

When we go ahead and do cross-domain calls, so you have an application that says: test.contoso.com implicit flow by design goes ahead and makes a backend silent call when your application is in your domain. That is contrasto.com and calls login.microsoftonline.com, which is another domain and safari, for instance, has already put a block for such requests.

B

So applications that's going to use implicit flow is not going to work and other popular browsers are also on track to go ahead and block this particular third-party cookies being exchanged across different domains very soon, so applications that are using implicit flow will break when that goes live. So that's the reason why we are recommending against implicit flow and migrate to opcode with pkc. If at all, if there isn't any reason, then we would like to understand, or we would like to go ahead and know it.

B

Please use the comments uh to go ahead and see if at all, if you have an app that's using implicit flow, and there is a specific reason why you're not able to go ahead and move to go to pkc, and we can see what we can do to help on that now. The other two are scenario based, meaning the ropc flow resource owner password credentials flow.

B

So in terms of this, this is a flow where you're going to go ahead and share explicit credentials to the authentication system and ask for an id token access token or an email refresh token for that aspect, to perform certain use cases now. Why is this bad? Imagine a scenario where you're, the global administrator or you're even an admin of some standard, and you have a script or you have some sort of an automation that is using this particular flow, which means your plain text: password is hard coded into that.

B

Let it be a devops scenario, let it be a simple powershell script, or let it be anything for that standpoint. Your plain text credentials is one going to be hard coded number two. It is going to be sent on the wire which actually increases the attack surfaces.

B

All you will need is just to go ahead and compromise it and that's going to go ahead and cause problems in terms of usage.

B

Secondly, going ahead and using this flow for federated scenarios going ahead and using this flow for mfa scenarios, device scenarios, so imagine your admin has went ahead and put in conditional access policies. Hey anybody who's accessing these thousand mailboxes.

B

You need to go ahead and perform mfa or device art, so we don't want to go ahead and allow unproved or second factored accesses to it, and ropc is going to just fail straight out on these scenarios. So again, there is no valid reason why we would say that ropc flow is required. It exists for certain reasons.

B

I will touch about that in the next slide, but again, let's not come to using or let's not go to a state where we want to touch upon using ropc in current world and finally, the client credentials flow using the client credentials flow, as sahil mentioned in the first issue that we talked about putting secrets in code.

B

So client credential flow is ideally to be used on confidential clients, because you're going to go ahead and use something called as a client id and a secret, and that secret can either be a plain text string or it can also be a certificate which is a private and a public key pair. So, ultimately, you have a secret whether it is a simple plain text or it is a certificate artifact.

B

So you don't want to use this on a client application on a mobile on a browser that is running on a browser like a javascript application, because you don't trust that end client device and you don't want to use a certificate or a secret that can be compromised as part of a reverse engineering mechanism or, let's say a fiddler or any of the mechanisms for which, because you don't have control of the client or the client application or the mobile or the client browser.

B

Simply put so that's where we go ahead and say implicit flow prefer using pkce auth code, pkc, msl, js v2 has native support, if at all, if you're, not uh or if you want to go ahead and wait for the public preview or the ga of our angular and react libraries, we recommend using the msal browser core v2 to go ahead and leverage that in your applications.

B

At this point of time, which is ga so that you can at least use it as a wrapper inside your applications and do auth code with pkca to begin with. But again the demsal angular m cell react. You can definitely go ahead and expect it to hit public preview very soon in terms of usability standpoint. Ropc again, as I said, end-to-end testing scenarios uh you you want to go ahead and perform some sort of a small automation.

B

You don't want to go through the loops or you don't want to go ahead through the bypass of mfa, exceptions and all of that then. Yes, that's the only scenario where you want to go ahead and look at ropc flows instead, if at all, if you're doing an automation as an admin, please prefer client credentials and use a secret or a certificate, the latter being the preferred option or even better use managed identity.

B

As I have mentioned in the first issue, putting secrets in code, the same thing applies here: we're just going ahead and touching on the actual flow. That's in the picture and finally client credentials use it only on the web. App side use it for server-side implementations use it for your api implementations, use it for your on behalf of implementations, but not on the client. So that's the main key piece of information and moving on to the last point of the agenda that we have today.

B

So this is a vast topic and we are only going to go ahead and give you insights of certain recommendations. This is a topic on its own.

B

We would like to go ahead and hear from you if at all, if you want or if you're looking forward to have an entire session on this topic, if at all, if you want please go ahead and enter it in the chat, and maybe we will work with steven to see if we can get it up in april or may, but for now we're going to go ahead and talk about hey when we are talking about mobile implementations, ios and android, how do we want to go ahead and perform sso, and when doing that, there are three options that we have at this point of time.

B

One is using the system browser the default mechanism, our msl sdks for ios and android depend on so in ios, it's going to depend on safari and in android it's going to depend on chrome, but again from an android standpoint. There is a capability to go ahead and have a different system browser as well, which is the default browser that the platform supports. Now.

B

The second one is an embedded web view, meaning inside your app you're, going to go ahead and render the web inside rather you're not going to depend on the mobile app or the default browser that you have and the last option is going ahead and leveraging a broker application and using the broker is the best case scenario that we have in this use case.

B

But again, as I said, not delving too deep into it, let's jump on the problems that we go ahead and see that, uh with mobile scenarios, first thing repeated login prompts imagine you have a mobile, you lock open the app you log in then you close and reopen. Maybe it asks again or you open an app you log in you, click on something else, but ultimately redirect back to the login experience now.

B

The reason why this happens is one you're, not using msl and you're, not leveraging the token cache all you're doing is just showing an embedded web view and you're just redirecting to the website that you have and you're not building a native application.

B

So in that case, if at all when we are talking about a non-native application- and it's just a wrapper that basically redirects to a url that is nothing but a website, then you need as an application, to have some sort of a caching mechanism uh that you need to implement with the web flows.

B

So that's the recommendation that we want to see in this in such scenarios, because you're not doing native development you're not going to use m cell ios or m cell android you're, building an app that just basically hits a url uses, a web view and reads: rx, not ideal. But again, what you could do is to have some sort of a caching mechanism so that the cookies the browser stores is stored when your application closes and when the application reuse opens. You make sure that you're not losing that cookies you're not losing that state.

B

Similarly, failure to go ahead and understand that, when accessing any application, you can always get mfa, you can always get conditional access because, for example, we as microsoft are recommending conditional access policies 100 from an mfa and device standpoint for all the users, and we are also going ahead and encouraging customers to enable risk based conditional access, meaning you might access an app that might work perfectly fine during testing.

B

But if at all, if there is any risk that is identified with a particular session, we might immediately go ahead and perform a step of authentication on that scenario. So never as an app developer anticipate whether you're going to get or you're not going to get mfa handy slack step apart or any sort of authentication failure. You always need to handle for it and failure to handle for that can cause problems.

B

And finally, a scenario where you are going ahead and using our adil slash, msa libraries, but there isn't a complete integration that has been set up wherein either you are facing issues with the msl integration itself, because one not configured properly or the second most common issue that we see is when apps are being built for intune integration.

B

There are two ways in which we can do it, and the integration in itself is not actually complete in terms of securing an application with msl, then going ahead and securing it in tune, as well as a complete option. So when any steps or any issues that occurs in that mechanism, we have also seen a lot of issues or we have also seen a lot of corner cases failing in such scenarios. So what? What can you do to make sure that we follow or we try to get the best experience so system?

B

Browser, as I mentioned, is the default mechanism, and we want customers or app developers to see if this can be leveraged instead of the embedded webview. The reason is this shares the cookies with the system browser, meaning user goes ahead and opens this browser logs into outlook logs into any of the microsoft application and sso cookie for azure id is set, and when your application uses the same system, browser based mechanism, you're going to go ahead and get the benefit of reusing that cache by default.

B

If you go ahead and integrate a sample without going ahead and enforcing an authentication broker, msal system browser is what the experience that you will see. Wherein you have your app, your app will react to system browser when a system browser based redirection will happen and then you're going to go ahead and sign in and the app will redirect back or once the sign in completes. The browser will redirect back to the app with the token for you to go ahead and perform the actions.

B

Now, that's the expected default experience that we want to go ahead and use now embedded webview, as we are talking about right in terms of the embedded webview use case. This is something that we want to go ahead and only use in certain explicit scenarios. Let's say you have an app, you are explicitly saying every time I open this app. I need to get an authentication done. Maybe let's say it's sensitive application. It has something to do with approvals. It has something to do with payroll, irrespective for such reasons.

B

So in that case, you can go ahead and choose to have an embedded webview and ignore the cache that is available as part of the system browser. But again, this is something that is to be used as an exception and not the num and finally, the best case scenario that as microsoft, we are going to evangelize. So in mobile. We already do this as part of our public guidance. You take our ios sample, you take our android sample. Our sample includes in code to go ahead and have the broker integration by default.

B

So if you said it set up the sample in a way that you follow the entire steps, you add the platform requirements for going ahead and onboarding a broker app and install the broker app that is authenticator or company portal on the respective platforms, then the sample apps by default, leverage the broker. The simple reason is you get sso for all the applications as an application owner?

B

You are basically offloading the entire secrets, token management to the mfa, or, let's say to the authenticator and a company portal apps and finally, you as an application developer, will be able to satisfy step up authentication mfa, conditional access, device-based, conditional access or even app enforcement. From an intune standpoint. All of those things can be leveraged only when you go ahead and use a broker application.

B

So, as microsoft we default to system browser, but our recommendation is to go ahead and use a broker for your lob applications to make sure that you get very seamless experience at the same time, the highest security as well, so that step apart can be satisfied in tune. Protection can be satisfied in those scenarios.

B

So with that uh we've reached to the end of the session and before opening it up for a q, a just a couple of things, what we would like to go ahead and use this forum to evangelize is: please leverage our microsoft q a and this is a straightforward link, azure identity, q, a that's going to take you to our community, where we have dedicated team looking into the community requests you we can go ahead and have eta questions. We can go ahead and have issues uh that can be raised if at all.

B

If you have a question in terms of how a feature works, please feel free to go ahead and use this as a forum to go ahead and begin with and if at all, if what are other options that we have specifically from a developer standpoint.

B

So one this link is going to go ahead and give you a bit more insights into what we're talking about from the microsoft q a so there are certain tags that we can go ahead and tag like an adal m cell that goes ahead and gives you that information, so that we get the right attention of the right teams so that we are able to go ahead and get the answers to you. If at all, if your issue is directly specific to a library or you have a question on it, please leverage the github issues.

B

We have our developers who are responsible for the github libraries directly reviewing these issues. We have the program managers who own these libraries reviewing these issues on a regular basis. So you know for it's an issue. It's a problem. It's a bug! Please raise it directly in the github.

B

That is something that will definitely go ahead and get you the visibility to go ahead and get that issue triaged and if, at all, if it's a specific feature requests that is form an active directory developer standpoint again, this is the link for it and finally, as a last option, do redirect us to our support if at all, any of these options are not helping you and you actually need a dedicated help or you need a dedicated insight to win. So with that.

B

Thank you thanks for taking time, and I think we have four minutes uh and if at all, if there are any questions, any feedback more than welcome, to come off, mute and share it on the call. uh If not, then I give it back to steven to close this one thanks: where do we get recordings for these calls.

C

So the recordings will be published on on youtube and also a link to the presentation will be shared in the description of the video in youtube as well. Thank you, so yeah. If you have any further questions that we haven't able to answer to you today, I would recommend that you use one of the links that sahil just posted in in the chat window. So the best place is microsoft. Q, a you can follow with any support or any technical questions in there, and thank you so much.

C

If you have some time, please fill out the survey and recommend any topics that you'd like us to cover in the future. We really appreciate you being here and you're, asking questions and sharing your feedback and your comments. It's great for us have a great day. Everyone thank you. Folks have a good day, bye.