Microsoft 365 Community Identity platform, 19 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: New MSAL for React, Angular-January 2021

Description

In this month's call, James Mantu (Microsoft) shares an overview of the new offerings in MSAL.js for React and Angular developers now in public preview.

For more information, visit https://developer.microsoft.com/en-us/identity

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

A

My name is james mantu I'll. Take you through the new library that we have for himself the new authentication libraries specifically for react, and for angular we'll start by understanding what msl is, which is microsoft, authentication libraries that we use to gain access to resources protected by our identity platform, and what we have now is a 2.0 version for react and angular. So I'm going to commit to an assumption that the members on this call have actually interacted with our libraries, the earlier ones for 1.0.

A

So if you get lost or if you need some further explanation on anything, you can just let me know, but we'll go with that basic assumption.

A

So what we had was the implicit flow initially and we're moving towards the oauth code flow. Now I'll get a bit point to that right after this, but the bottom line is oauth code is more secure and with the new security that browsers are putting in place where they are blocking third-party cookies. The implicit flow really won't work, especially if you look at safari with its intelligent tracking protection.

A

Implicit flow basically has become untenable.

A

B

Could you explain a little more why implicit flow will no longer.

A

Work, that's what I will do on this screen that we are on now cool. Yes, so if you look at how this screen works, the thing with implicit flow is you you have your application. You send a request to your authorization service, whether it's microsoft or whatever it is. You give your username your password your credentials, and then you get your access token back in a browser fragment. Basically it's part of your url. That comes back with your access token.

A

Now. The challenge with that is your authorization service is a third party. It's not the same as the domain you're. Currently on. So once you start blocking requests across origin requests to domains which are different from the domain. The browser is currently sitting in. Then you have a challenge, because that request cannot go silently.

A

In the background, what we had been doing were using hidden iframes to pass the request to the authorization provider, but because of blocking those requests they cannot happen, silently without actual user intervention, which provides a very bad experience, because you'd have to keep on popping up for the user. To you know again once the token expires.

A

Does it make sense? So you are saying.

B

That, because of the course the course uh I I thought that microsoft idp allows this course to begin with right.

A

Because if you're on, let's say a website, I don't know, uh let's say: google for example right and you want to use microsoft, authentication the request your browser is currently on www.google.com.

A

You have to suddenly pass a request to microsoft.com.

B

A

Right so now, microsoft is different from google, and this is what browsers are currently locking, with intelligent tracking protection.

B

Saying the browser is blocking, but you microsoft allows the course, though, right because yes, that's what's supposed to.

A

Happen exactly, but by default, as google chrome safari as implement this feature, that becomes more of a challenge for seeing us, because the users really don't notice. They just set up a high security level. So you start having a challenge. The application or the user is one who has blocked calls on their site because they just set up default settings in terms of security.

C

Hey uh this is manish. Are you talking about like a course issue or uh uh third-party cookie issue here.

D

Yeah, it's yeah third-party cookies, yeah.

C

Yeah sorry, for that means I was a little bit confused, go ahead.

A

C

A

Cookies that have been blocked so that now has become a challenge with that implicit grant flow. So what we're moving towards now and the rest of the industry is the earth code ground flow. So, as you can see in this case, sorry I'll just go back one step. The implicit flow was designed. It does not have uh refresh tokens that come in whenever your token expires, you actually have to make a fresh request through the browser.

A

If you look at the oauth code flow as it was designed, you get an access token and you get a refresh token at the same time that whenever you want to re-authorize the user, you can use the um refresh token to get another access token, so in this case, you're not being forced to go back through hidden iframes or whatever you actually are calling your token server and getting your fresh token, uh your access aiming your fresh access token.

A

Using the refresh token.

A

This is what we have implemented in msl version 2.. This is now supported.

E

I I have a question: this is priyan uh yeah, so the same issue that you have mentioned about the third party cookies in implicit flow.

D

F

E

To a browser, the same thing can happen in auth code grant flow also right.

A

But you'll notice here the requests to get our token have been sent to our token server, as opposed to you can actually raise a request to your token server through an api call or whatever it is, as opposed to having to load an iframe which you can use to get your access. So now, you're, actually calling an api.

E

uh So, uh are you saying that the access token request to azure from a browser-based application in if they are using auth code grandflow is no longer dependent on the sso cookie correct? Yes, okay, make sense, yeah.

A

Okay, so we'll have this ppt available, you can go through the diagram afterwards. I won't get um so much into it, but rather I will want to just maybe take a look at the additional risks of the implicit flow which we're trying to avoid.

A

Like I mentioned, you get your token back in your url as a fragment of the url, so we start facing challenges of interception attacks and then because it's in your browser, your browser might actually just save that history, so these are just two additional risks that we found. That is forcing the whole industry to move away from the implicit flow.

A

So taking this further.

B

Going back to um and making sure that we have the closure on this, it is the cookie. It's not the course, because you are when you are doing the code flow. You are still from google.com the example that you are going giving. If I was on google.com, I would still be making the call from google.com to the microsoft identity, server.

B

The browser was stopping that you'll be stopped anywhere right that doesn't go away. What you're really saying is that now you know you're really working to make sure that those two cookies.

A

Are not shared exactly the third party cookies are what other browsers have been working on securing because of tracking. Thank you. Yes, so I wanted to take it a step further and look at pkce, which stands for proof key for code exchange, and the idea is that when you want an authorization token, when you want a token, you must prove that you're, the application that is supposed to have the token in our mobile apps and most of our spas we've had coded their credentials.

A

So if someone is able to get access to your to your authorization, your host codes, they can spoof that to get access codes from from your server, so the question becomes: how do we make sure that the person who is making a request for an access code is actually your application, not just some third party who has stolen one of you most codes and then using the refresh tokens to keep spoofing your application.

A

So what we have here is basically a proof of possession. What we're saying is that when I come and ask you for an access code, I want to know who you are and how do we do this? When you are raising a request for an house code, you pass what we call a code challenge, which means that when you come back and ask now for access to a particular resource, I need.

A

Are you able to pass me a code challenge and I verify that you are who you are so they have a verifier and a code challenge before I answer. I think I'll use this screen and then you can ask all the questions we have after that. So here's the client send the request to be authorized and with it, you'll pass a code challenge. Basically it is something that you can use as a sha-256 or whatever to verify yourself.

A

The authorization server then notes that code challenge and then issues you the authorization code and then you come and ask for an access token. When you ask for your access token, you have to send me the original code challenge which you sent. So I know that the person asking for this access token is someone who have already authorized, as opposed to someone who may have actually intercepted my oauth code and then it's time to use that to get authorization to my resources.

A

I would stop there if there are any questions.

E

What's the life time of this authorization code.

A

The oauth code, um you can define how long you want it to be alive, but mostly because the oauth code flow has refreshed tokens. The authorization codes will be valid for a very short while a minute five minutes, and then your refresh token will have validities of maybe 24 hours. So you have to keep reauthorizing.

E

And is authorized yeah the authorization code is one time use, or can we use it within that five minutes multiple times.

A

I need to confirm that I am not sure I.

D

Don't uh authorization goes, I believe this time are not, uh I don't think they're one time use, but they have a very short expiration and the msl library handles all of this. For you, msl.js version 2 handles trading the authorization code for the refresh token.

E

Okay, so that means we can reuse that authorization code within that five minutes because it is coming in the url just like the implicit flow, it will be reside in your browser history or maybe, if somebody sees that network proxy, they can see that authorization code and within that five minutes, if somebody captures they can reuse that authorization code correct.

D

This is what pixie helps protect, but I believe so I'll double check, but pixie helps protect. That.

A

Thank you. Yes, because the authorization code has gone with a code challenge. So even if I got that authorization code, I will not know what code challenge the application has sent and the application will have its own logic of generating its code challenge. So this is not a one-time thing like you'd have username and password saved in your application to use across all your installations.

A

This is something that you can have a logic in the application that keeps generating, and then the odd server is able to check the code challenge and validate that it's come from your application.

C

uh This is manish again, so is this something that you configured for your application to support pkc? You know you're, ready.

A

um Okay, as was mentioned earlier, is we built all that uh plumbing into the library so from your side? There's there's not much you'll be doing over here. When you register an application, a new application, you just simply add authorization and tell it to support the dixie.

A

That's all that will be happening from your site when you register your application on the azure portal.

C

So, does that mean that my application can support my client credentials plus pkc as well, both at the same time.

A

Yes, it does okay, okay, so if.

C

You don't mind, I mean that's just a little bit like diverted based on like like different provider. If you go for example, octa they, don't they let you choose one or either like client, credential or pkc.

C

So not sure. Is that something.

A

I I need to reconfirm on the question: okay, pixie and I'm client credentials, because what we have on azure, you can add different authorizations to your application.

A

So I know you can put in the autofluid pixel and, at the same time, have some support for implicit flow. Although we are currently deprecating our support for the implicit flow, if that's what your product is using, it will continue to be supported, but we're trying to discourage new applications coming in with the implicit flow and we are backward compatible. So you can actually support multiple authorization flows got it yes, so that was just basically a summary of what we are trying to do and what we have achieved.

A

So I wanted to take a minute just to basically run through how easy it is to create an application. You just need to go into the portal and register yourself register.

G

An application then, because this.

A

Is react and angular we're using node.js, and I personally am a fan of visual studio code or whatever editor you want to use. So you just sign into the portal you can choose which tenant you're using. If you have multiple tenants, you just select app registrations, put in a name select the accounts you want to support. I think most people go for in any organization directly and personal accounts. Then you register and that's it.

A

Then you've got a quick start page where you can download your your application and actually get up and running immediately and I'll. Take five minutes to show you exactly what I mean when I say you can download your first application. Your first react application actually log in and you're able to access microsoft graph.

A

So I was just saying that it's pretty simple. If you work with react all you have to do. Is we made it so simple that we tell you where to put your client id where to put your authority where to put your redirect uri, and this evaluates that in the quick starts, we've shared with everybody, so what you arise to use and all that there's very little plumbing to get up and running with your first product and utilize the identity service?

A

This is just for react. This is for angular and then once it's configured you just install get up and running. If you don't use the quick configuration it's our libraries, you can just get them directly from npm through npm install, so I'll actually show you one application that I have which actually follow these steps, and then I guess, after that, you'll have more more questions to ask just to show you what I mean when it's that it's pretty easy to get started yeah.

A

I wanted to use this simple example, for I had followed the steps and reset and downloaded so this is actually a react. Application on my side, which I downloaded from the website.

A

So you just go to the source. You just come to the auth config file.

A

And that's about it the way I'll show you the example you get. You can download this and you just have to set up these values. These are my values for my client. The authority is pretty much standard across and I'm redirecting to localhost 3000 the default port for nodes. I mean sorry for react.

A

So if I was to come to this and actually run that.

A

A

I already did an npm installed, so the label is idea. Then I just say sorry: mpm starts.

A

And quite easily, I'm able to get my first screen running. I can sign in whether I use a pop-up or redirect these steps already in place for you I'll try for the pop-up.

A

Because I'm already signing on this is my personal pc. It is already able to sign me in and I will not request my profile information. But yes, if you do this, you can actually get information. You can use graph to get as much information as your authorized to access and it's actually really simple to get started.

A

It takes about just this much.

A

You just have this one, one, um the auth config. You need to change it's a different file for angular, but you're up and running almost immediately in five minutes.

A

So I there wasn't much else we hear if there are any more questions, but it's really easy to get up and running with your fast react for your first angular application. It'll. Take you five ten minutes maximum we've hidden all the plumbing we've made it so that all the heavy lifting is sitting on our sides from your side. It's just a few configurations that you're up and running.

H

Thank you james. This is jen, uh quick question now I know. Typically, when m cell supports azure ad, it's very streamlined. Is there any difference when we're dealing azure, adb c, you know in this case you know. Typically, when we go get onto github, you see, you know um it's smooth sailing with the azure id and the second we go to azure adb, to see, there's always some quarks. We have to work around with it. So for this particular one I'm looking at for react.

H

Is that fully supported or is there something else we have to do if we're dealing with, let's say all's code per se, like you recommended here.

D

Thomas who actually kind of has been driving the the react library and also is very familiar b2c. Do you want to comment on that.

I

uh Yeah it, it is fully supported. Some of the same quirks that you might run into with browser will carry over into react just due to the fact that the services are implemented slightly differently. um But if you do run into any issues, we encourage you to open an issue on our github page. We try to resolve those relatively quickly.

A

J

I

J

Thank you, hi, it's rory, um the libraries. Are they public preview with ga public preview, not nga.

A

And do you have any kind of eta for ga we're looking at it within the next one or two months, but let me get to it so that I I give you actually something concrete, not what you randomly have yeah.

D

Yeah, we certainly like to have that mga sooner than later, the more of you that try them out and give us feedback on the faster that that happens.

K

Hi james, could you could you give uh a reason why someone would choose the msl library over say, for example, a more generic oidc angular library? What are the advantages in going with an m cell library.

A

Now don't tell him as a program manager driving these products. The fact that we've hidden all the plumbing is one reason I would go for it yeah. It takes me five minutes to get up and running if I'm.

I

Going to use a.

B

A

E

Properly industry supporters.

D

A

D

Me but someone else.

A

D

A

D

So some of the other reasons there are some you know: azure id follow zoe dc, for example, but there are some nuances with with azure id that our library for one is aware of and helps mitigate. uh I would say the other reason is that there are some features that we are shipping in azure id, that the amsoil libraries will support, that you probably won't get from a more generic library. So, for example, say we support proof of possession for access tokens.

D

I'm sure familiar proof of possession cryptographically binds access tokens to the browser that requested them, so that helps mitigate, for example, token replay, if those if those tokens are excellent from the browser. So that's like a really key security feature, for example, that our first party microsoft products are very much one um and we're doing additional we're looking at a proof of possession for refresh tokens and we're looking at other potential security features and enhancements, and you are probably not going to get those from a third-party uh library such as the one that you mentioned.

B

So I I have that I have one question related to the access token. Why is access token available on the browser I mean it appears to me: that's a broad user to system only the id token should be available.

D

Yeah so in terms of like, why is it stored in in local storage, for example? Well,.

B

Yeah, I I think to begin with it shouldn't be even available in the browser in the user context right in the user context. Ig token is the one that user needs access. Token is more for system to system like in a client, credential flow, it makes sense, but you know auth code flow and pixy flow, that's user to system.

B

You know, because you could take the access token and just log in so I I just wonder what was the thinking behind to have access to can available in the browser context.

D

Yeah so access this comes down the difference between authentication and authorization, so your id token represents the user, as logged in right tells you metadata about the user and about their session potentially, whereas an access. Token says that as the artifact that the user has granted you authorization to acquire data on their behalf from like a backend service, so microsoft graph or your own custom, backend api and access tokens can't be shared between resources. So an access token for microsoft.

D

Graph can't be used to acquire data for your back-end webinar, for example, and id tokens are not the appropriate artifact to use there. So, just because the user is logged in doesn't mean that they've granted you access to acquired data from from graph, for example.

D

So that's what access tokens help solve and that's why we expose them in this case, in the user context, in your single page application, for example, and we help mitigate some of the concerns around proof of possession, for example, is a mitigation to help address concerns around um tokens being replayed if they are excell traded through crosstalk scripting, for example, they're also short-lived, so they're only an hour that sort of thing.

B

Thank you that makes sense.

E

Thanks jason and thanks mani for bringing this up, so our security team has found one flow uh with this authorization code grant flow. We we have been using this in our organization and what they are telling is the user is logged in the single page application and they have the token the tokens are available in the browser cache and they can capture this token if they are putting any proxy like a bob tool or a.

G

E

And even after the user logout, they can replay this token to the end apa and get the response within that one hour of time yep. So what the issue that security team is bringing is, if some malicious actor getting the position of your machine or your browser, they can grab this token and they can replay this even after the user logs out from the application yep.

E

Is there any mitigation to that.

D

Yeah, so it's correct that we don't invalidate access tokens, so they are valid for an hour after they were issued, and that is a known trade-off that we have made as far as if those tokens are extra traded. Somehow, as you described so, if they're intercepted through man in the middle or they're, you know cross-site scripting, for example. Yes, they can be replay from another machine for the duration of their lifetime.

D

So proof of possession, for example, is one mitigation that we have for that, so proof of possession like I mentioned it, cryptographically binds the access token to the browser that requested it. So it can't be replayed if it's exfiltrated, it doesn't address the the expiration thing and again, that's just a known trade-off. There's lots of complexity that comes with invalidating access that we've decided not to make. So I would look at proof of possession.

D

That is a feature that has supported msl browser that if you are concerned about your access tokens being replayed by a bad actor outside the context of the browser that requested them. That is one of the mitigations that we provide for that and we're always looking at increasing the security of our products. All up.

E

Is this part yeah sorry to interrupt you, so is this proof of possession is only for the code code right code, but it's not applicable for the access token.

D

No, it is so pixie pixy protects the authorization code and then proof of possession protects the access token and then we're also looking at proof of possession for refresh tokens as well.

E

So, are you saying that the when, even though the malicious actor captures the access token, they cannot replay from a different different system they can replay from the same browser, but they cannot replay from a different system. Is that correct.

D

If they're able to export it from like local storage, for example, then correctly, they would not be able to replay it from a different browser or different system.

B

So, just to follow up on that, the access token is a you know is used to just like you said, to make api calls like graphic via calls right.

B

They probably don't have the context of the browser, so in general I could take an access token and from the back end I would make api call to get other data, or are you saying that this access token actually has something related to the browser? It can never be called outside of the browser correct?

B

Okay, so you mean I, if I make an api call, just direct http api call with access token, it will no longer work. It will only work from the browser where the access token was issued with your position.

D

Correct yeah so again, this is for only for proof of possession protected access token. So this is an opt-in feature and your back-end api that you are using the access tokens for, must support, decoding and validating these tokens. So again, this is not the default.

D

But yes, in this case, if you have a proof of possession protected, if you've enabled proof of possession in your in your middleware in this case, where you're validating your tokens and then you opt in to proof of possession for the access token that msol will acquire for you. If someone were to steal those access tokens from your local storage and then try to use them, they would not work.

E

Is there any documentation on that.

D

I believe we had documentation in the github repo about this. So take a look there, I'm not sure if we've documented it on like docs on microsoft,.

E

Okay, so uh I'm just just to make sure that we are in both same page. So are you saying that if we enable this proof of possession for access tokens, then the access token minted from azure ready will have a signature or a proof that okay, this access token?

E

Is the user got it from so and so browser and when he plays that access token to the apa in the api also, they have to go back to azure, ready and check that okay, this access token is came from so and so, and is it com this request, api request is also coming from the same ip. If that matches. Yes, access token is valid, if not.

D

It's able to it doesn't have to go back to azure id in this case. It's able to statelessly validate that. But that's that's the general idea. That's not quite how it works under the hood, but that's the general idea.

E

So that minded token will have a claim that by validating the claim, we can make sure that this is com originating from a valley.

D

That's that's part of. I don't want to get too much in the weeds about the implementation details, but that's part of it yeah, but again again, this is not the default, and this is something you have to opt into.

E

Sure, thanks so can you.

D

Can um yeah I'll follow up with that yeah and if you have more questions, feel free to ask on github? Thank you.

L

So does microsoft provide a api side library to do the validation or proof.

D

uh Yeah, I believe our net library supports this basically validating proof of possession I'll make sure that we have that documented. If so,.

F

Hey jason, this really here is that a documentation where we can refer to all these vulnerabilities and how this feature mitigates some of them and which one it's not mitigated.

D

Are you talking about possession? Yes, uh like I said, I'm not sure if we have docs up at the moment for that, but I'll I'll make sure that we do that. If we don't because.

F

That clarity is really helpful for us or in the field to help customers understand for sure. Thank you.

E

F

E

On the tokens so in the sample they have mentioned about getting a token for user dot rate say, for example, if I have multiple tokens accusations like sharepoint token graph token crm token, most of our application will have multiple dependencies like graph, maybe for getting the signed in user details or and sharepoint api to get the documentation or the content from the sharepoint or maybe for crm. So if, if you have multiple apas or dependencies so.

G

E

Is the recommendation uh from I mean the m cell perspective? Should we add these scopes like a comma separated one by one and get the tokens on startup itself or when.

G

E

User takes an action yeah on that.

D

Okay, yeah, I understand thank you. So our general guidance is that so you have, you know, there's two operations right, there's logging in and then there's acquiring tokens. So when you log in you can provide the scopes that you know that you're good, that you want your user to consent to upfront right. So if you have six scopes across three different resources, you could provide those upfront and we will prompt the user to consent to those scopes if they haven't consented already.

D

That being said, we only issue one access token at a time, and access tokens are only valid for one resource. So if you have access so, if you need an access token for sharepoint, you need an extra soaking for your backend api. You have access token for for graph, for example you so you can. You can provide consent for them up front and will issue exactly what it is. But basically you can provide all of those scopes up front and you're in your login calls.

D

So the first call to the authorized endpoint and then I think, we'll issue you one an access token for one of those and then downstream in your code. Basically, when you need you know, kind of the general guidance is right before you need an access token for a given set of scopes for a resource. You call acquire token silent and you provide just the scopes for that resource and msol will acquire an access token for that resource. For those scopes.

D

Does that make sense, so you can provide them all up front in in the interest of having the user can send, but then, when you downstream, you can provide those just on a resource or resource basis for each respective api. Each respective api calls and themselves will acquire an access token. Just for that resource. For those scopes.

A

Cool got it thanks. uh I think I would also add that, since like we mentioned, we have refresh tokens and we are handling the refreshes. So even if you call early before you talk about to destroy your session, um the access remains.

A

E

Got it another question on the conditional access policy for this authorization code grant flow so when, when what we have seen or what we have observed is when we are specifying only the application like we create a single page application, and when we specify that single page application into the conditional access policy, we are seeing that the policy is not getting applied and what the workaround that we have seen is.

E

We have applied the conditional access policy for the first token that is getting procured and we are applying the conditional access policy for both single page application and for that api custom. Ap.

E

So is that the correct way to apply a conditional access policy to a single page application using web authorization flow or is there any other ways.

D

I'm personally not sure the answer of that, so you might need to send that question.

E

Sure sure thank you and what about the adf for support uh to emsal 2.0, I mean with where both resistance flow does support, adfs or only azure, ready.

D

uh We should support adfs thomas. Do you have anything you can add there.

I

uh Yeah we do support adfs, but there are changes that you'll need to make to support cores on your adfs server.

E

Yeah, are you supporting the adf 2016.

D

Yes, is it 2016 or 2019 thomas that we one of them there's a specific dependency that you need to have. I think let me double check.

E

A

Any more questions.

C

Hey, can I go back to the the third party cookies again? Okay, so, are you guys changing anything on the server side on the cookies saying same side equal to none to lex? That's what you guys are doing or.

D

Because yeah the same site, we we've addressed the. So what? Basically? What browsers did was they made the they first rolled out same restrictions around the same site flag on cookies? That was done a year ago, maybe a little more. uh We we did all the work needed for that, and then that was like the first part of like the third party cookie changes that browsers were rolling out.

D

So we did all the work needed for that and then browsers are now going a step further, where they're just simply blocking third-party cookies in certain contexts and that's where and we, the work arounds, the mitigations for that are the amsoil js version, two library that uses the author flow, where we don't rely on third-party cookies for for most silent token acquisition, which is what james described earlier.

C

So if I have all the app that will stop working after some time with the implicit flow.

D

You're using azure id implicit flow, yep, so yeah, so if you're using azure id implicit flow, if third-party cookies are allowed, it will continue to work even with the same site changes that browsers roll out now, if the user is in a scenario where third party cookies are not available, so safari itp is enabled or chrome incognito, for example, the implicit flow is somewhat broken in that regard.

D

In that scenario, you can mitigate that by you can still acquire tokens using the flow you just have to do it through interaction, so you have to do like require token popup or or.

C

You cannot do behind the scene in iframe. That's what you guys.

D

Yes, the the token acquisition through an iframe is what is broken. So that is what m cell version 2 helps mitigate, because we no longer use hidden iframes to acquire new access tokens.

C

Which browser came with this like? Because I am chrome still supported.

D

Yeah so safari safari with intelligent tracking protection enabled they were they were. That was really the first browser and then, if you do chrome incognito like if you open income, you don't chrome, really any of the chromium browsers. So like the the new, the microsoft edge and incognito you'll, see when you open the ink, you know there's a little toggle at the bottom of the new tab screen that says whether or not third-party cookies are blocked that is on by default now. So that is another scenario where users would encounter that.

C

Got it? Thank you.

L

Are you aware of any technique in m cell where, when the pop-up is displayed, that we can make it stay on the top of the screen, so that the user.

D

L

Sight of the window.

D

Yeah so there's there's a there's like it yeah there's a github open issue open about this. We can't prevent the. I don't believe we can prevent the the pop-up from going into the background, but we're looking at ways that we can at least improve that experience. For example, if the user thinks that the pop-up is closed, then they click your login button again that we maybe focus the existing pop-up we're looking at improvements we can make to that because we're aware of that issue so keep an eye on our github and npm for releases.

D

And you can you can take a look in the change log to see if we've, when we've addressed, that it's definitely something that we're definitely looking to improve the experience, especially around multiple pop-ups.

A

Even alan, it back to you to help.

G

Us close out, yes, thank you james uh and thank you jason and everybody else who participated today. I love all the questions and the interaction, so this is really great, we'll post a copy of the powerpoint that jay should show today in the description of the video that we're going to be posting on youtube.

G

So thank you, everyone for calling it today. We really appreciate it and we hope to see you on our next call february 18th. So thank you so.

E