Microsoft 365 Community Identity platform, 3 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Enable Single Sign-On on Android Apps using MSAL, secured using Proof-of-Possession – November 2022

Description

This month’s in-depth topic: Enable Single Sign-On on Android Apps using MSAL & also to secure it using Proof-of-Possession. Integrate Single Sign On (SSO) for users on an Android application with detailed code walk through on how to acquire an access token using Microsoft Authentication Library (MSAL) Android and further secure it using Proof-of-Possession (PoP). Overview of MSAL Android, SSO and PoP. Enabling single sign-on via Broker and via Browser, integrating with a broker and reviewing the need for PoP. Q&A. Microsoft Presenters: Neha Goel and Shane Oatman. This call was hosted by Nandeesh Swami (Microsoft) | @Nandeesh_Swami on November 17, 2022.

Learn more
• See the full blog post for this call in the Microsoft 365 platform community blog - https://aka.ms/m365/blog
• Mark your calendar for next call on December 15th at 9:00am PT. Download the recurrent invite for this call | https://aka.ms/IDDevCommunityCalendar
• Microsoft 365 Unified Sample gallery - https://aka.ms/m365/samples
• Microsoft 365 Platform Community in YouTube - https://aka.ms/m365/videos
• Microsoft 365 Platform Community - http://aka.ms/m365/community

A

A

Exciting call this session I mean I started a lot of my development I mean when I remember my developer days. I used to be a mobile developer, working on xamarin and uh yeah. I think this is really close to my heart and thanks a lot Shane and nehav to agreeing to come on our community call to present about MCL single sign-on on Android apps. uh This is really exciting for us, like always, the call gets recorded. So we are going to record this call and we are going to host it on our YouTube channel.

A

You can go to our YouTube channel. uh Just go to that link, AKA dot, Ms, m365pnp, slash videos. You will be able to see all our videos. We do this monthly call and you can follow us on Twitter, Microsoft, 365, Dev and Azure 80 to get updates on what what's going to be. The next call. We do a lot of exciting calls. The next all is going to be on December 15.

A

with that nehao is our product manager here and Shane. Is our principal software engineer off to you folks.

B

Hey hi, everyone, I'm Neha, goel I'm, a PM on M cell Android team and I'm here, joined with Shane who's, a lead principal engineer, and we are going to co-present this topic today. uh So on. Our agenda today is overview of MSL Android.

B

What exactly is msat and and then we will dive deep into how you can enable SSO what is single sign on and what are the ways to enable SSO and then Shane is going to talk about what is proof of possession and how you can actually use proof of possession to protect your access token, and then we will open the slot for Q a so let's just dive when well. M cell Android basically enables you to acquire security tokens from the Microsoft identity platform to authenticate your users and access secured web apis.

B

So basically, when you're using MSL Android, you do not need to directly use the oauth libraries directly and write a code against the protocol in your application. It maintains the token cache and refreshes the tokens for you when they are close to expiring. You don't need to handle any token expiration or token Management on your own, and these are some of the list of features which are supported by m cell Android SSO with custom browsers and Brokers Azure adb2c accounts brokered auth, single and multi-account mode logging in global settings.

B

Today we are going to dive deep into how SSO works with browsers and Brokers using MSL Android. So what exactly is single sign-on? You might you guys might have already been using single sign on. You might already know single sign on it. This is a this is like a really great feature in identity which was developed and you know, is very, very convenient for end users. So basically, single sign-on allows end users or employees to only enter their credential once and have those credentials automatically work across applications.

B

Now what msal does for you? Msel works with a broker component, which gets shipped via Microsoft authenticator app, and it provides you device wide SSO across all applications.

B

Some of the biggest problems which you can solve through SSO is basically there is going to be less password management, which means less prone to human error, and it makes your system more secure and decreases the tax service.

B

It also improves overall efficiency and productivity by improving the end user experience by just letting them enter their password once and then just forget about it, and then apps will be magically signing them in now, apart from just the end user experience improvements, it also saves Enterprise quite a lot of it team time and money by not letting them do a lot of automation, integration and actually password research, because you know passwords are basically just not being entered too much, so there is less probability of forgetting the passwords or you know, losing the passwords things like that, so how you can enable SSO in your application using MSL Android.

B

There are two main ways through which you can achieve SSO in your application, so first of course your application should be using msal and then through broker applications, so broker application is a component which is a headless application by the way and and it gets shipped via Microsoft authenticator application.

B

uh This Microsoft, authenticated app is uh holds the broker component and the second way you can actually achieve SSO is through the default browser and using the cookie jar. So we strongly recommend you to use broker application for getting the benefits. Like you know, as I mentioned device wide SSO, it also provides you account management experience and conditional access, although it does require your users to download additional application, but then it only happens once so.

B

What exactly is broker and how SSO wire broker is achieved? Well, as I mentioned, the Microsoft authenticator broker is a confident, that's included in Microsoft authenticator, app and Microsoft authentication broker uh can be utilized to provide device, white single sign-on, and it also help you meet organizational conditional access policies and integrating with broker can provide. You uh benefits like conditional access device, wide SSO uh managing InTune policies Etc.

B

So the Microsoft authenticator app can be installed by the end user anytime through the Google Play Store. Basically, so there are three major steps which we are also going to watch in a demo today uh which we need to actually uh going to focus on while integrating with broker. So first, we would need to generate a redirect URI to enable the broker and then configure our MSL application to use broker. There are some config values which we would need to update, and then we are going to verify our our broker.

B

Integration um in the demo at the second uh way is, of course, is when your application is not using brokered authentication or you do not have a brokered application present on the end user device, then the other way of actually achieving the SSO is via system browser or also webview, uh to attain the SSO.

B

Now, let's just go into the demo, give me just one second and I'll share my screen again laughs.

B

So, as I said to enable SSO, you need to update configuration settings of your app and we are going to need two main things redirect URI to enable broker and value for authorization user agent, which is going to be defined in the config file of your application.

B

So I have a demo test application for demo, which I have already downloaded here. I have already downloaded our authenticated app where our broker is hosted and, let's just die deep. So first enable reader get the redirect URI.

B

You would need to sign into the Azure portal and select your application, go to the authentication, blade and click on add a platform select Android as your platform of preference here, and you would need to provide your applications package name and before this step, you would need to generate a signature hash using comma command line via key tool. I'm going to provide my package name here and I'm also going to share my signature hash and once I click on configure.

B

It has provided me the redirect URI. Basically, the redirect URI is the combination of my package name and the signature hash, which I generated using key tool, and this is the configuration file widget, which it has generated for me, which you can just copy right here from here and provide all these values here and paste it.

B

So authorization user agent set as default means if there is going to be a broker there is always going to be uh like P0 broker, would be the preferred option for any M cell enabled application. Every time when a broker is present on the on the system on the device, MSL applications, all the quiet token requests are going to go through the broker application. If broker is not there, then you can actually explicitly use values like, for example, browser or webview.

B

If you want to make browser as your default or webview as a default, so I'm going to go on the demo app here, so we have config file selected as default, and I already mentioned that I have downloaded authenticated app, so I'm going to click on. As you see, there is no account selected here. There's no account added here now. I'm going to click on acquire token, the ux here is actually provided by the broker application. You see, it is a little bit different from the browser system, browser or default browser.

B

Now, okay, what happened uh now I'm going to provide my credentials.

B

So we just got our first token and the token request went through the broker. Now, let me share the device's state with you. I am going to show you settings and accounts, so whenever you use broker for authentication that account which I used to sign in got added on the device level account management, and that is what helps us to basically share and get the device wide SSO and if I show you how this authenticated app looks like.

B

And if I click here on the sign in you will see this is this is already coming into list of the accounts, the account which I just used uh in my application. I, never added this account explicitly here. So this is what the advantage you get for the device wide SSO. You will get the account already uh in the account list for the end user to select and then authenticate now uh what happens if I go ahead and delete the authenticated app. What would be the scenario in that case?

B

So, let's just try that uh app info and I'm going to uninstall the authenticator app here. Okay,.

B

I guess it emulator restarted.

B

But now we do not have an authenticator app here. Let me just go to the test app.

B

And now I'm going to select browser, as my preference for signing in here to achieve SSO.

B

There is no account selected here because I deleted authenticator app. So therefore, all the accounts associated with the authenticated app got deleted from everywhere, because broker is what is managing accounts across device. So let's just click on acquire token.

B

So now you see there is a different ux you're. Seeing and now the app redirected me to the default browser which is which in here in this case, is scroll and now I'm going to sign in again and provide my credentials.

B

And we just signed in using the system browser, basically so the system, cows that actually maintains the cookies a cookie jar and if I go back um and, for example, I try to if I try to open Outlook.

B

Well, it has kind of already signed me in somehow using uh the same account which I used for signing into my test. App.

B

So this was just a demo for enabling SSO on using your system browser and developer application.

B

So there are a few things which I would like to highlight that what you need to keep in mind when we are talking about broker and what is the impact of broker overall, so whenever a broker is installed on the device, all subsequent interactive token request, like, for example, cost acquired token are handled by broker rather than locally by msat, and if, for example, broker was not installed before and I would have gone through the system browser first and then I would have downloaded the broker.

B

Basically SSO State, previously available to msat would not be available to broker unless I have actually used broker for authentication.

B

So it is going to ask me to sign in again and basically installing a broker doesn't require the user to sign in again, because uh you saw that the moment I actually signed in using my test application by default uh using the same account, I got signed in uh into the broker, and we saw that if I, when, once I removed the broker hosting application, all the user information in the account was deleted from my test application and also from the device.

B

So this is what we had the demo for uh SSO today and are there any questions.

A

I I see one question in the chat. It says any way to change the redirection page for authentication to an internal company, page or usage company branding instead of autobac SMS.

B

C

Believe there is but I'm gonna book her out here and see if I can find a link to the documentation. Unfortunately, of course when I search for you know, sign and customization I find everything related to Azure active directory b2c, but I believe that there is actually support as well for just standard organizational customization of the sign-in UI, but I will I will take it up for you guys here and I'll post it on the chat when I find it.

B

So I will hand it over to you Shane.

C

Yeah I mean I'll. uh There was a couple other questions in the chat, so I'll just briefly mention them. um You know that the broker uh we do the broker does do what's called device registration. So basically, what that means is you know when required the the broker? Will you know, prompt the user to register their device? The device then becomes known to to Microsoft, and we actually you know an InTune or another MDM service. Can you know report device health status relative to that device?

C

um We also keep track of InTune app protection. In the same way, we know which applications have been installed on a particular device and which applications have had into an app protection policy applied to those applications. So a lot of things are sort of bound up in the broker.

C

um You know one of his core responsibilities as well as authenticating the client applications. So we talked about the redirect URI that you need to create, and the redirect URI is based on the actually the signature of your application and so using that that signature, along with the package name, the broker, can actually authenticate your application, which is exactly how we do that for things like internet protection anyway.

C

So there's there's quite a bit to the broker feel free if you've got any questions to throw them in the chat I'm going to talk a little bit about possession.

C

This is that we have a current implementation, that's in preview with the MSL Android Library, uh where we have also the implementation completed um within adb2, so Azure active directory and the V2 endpoint. It's based on a specification that had actually expired a little while ago and now that that specification has been reincarnated uh as a new draft, and so you may see the specification referred to as demonstration of proof of possession or depop. So this is very similar to that spec.

C

It doesn't follow that spec to the letter, because again it's never really moved out of its draft mode, but it's something that Microsoft is interested in pursuing or you know internally for our own users of Office 365, and then we think it also has a value for for external customers, basically with proof of possession.

C

We generate an asymmetric key pair on the client and the where we ideally are generating that key pair in in Hardware backed storage, um that private key is held in that Hardware back storage and we actually take the public key and when we make our original access token request for, let's say Ms graph. We provide, along with that request, the public key, and so when we get back our access token, that access token contains that public key and then what we do. Is we actually take that private key?

C

We create a new jot token that wraps the original access token that was returned and we actually signed that jot using the private key. So now I have an envelope signed with a private key, but inside the token, is the original access token with the public key, and so our server software has also been updated to validate this kind of token. Now. Why are we doing this?

C

We're doing this because you know we want to. We want to be sure that when you know, you've got an access token that it's actually being sent back to a resource server by the client that it was actually issued to you know. The tokens today are bearer tokens, which means that if you are literally the bearer or the holder of the token, the service is like. Well, you have the token.

C

So, therefore you have authorization, and so there's no there's not a lot of protection in terms of token exfiltration, so in other words, if somebody was to intercept a token if a malicious app was to take a token and forward it to a different endpoint and try to use it from that endpoint, you know it becomes a situation where you know. Bearer tokens are a little bit.

C

They have some weaknesses, um and so you know we're looking to you know, increase the overall security posture and, and we see depop and proof of possession as a way of doing that.

C

So partly what's interesting about the pop token, in addition to the binding using the keys, is you can actually in that envelope? You can actually add additional.

C

You know address information, so when I create that that wrapping token, we actually ask you to provide the HTTP endpoint that you want to send the token to like the full path, as well as the hdb verb, which means that that token, even if it's intercepted it can't be replayed for just any purpose right today, access tokens tend to include all the Scopes which the user granted the client application in this case, when the client actually creates the jot token and again, MSL will look after all this.

C

For you, you don't have to do anything um you know, msol will generate the private key Amazon will make make the the request for the the the original access token. It will create the same jot. There's nothing you have to do. There will do it all, but the the additional addressing as another sort of layer of protection, because it's not a situation where you know I've submitted this token to do this operation and that's the only operation that it can perform right.

C

It can't do other operations against other endpoints that are part of the same API, so there's some pretty substantial benefit. In addition, it enables some pretty interesting scenarios where you can model your services somewhat differently, so you get to a situation where you could potentially have multiple physical services that actually use the same. uh You know app ID so effectively they they are. They have the same audience so, in other words the audience for all of these things could be. You know, service one right so service, one. The tokens are accepted here service.

C

One tokens are accepted here in this physical endpoint service. One tokens are accepted here in this physical endpoint. What's interesting about this is now your client application only really has to request. One access token, but what's also interesting, is- is that if those different apis have different functionality, Again by having that addressing in the envelope shot, you can say: okay, I can send it to. You know the the physical endpoint one, but physical endpoint one can't forward it to physical endpoint two.

C

So it's kind of you get some some very, very nice capabilities that come out of this and by having proof of possession we also get to a situation which is better for Microsoft. In terms of you know the the cost of running the business, and it's also better for you in terms of reliability, which is basically with with proof of possession where we're more comfortable, extending the access token lifetime, so default access token lifetime, you know historically, was an hour.

C

You know with proof of possession, we feel we feel comfortable, and obviously this is something that you know. Customers will have input on. You know extending these access token lifetimes. Why is that good? um Well, if an access token is expired and for whatever reason the you know, the security token service is inaccessible. uh You know you're not going to be able to refresh that token and that application is not going to be able to do what it was supposed to do.

C

So, there's there's sort of like a huge bucket of benefits uh to getting to proof of possession, and so anyway, I will dig into this a little bit. uh I'll be ready to answer any questions you have, but we'll go to the the sequence diagram here and I'll walk you through kind of the steps.

C

So I spoke to this, but this is actually a picture of what the flow roughly looks like so you're, actually invoking msol and you're, making a particular request for a particular authentication scheme. So, instead of making a request for a bear token you're making a request for a pop token, msol is going to check to see whether or not that key pair exists for your client.

C

If it doesn't, it's actually going to go ahead and generate that key pair, it's going to then take the public key and it's actually going to make the token request, as I said, with the public key, it's going to get back the access token with the public key as a claim. It's then going to catch that result. So now that access token is in the cache- and you can use that same access token now to generate multiple pop tokens.

C

So the the envelope you know the message, the original access, token that's going to be embedded in the wrapping jot gets reused, but each jot is is per request right because that, again, that jot is targeted at a specific endpoint, with a specific HTTP verb.

C

So you're going to be able to when that request comes in we'll generate that envelope, using the values that you provided us we'll sign it with the private key and then we'll return it back to you so that you can actually use it to make your API call any any questions on uh on anything here. So far, I think there was a question about uh for iOS. So for iOS, this is a work.

C

That's still in progress um right now, uh just to give you guys a sense of of uh where some of this is heading.

C

uh We already use a protocol very similar to this, and some of you may have heard of this protocol because it's documented for Windows, so mobile uses the same protocol, which is sometimes referred to as the primary refresh token protocol, and we use the same proof of possession approach to ensure that those sort of those primary refresh tokens, which are the ones that enable device-wide SSO, are bound to a device today and so we're doing some additional work to be able to assert the information from the device about you know what model of the device is this uh you know and is this?

C

Is this private key actually stored in in Hardware or not, and so there's some work going on on the on the PRT side and once that's finished then we'll be able to return to some of the more access token Focus work, but obviously this is very exciting for for us and very exciting for hopefully for you folks, because you know this is like I feel like something where we're actually going to be able to make a difference from a security point of view for probably in a fairly big way.

C

So for me, it's exciting, but I geek out about this kind of stuff I'm. Just looking here for another questions, uh yeah I mean I. Think in in general. uh You know our goal here is you know it's never straightforward to adopt a new. You know authorization protocol.

C

um You know, as I mentioned we're not just making changes in client applications. We have to make changes in. You know apis right, so in these various services that are out there have to also be updated to understand and be able to validate correctly pop tokens. So this is not a something that just we flip a switch, and you know we're all able to start benefiting from. It does involve quite a bit of work, but we think that the the the promise of this is very exciting.

C

Is the new pop token generated for every single request uh it can yeah? It depends. It depends basically on the um on the HTTP, endpoint and verb that you pass in. If we already have one, you know that we generated I. Think the validity of those tokens is relatively short, so I would say you can think of it as being done ever on every request. There may be some scenario area where it it will take it one from the cache, but those jot requests are kept to a very short lifetime, much less than an hour.

C

I think it's like 10 minutes, basically just the amount of time to deal with clock skew between the client and the server. uh Yes, so the work it has been done already to validate the the pop tokens.

C

So the MSL, our msol um server team partners and you'll have to forgive me because I'm a little bit unfamiliar with the various acronyms they use for their Library, so I think it's uh Owen is there's a the Owen packages that we have for for token validation, so I believe they've been updated at this point to uh to support validating pop tokens.

C

Okay, uh should we go to the I? Think, that's I think that's! Basically it right do we have another slide there and they are I. Think I may have already spoken to this yeah I think I already spoke to that yeah. So any any questions on that or anything else. uh You know and I'm sure, Neha and I are willing to field any kind of questions you have relative to MSL Android, but probably MSL in general we'd be happy to take a crack at it.

A

There is one question: are you making the API site code needed to validate the pop.

C

Yeah we are and I think the answer is yes, we will do it for more than just.net. uh You know so we're I think right now, from a middleware point of view, we support uh node, slash passport, uh so I believe there's there's something there.

C

That's coming along um and I think in general there's an effort that I'm involved in which I'm not going to talk too much about, but like there's a there's, an effort involved in um in in trying to figure out how we bring some of the the things that we're doing with middleware today to uh two proxy servers, um so I think like in general, it's difficult for us to support every language and framework out there.

C

uh You know our team doesn't can't necessarily scale to every language and framework that you know somebody might want to use, but we do think we can. You know light up identity scenarios using uh reverse proxy Solutions, like nginx and and others I think, there's a new pingora one, that's written in Russ from cloud fair and others.

C

So you know I think if we're able to do that, that will be a a benefit and hopefully enable us and enable you to you know, have a little more flexibility in what languages and Frameworks you choose to work with since you'd. Be delegating responsibility for things like token validation to the reverse proxy.

A

There's another question about a.net core Damon console application calling a protected web API. They have put a sample out there. uh Oh you are you asking for uh you know if we're gonna update that sample is that the question.

C

I think that, like the reason why some of these things are marked is not recommended is again like we're trying to figure out like what is the status and this kind of goes to the next question. What is the status of the of the public specification and and where will things land?

C

um That's that's kind of why it's still in preview. uh You know in in Android land as well like we're it's very possible that we will make changes here and- and we are still I- think, there's still some difficulty in terms of getting broad industry support for a depop, um and so that work is ongoing. You know I, think that if you and and your uh the organizations you work for or whatever your relationships are, if you have any you know, you know ability to influence these things feel free to to try to do so.

C

I mean I. Think personally, I feel like this is a very you know, useful security enhancement.

C

um You know, but I think it in some ways. It's uh you know. How do I say this I think you know, identity is uh is not static. Things are always moving. Things are always changing and I think you know we we've seen some Evolutions in the industry over the last few years that actually touch on some of the things that we talked about today. You know we have Google, you know who's very heavily invested in trying uh and encouraging folks to do authentication using the default browser.

C

um But of course, if you're doing that, then you know some of these capabilities become more difficult to implement, um and you know and I think that there has been some feedback. That's been, you know given to Google and I. Certainly, there's been some feedback given to Google by me and and by some others. You know that who are concerned about um delegating an authentication, Flow, To You know to to an external application.

C

Like a browser, um you know it's not a dedicated channel, for you know, authentication, it's not something, that's being provided by the by the operating system like Wham or like the Android account manager, so I think that there's some things here that are kind of still in flux, but I think like this part of like what we want to do here is share this information with you guys so that we can get a sense of you know how enthusiastic you might be about.

C

You know uh things like proof of possession and sort of see if we can figure build. Some kind of you know support uh for for getting this to a place where there is more. You know, interest in Industry adoption and more push to get this kind of thing. You know over the finish line, and it's not it's not a I, wouldn't call this either. It's not there's no Magic Bullets, so there there just isn't. uh So you know what we talked about today is relative to tokens. There's also similar discussions about how to protect cookies.

C

um So it's it's again. There's no there's no magic bullet here. I'm just gonna check the chat here for questions. Sure.

A

If you have free, has a question and I also see uh Patty's hand is up.

C

Yeah go ahead, Harry.

D

um Yeah, you said about that proof of possession that there's the audience inside the token that that is the one defining the token access or use the token. Yes,.

C

Yes, that's correct, so you can what what this sort of enables um so I, don't know how like uh how clear this is to everyone when you're, when you use Microsoft graph today, um you know Microsoft graph when you hit the the main Microsoft graph, endpoint, uh effectively you're, hitting a reverse proxy. It takes those requests and forwards them to different back ends, but you have one audience in the token it's Microsoft graph.

C

um So, but in the case of Microsoft graph, you have a physical reverse proxy, a place where you're. Sending that token, um you can imagine with proof possession access tokens that you don't actually need the physical reverse proxy anymore. I can Define one audience. I can have multiple separate backends that have different functionalities. So imagine micro services, for example, so I've got a one or more micro, Services set up that all um are the using the same audience, so they all accept the same token audience.

C

What what you can do is, you can say, I can Target the specific pop token to a particular endpoint, because I put the addressing information in the envelope and part of validating the. The pop token is to say yeah the pop token's valid and it was sent to me and to this specific endpoint, and so therefore I accept it when it's received by that that first endpoint, because that endpoint doesn't actually have uh the private key. It can't just take that token and forward it right.

C

So I can't take that token and forward it, um and so there's sort of like a two layers of validation that happens right. You have to validate um the the inner access token using the signing keys of AED, and then you have to validate the envelope using the public key that was contained in the inner token, um and so, if you don't have the private key, you can't forward that token.

C

So it enables you to get to a place where you need fewer access tokens to enable scenarios, um and so there's like the security benefit and then there's what I sort of sometimes refer to as like the the kind of the cogs or the you know, the the cogs benefit and, as I said and I, think, there's a reliability benefit as well, which is kind of attractive to me. Yeah.

D

The secret society is huge on on that one uh who is giving the private key that you use in the envelope, but can we give it ourselves? Is it always Microsoft.

C

um Right now you know msol has done it in internally, but this is like something that you know I think we would be open to discussion about. um You know we have some uh some protocols. You know that are proprietary protocols, internal to Microsoft that use again something similar where we do accept a private key, that's generated outside the authentication Library.

C

um So it's not out the realm of it's not outside the realm of possibility. From my point of view, we're just trying to simplify some of these things uh for for customers by handling it for them. The other thing it's nice for us from a from a conditional access point of view.

C

Is uh you know if you give us uh if you point us to a private key location, or you know, we don't necessarily have the ability to like know how the key was generated and what um and under what sort of circumstances it's being or how it's being protected right. So when we want to make a policy decision, it becomes a little more challenging because you know we don't necessarily know um is this: was this key pair generated in the hardware you know and what was the hardware exactly right?

C

So, if you're a very high, you know if you're a high security sort of customer, you know pharmaceutical government so on and so forth. You may literally care, like you may want to know like you want, want to have an attestation from the exact physical device, meaning you might want to actually have attestation at the chip level uh to know where the private key is stored. But this is getting a little bit more kind of complicated here, but yeah you can see see a scenario. Would that be interesting? Yeah.

D

Because I was thinking like the certificate based on the dedication that came to ca, I think Knight, that that would be like a perfect place to get the customer, some keys, the public and the private keys that connect them with this one, if it's possible so.

C

Yeah I mean I. Think it's like. If you see things like you know, one thing I'll really acknowledge is that you know Microsoft's a big company and sometimes we don't we're. We don't always see the opportunities.

D

C

Know connect the dots.

D

C

Feel free to feel free to help us right.

D

Yeah yeah, that's the reason: I open my mouth so.

A

I believe yeah I appreciate.

D

It about this one I had some ideas: yeah.

A

That's awesome. Thank.

D

A

Yeah, thank you. Thank you. uh Nia has put in a question. uh How do you learn about M, cell or identity related concepts for your application scenarios?

A

If you could uh probably help us answer that uh we're doing a lot of changes, we are trying to bring in new stuff, so uh this kind of information would really be helpful.

C

Any any other questions I'm just looking through the chat here I saw a question from Jeffrey Jeffrey I, don't know the answer to your question, but I can. If you email me, I can put you in touch with somebody who would be able to answer your question.

A

He's also asking, if there's a good example, that you could point to yeah.

C

I mean the same thing: I will, if you, if you, uh if you send me that with both those asks I can uh I, can connect you with the folks on the.net team uh who are looking after those things, you may have already run into jean-mark I'm very likely to send you to John Mark. So anyway,.

C

All right, oh I, put my emails right at the very top of the chat, um but I'll type. It here again here.

A

You can go to our YouTube channel. uh Just go to that link, aka.ms.m265pnb, slash videos. You will be able to see all our videos. We do. This monthly call and you can follow us on Twitter, my Microsoft 365 Dev and Azure 80 to get updates on what what's going to be. The next call. We do a lot of exciting calls. The next all is going to be on December 15., foreign.