Microsoft 365 Community Identity platform, 6 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deep dive on using MSAL Node to integrate Electron desktop applications with Azure AD – October 2022

Description

This month’s in-depth topic: Deep dive on using MSAL Node to integrate Electron desktop applications with Azure AD. In this session, walk through steps required to integrate a cross-platform Electron desktop application with the Microsoft identity platform. Enable single sign-on (SSO) for users and get an access token for the Microsoft Graph API. Use the system browser for authentication, subscribe to MSAL events (for user sign-in and sign-out), cache tokens on disk and MSAL Node for desktop apps. Microsoft Presenters are Emily Lauber, Doğan Erişen and Salman Salem. This call was hosted by Nandeesh Swami (Microsoft) | @Nandeesh_Swami on October 20, 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 November 17th 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

Foreign folks welcome to the monthly call. Today we have with us Emily, Dogan and Salman. Today we have our third call in the MCL JavaScript series. It is the last call we had an outstanding call, the you know the previous month and a month before that, with a lot of attendees, as well as a lot of views on our YouTube video. If you have not attended that call, I would probably paste in uh in the chat the link for those videos to check it out, uh but this call again exciting call.

A

We have a new topic deep tie on using M cell node to integrate electron desktop applications. uh Desktop application is very close to my heart. That's where I started my career at least so I'm really interested to see what folks have today we would love to you know, hear back from you. I will be sharing a survey through the call. uh Please provide inputs on what you think went well and what other kind of calls you would like to have or what kind of topics you would like us to present.

A

Like always, we will be recording this session, so let's be pleasant and we will be putting the recording into uh AK dot, Ms m365pnp. You can just go to that link, I'll, be posting it in the chat window and if you would like to uh keep yourself updated, uh follow these Twitter accounts, my Microsoft 365, Dev and Azure ad. uh You will be getting updates about this kind of cause, as well as a lot of other events, that our team puts up all right thanks a lot over to you folks,.

B

All right Emily, you would like to start sure.

C

So our agenda for the call today is we are going to start with an overview of msol node. uh We'll then get into some of the oauth 2.0 native app best practices. Then we get to the really fun part of what you're, probably looking for, is how to enable single sign-on using these libraries. Well then, moving to acquiring a token for Microsoft graph, what it means to call Microsoft graph and at the end, we'll have q at 9.. We do have pauses for questions throughout the presentation, so feel free to put your questions in chat.

C

uh You can write them down, hold them till the end. You can put them in chat. You can raise your hand and interrupt us if there's something, that's really not clear. This is our path for today.

C

So to start, we've been saying: the term M cell M cell is the Microsoft authentication libraries. We will focus this call on the JavaScript M cell. We do have M cells, we have other libraries for other languages. uh My focus is on JavaScript. I am the PM for the M cell JavaScript team.

C

What we're sharing on screen here is our package structure. So when we say JavaScript JavaScript is a large ecosystem. So we've tried to develop a few different ways to engage with this ecosystem. You can see on screen, we have our our common layer. More importantly, though, we have our M cell browser layer, which is what typically our single page applications we'd recommend that you use. We, that is a framework agnostic SDK.

C

If you like a particular framework, we have react and angular that you can use the focus of today's call, though, is going to be M cell node and MSL node. We do have a few different oauth 2.0 Grant types that you can do for it we'll get to the codes in the specifics later.

C

This is kind of an overview of the different things that you can use for, M cell node and other things within the JavaScript ecosystem, so MSL node does support public and confidential client applications, and I will note so node does do is based off of the node.js project. We keep up with the support schedule of the node.js, so that would be the even numbered stable releases if you're familiar with node.js as a framework itself, we try to keep up with those releases there.

C

That is our overview and then we'll get into specifically using MSL node in your applications.

B

Yeah, so um the demo application we're going to go through today. uh You can find this app on the repository here and Sal will also uh share the link in the chat window. Essentially, you can just go ahead and clone this register an app on Azure ID and then just start hacking in a bit more detail. You're gonna need a node.js version 14 or later, and then Azure ID, tenant I can easily get that through the Microsoft 365 developer program.

B

If you don't have any and I just want to start with giving a brief overview of electron as a framework and how msel fits into this so electron allows you to build cross-platform native desktop applications. The idea is that you write your code once and then you package it for different operating systems, and it allows you to do cool things like you could develop a UI framework and then a UI and then use it on your electron as as your desktop UI, and then you could also deploy it to web as a single page application.

B

Perhaps and an electron application is essentially made up of two kinds of processes: there's a main process which has access to your operating system and integrates with the native uis of the operating system, and then there's one or more renderer processes.

B

These are by default, isolated and they do not have access to node or the file system, and these two kinds of processes communicate over what is called the inter-process communication and they can exchange data between them through this way. So, in an architecture like this Amazon node comes into play on the main process, node site, we essentially handle authentication in the main process, and then we share our authentication State uh with the renderer processes through the IPC Channel.

B

Now, let's go into a bit more detail about uh what are the best practices for desktop apps for all outs, so most of this is outlined in the RFC 8252 memo.

B

In summary, desktop applications must implement the proof key for codex change, which is an extension on top of the authorization code flow. This is the mechanism that prevents authorization code, replay attacks, so absolutely no implicit flow for a desktop application, and it is also recommended to use an external user agent for authorization requests traditionally desktop applications they've been using either an external user agent. Typically the system browser on your on your machine or an embedded user agent as a webview, perhaps on your UI.

B

So this has several drawbacks.

B

One of them is that the host application running the webview would be able to access the credentials that the user enters, which, which is essentially the whole idea of oauth, that the application shouldn't be exposed to the user's credentials and that shouldn't be the application's responsibility, and it also uh makes it difficult for enabling single sign-on each time the user has to sign in again.

B

So if you use an Excel user agent, a system browser, then you could just leverage the existing active session with Azure ID, and this is what we are going to use in this demo.

B

As a redirect URI option native application is the desktop applications could use one of the two redirect URI schemes here. uh The first one is private.

B

Uri scheme, or sometimes called custom URI scheme, which is uh usually used together with an embedded user agent or you could use a loop packet dialect, essentially the localhost for communicating with the Azure ID with the IDP now interior, it's quite possible for a malicious application running on your system, to listen for these channels and intercept the authorization code, and this is why we need the proof key for code exchange mechanism which, essentially, even if your authorization code gets leaked, it won't be able to use by the attackers all right.

B

So our happy pad is single sign-on. But at this point, I just want to show you what up what the demo app we have here. So this is a very simple electron application. I'm just going to go ahead and install the dependencies and I want to show what we have here. It's the bare bones of a simple electron app.

B

We create a browser window which is going to be a chromium instance and we load a preload script, which is a script that integrates the render process with the main process and exposes certain apis from the main process to the renderer, and then we load the index.html file, which essentially serves as our UI.

B

We have some native UI controls here and eventually we're going to have three event: handlifts a login event, a logout event and a get profile event and step by step, we're going to add authentication here.

B

If you look at the index HTML file, this is a very simple HTML file with some bootstrap use this CSS framework as an important aspect. We Define the content security policy here, which states that this page cannot run any script other than what is exposed from itself.

B

So this is an important security measure that uh recommended by the electron uh documentation as well. You should definitely um follow that uh when you're building an electron application- and we built we import some render.js uh script, which is essentially handling our UI logic.

B

In my render, JS file I just assigned certain event listeners and then use this renderer API, which is coming from the prologue.js to exchange back and forth data between the main process and the renderer processes. Yeah, we can see the channels we expose in the below Js and that's pretty much it. So, let's go back to the slides and our happy path will be single sign on and what we mean by single sign-on is that you have an active session.

B

If your user has an active session with Azure ID, then when they try to sign into your app, they don't have to enter their credentials again. They will just be able to sign in without any prompts unless they have multiple active sessions. In that case, Azure ID doesn't know which account it needs to sign in the user to, and you can actually bypass this by supplying some login hint to the your authorization request. If you know the user's identity beforehand, so in a bit more detail, the process we're going to do is looks like this.

B

We have our client application, which implements MSL nodes using Amazon node, we're going to create an authorization request and load. This authorization request URL to a browser page. This will take us to Azure IDs authorization endpoints. If we have an active session, we can just get the authorization code back otherwise, you'll have to enter our credentials.

B

M cell node will listen for this localhost and grabs the authorization code from the browser and then exchanges it for a access token, refresh token, and also an ID token from the Azure ID token endpoint.

B

So all of this will be done by a couple of line of codes from Amazon nodes. A new API called acquire token interactive and we're going to just implement this step by step. So let's go back to our app. So I'll begin by installing.

B

B

And what I'm going to do is that I'm going to wrap MSL note into your class with a simple interface. Let's call this up providers.

B

We will also export this.

B

And this class will essentially have three methods: we'll have a login method.

B

And logout methods and I get token methods.

B

These will do async operations so we'll also add some keywords.

B

And in the end, I want to use this in my main JS file, I'll instantiate, this class.

B

And then I should just be able to do something like.

B

Again and maybe I can access the account information provided by this class, something like this to update our UI with the user's username. So how do we implement this I'll? Go back to my output provider.js.

B

Let's add a Constructor here.

B

Let's also have some member variables.

B

A an M cell configuration object will have a cache instance and we'll also have a account object.

B

And now in my Constructor I can go and set and instantiate MSL nodes. So let's first import this.

D

B

First, we need to create a configuration object.

B

And then we can pass this configuration to.

B

There we go now in my configuration object: I need to have a client ID and an authority at the very least so I'll go ahead and do this.

B

So now we need to register an application with Azure ID. So what I'm going to do is that I'll go to the Azure portal.

B

I'll sign into my admin account.

B

I'll select the Azure active directory service. If you don't see it here, just search for it.

B

Then we go to app registration, create a new web registration. We'll call this so I'm, not demo. You want to sign in users in our own tenant, so this is going to be a single tenant tab and we will have a redirect URI of the type public, client native, so mobile and desktop apps.

B

Now redirect URI will be http localhost.

B

We'll go ahead and register this. We get our client ID, we get our tenant ID. We go to the authentication blades. We could see that the platform is configured and our redirect URL is here. We could look into the API permission slate. We could see that by automatically I've been added a permission for Microsoft graph user reads. This will allow us to read the profile information.

B

You could do a bit more. We could add some optional claims to our ID token and access token to tell us more about the the signed in user. So, for instance, I could do I could use the ACC T claim to tell me whether the user is a guest in this tenant or not.

B

I could use the FWD claim, which will tell me the IP address of the user.

B

uh Let's go ahead and select login hint, which is a useful claim that we could use in single sign-in and single sign out scenarios.

B

So I'll go ahead and add this and then I'll just copy paste. These guys back to my app yes.

B

All right, so this is pretty much so in the configuration object. You could do more if you like, you could, for instance, configure themsel to uh log messages. Please tell essentially what's happening at any point in time.

B

So we could use some uh useful messages for debugging purposes and yeah, so this will create our public client application instance and assign it to the client application. Let's also assign the cache in this sample. We will have a in-memory cache.

B

That we could use this later on for adding and removing accounts all right. So that's pretty much it about instantiating emson nodes. Now how do we implement the login methods?

B

So, as I mentioned, the API we are going to use with MSL node is acquire token interact, so I'll go ahead and create a try and catch block here. Just console log data for the moment and we could have something like cost out response.

B

And the API we are using is this client application acquired token Interactive.

B

So this API, let's take a look at what it does.

B

It accepts the request, parameter of the type intellectual request, and then it returns a promise of authentication result which essentially contains your access, token and ID token, and the account object.

B

The interactive request type requires us to define a open browser function. This is essentially your implementation of opening your browser from your electron application, and then you could also use a success, template and an error template, which is some message that you could display to the user after the authentication is done or if it's failed, so I'll go back and I'll. Do this I'm going to define a function here called constant browser.

B

And here I'm going to use the electrons shell API, so let's go ahead and import this.

E

B

And then I can just do an external URL. Now we need to pass this to out response and then I can pass a success. Template let's say, are signed in.

B

Close this window now and then I could do a failure. Template.

B

And I could use some HTML in this as well. So maybe something like.

B

Yep that looks good and I could also load the HTML page as a template. So, for instance, I could do something like let's create a new file.

B

D

B

And then I can go ahead and just read this file here. So maybe call this says templates.

B

It will be so I need to read this file, so I'll go ahead and import. This.

B

And that'll be.

B

Foreign now you need to be absolutely sure of what is in this file template that you are using. You have to be sure that this is not running any script. That you're not aware of so be aware to properly sanitize this file, but essentially, after that, I can instantiate. The uh I can initialize the account with the account object from the authentication response and let's also consult this.

B

And that's pretty much it so we can now go to the main.js and we can just call this and then this account object will be initialized when the sign-in is successful. Let's go ahead and start this.

B

All right so here's my app and I click sign in the event fires. A browser window will open redirecting to the Azure ID and you can see that I have multiple active accounts, so I have to select one of them because I should already doesn't know, but I can bypass this by passing the username beforehand.

B

I'm going to sign into this account I've been prompted for consenting, so I'll do that and then my template shows up now. The app will not be automatically focused will not automatically Focus, but you could do this by using a deep link with electron check out our samples in the M cell repository.

B

There are ways of doing this for Simplicity I didn't implement this now, but essentially, if we go back to our application, we could see that the the the the user is signed in and we can see the identifier here now when you sign in you obtain an ID token, an access token and also an account object.

B

Msl will log this for you. uh You could see the parsed ID token and the claims inside this ID token. You could also see the raw ID token and access token when you sign in the the result. Is the ID token that you can use to customize your UI, but you should not use an ID token for accessing another resource.

B

That is what we will do by getting an access token. So, since we signed in, we should also look into signing the user out. So let's go ahead and implement this one. So logging out has essentially two aspects. First you'll have to clear the application cache for anything related to the usage and optionally. You might also want to end this, allow the user to end their session Azure ID, so that the next time they sign in they have to enter their credentials again.

B

So this is quite easy: let's go ahead and do this for the moment I'll just so look, and what I want to do is that I want to access the cache and use the remove account API to remove this account from the cache and also set this to null and now, if I want to redirect the user to the sign out, endpoint I could do this.

B

There we go essentially, this is your um Authority string, plus o out V2 logout endpoint, so by default, this doesn't know which user, which account it needs to sign out to user from, and you could bypass this if you like, by passing the a logout hint. So something like, let's improve this a little bit to do this, get out Authority.

B

And then we could use a logarith.

B

And this will be an optional claim. We have in our ID token called login hint it confusingly, but we could use this for logout as a logarithms and okay. So let's go ahead and rerun this and try it out all right, so I sign in.

B

Select my account back to the application now I can sign out.

B

I think something went wrong.

B

Oh, we didn't call this logout. Sorry.

B

Yeah there we go okay, we need to rerun this again and let me also use the login hint when we are signing in.

B

I want to know which account I want to sign in so I'm just going to use it.

B

Let's go ahead and run this.

B

So when you sign in what I call your interactive acquire token, interactive API does is that it generates. It creates a loopback server on your machine and start listening on a random port, and then it receives the authorization code back here strips it from the query parameters and then stops the servers. So now we are signed in and we can just test sign out.

B

Something went wrong again, all right. We couldn't access this for some reason, all right we can debug this later on, but essentially our application cache is cleaned out now. Finally, let's look into getting an access token for Microsoft graph, again I'm going to have a try and catch blog and the recommended pattern when acquiring a token is that you first try to get it silently using msl's acquire token silence.

B

If this is not possible, if interaction is required, you catch the error and then use an interactive method to get the rest. So let's do this.

B

B

Let's accept the token request in this method.

B

And then just pass this guy here and then we can return the alt response back to the main process.

B

Now, if this is not possible, we're going to get an errors which is called interaction, acquired alternative and let's go ahead and import this there we go.

B

Then we can just use an interactive method and I'm just going to copy paste this code here, but we'll probably need to refactor this later on. So let's do that they also pass our token request. Object to this method.

B

And then we'll just return this.

B

And if you have any other kind of photos, let's just console lock this one.

B

Okay, so if I go back to main I can use this.

B

Get token I can pass here. Scopes I want to get a token Force, which is going to be user. Read it also pass an account object for silent acquisition.

B

And that's pretty much it! Let's assign this to Ken response and then console log. This response.

B

You could also hydrate a UI, the account object and let's go ahead and run this sign in go back to the browser sign the back. If you go to the application, you can now click to see profile.

B

We will be prompted for this scope, say accept and then, if you look at our console now, you can see that Amazon just grabbed the response from Azure. It will contain our access token that we want to use later on, and this is essentially how we get an access token.

B

Now you could use this token for calling Microsoft graph I. Will let cell tell us about how to call the graph API, but before that, were there any.

E

B

E

Me see if I missed something from the chat. Yeah. One question was about how we hand the refresh tokens I. Think I missed there so where and how does MSL save the refresh token? The question was so.

B

Msl abstracts away the usage of refresh tokens as an application developer. You shouldn't be concerned with using refresh token. It will use it under the hood and it will cache it in its own cache in this sample. We are using in memory cache, but you could look into saving your cache to disk, but essentially the entire refresh token usage is abstracted away.

F

Is the cache configuration itself configurable Pi M cell, or is that something you do via electron.

B

Yeah, definitely you can configure it with M cell MSL has a um cache configuration options. um You could look into our samples as well. We have several implementations to show how this is done.

F

Is the token itself encrypted at all, or would that be something that falls to me.

B

Yeah they will be falling so um by default it will not be encrypted, but you could look into equipped in the entire cache file yourself or, as Emily can uh confirm. Msl can offer uh MSL that's working on offering a better cache Solutions encryption Solutions uh for doing this without uh involving the Developers.

F

E

I think we have also a question someone's losing his hand. Yes go ahead.

G

Hi I have a quick question so here when you are logging in light like uh it is going to the login Microsoft online.com like. Can we see that Network developer tools I? My social is like when it goes to login Microsoft online.com.

G

It is calling the authorized client right. So at that time uh it's like prompting us to logging in and when it's giving the 200 status codes.

G

So that means it's signed in so it is giving the code, uh based on the request that we are sending right like if you're going to send like a request type as code, then it will. It is going to give us the code sure.

B

All of this is abstracted away, but yeah. This is what MSL does it will take you to login.microsoftonline.com authorize endpoints uh with some query parameters to customize that uh screen you're gonna get when you go to that URL Azure ID shows you the login prompt and.

G

No then exactly it gets authorized like can can. Can we see that the network tab like for the one that you've developed.

B

Sure sure, let's let's go ahead and try this see if I have still it open.

E

I think you're gonna get it in the application. Oh, you might get it here. Actually, yeah.

B

Yeah I'm not gonna, get it's huge, but maybe I could do this again. Let's try.

B

If not, we could always use Fiddlers, but I don't want to use this right now. I, don't think we're going to be able to see that yeah, but definitely check out our documentation. uh We have more details how this works, but essentially, as you said, you go to the authorization endpoint and you will see a screen there. The Azure ID will show you a screen and if that screen, if you pass that screen, it actually is able to verify your credentials. This is what you will get an authorization code back to episode, yeah.

G

After this login Microsoft online.com, it is going to the auth Token right to try to get the token. So so first I get this going and then a post is there to get the token.

B

First, you get the code first in the URL in the in there's a query parameter.

G

Yeah in the response we are having a code and also when we are seeing uh in the cookie right in the application tab that we can see that um cookie is also generated. So does that mean uh that this is authenticated.

B

Yeah, that means that you establish an active session with usheriti, essentially, but.

G

Sometimes like.

B

Yeah go ahead, go ahead, but.

G

Sometimes what is happening is it's keep on looping through just like keep on uh redirecting to the page that the localhost page that it has been developed so I'm just trying to figure out like where we can see and from the network tab when I'm seeing the response, it says different message, but through Fiddler. Actually we are getting a different response, though.

B

That sounds like a bug. You should definitely be able to get all the network trays on the Fiddlers uh I. Just don't uh want to use in the middle in the call, but it should be all there and um yeah if there is a bug, definitely go ahead and file a bug, and we should take a look into this. Okay.

G

And another question like uh um it works for me like when I developed and when I'm trying to give it to none other developer. It is not working in the app registration that for them in their system, I try to log in and it authenticates.

G

So when I check in the app registration uh there is like single tenant, or we can even give just organizations and also personal account right. But if, in that case, like that's what I said, what is the reason that it will just work for one person because I'm the one who it's.

B

Very difficult, but but we could definitely help like if you file a bug or with the in any of the sports channels. We could help with that. But um it's very difficult to know. Without um looking at some Network trace and your application configuration.

G

Okay and the default uh redirect callback path for the M cell. Is it like sign in oidc for the identity provider.

B

uh That depends on what redirect URL you assign. So it's uh mostly it's up to you. What to direct URL, you want to use in some special cases, there's a set through direct URI, for instance, with our electron app. We have to use the localhost, because this is how the acquire token interactive API works. It will start a loopback server and listen for the localhost, uh but in like in a single page application, you have much more options.

G

Okay, and is there any reason that you used to just HTTP uh like in localhost, HTTP and https, both can Network or is there any restrictions over there? No.

B

It's just have to be HTTP. uh Https would um not entirely sure if it will be possible, uh at least not with the acquire token interactive API that we use it will by default, just listen for http, so yeah as far as I can tell right now it will be just HTTP, but in a single page application you could it's it's a bit more up to you. If you establish a https server to listen for, then you could use https localhost as well.

G

Thank you and for multi-factor authentication. Also, will there be anything over here or it will work perfect.

B

uh It is entirely up to um Azure ID what it's, what what it, what it prompts. So, if there's a yeah, if there's some conditional access policy there, uh you will be prompted for that. uh There are certain cases you have to you have to handle the response in your codes.

B

um We definitely have samples, so go ahead, check out uh code samples and you will definitely find something about handling conditional access or different conditional access scenarios. Sure thank you. Thank you.

E

I think we have another question as well. Someone else like with their arm uh speak. Please. If you have a question.

D

Yes, yes, so one quick question um so you're having to sign in every time you start the app I'm, assuming that's what cash and would take care of as well. Is that correct? You were cash on the Node side.

B

Not really so we'll uh well yeah, if you have something, if you have the valid access token in your cache yeah you could you just go ahead and use this if it's not if it's expired, for some reason, your ID token or access token, then you'll have to go to the Azure ID again, you might have an active session, an active session cookie with Azure ready. So you might just see a brief transition, but yeah. If you have a cache and if you save it on disk yeah, you will see much less redirects.

D

So to speak, so so you could attempt to do like a silent sign in first and if that fails, then you'd have to show the sign in page. Is that correct.

B

uh So, in a single page applications we have MSL browser, has an SSO silence method, which essentially opens a hidden iframe to do all of this, so the user doesn't see any prompts on the Node side uh if your tokens are for some reason. If, if your tokens are expired, essentially, then you won't be able to use the tokens and you'll you'll need to do an interaction and that will yeah. That will definitely take you to the uh authorization endpoint.

B

But, as I said, if you have an active session, cookie you're just going to get back to the application immediately after that.

A

Awesome, okay, thanks Logan! So let's get on with the session and probably we can take more questions at the end.

B

A

B

So let's sell to talk about how to call graph.

E

Okay, we're using graph SDK to call graph API. We recommend developers to use graph SDK rather than call the graph API directly, because graph SDK helps build high quality, efficient and resilient applications. It also provides a set of features that enhance working with all like Microsoft graph services, like embedded support for the entry handling Security direct payload compressions failing through collections, create touch requests. Now, let's go through the initialization uh first, we must initialized a client instance of the graph SDK. As we can see in the table.

E

There are two different ways to initialize the client instance in your application. The first implementation is create with client options where we configure a default middleware that allows the SDK to communicate with the Microsoft graph. First, we must create an instance of a class that handle authentication. This class must implement the auth provider interface and we and will contain the logic and will contain the logic of acquiring token, then pass the class instance as an auth provider in the client options variable to instantiate the client.

E

The second approach is create with options where we pass an auth provided function in the options while initializing the client. In this case the user has to provide their own implementation for getting the access token and refreshing the token. A callback will be passed into the author of the earth provided function that contains an access token or an error.

E

We're really implementing the second approach, because Ansel will handle the access token and the refreshing token for us, and then let's go to the next page, which is how we call the graph API after initializing the graph SDK we'll obtain an access token from MSL. With that acquiry permissions as Duggan should in the code before, for example, let's use the user read and pass the token to the graph SDK and call the endpoint me to get the profile information. So let's go back to the code and see how we do all of that.

B

All right, let me switch to branches just a second take.

E

B

Yes, you can all go away, you can do checkout app.

E

So, as you can see in the code here, we have a graph file. uh This is exactly how instantiated in the electron application, we have a function called get graph client. We pass the access token with that we fetch from msolve we instantiate the client and return the function, uh and then we go to the main.js, uh we'll go to the git profile and, as you can see here, uh we we have the request, token request, which is basically getting the token with the reads. After this we get the get Crow file function.

E

We pass the access token. We go to the me endpoint to get the profile information, let's run the F and see how all of this is working.

B

That's okay: it's installed dependencies again.

E

B

And then click on this foreign.

E

So this time, I'm gonna sign in as usual.

B

Oops we had an issue oops.

E

I think also I'd. uh We didn't test exactly. You didn't go.

B

Ahead and grab this again.

B

E

And also I think you're good to go.

E

Yeah sign in Parts, open interactively again redirecting pick the user and let's get back to the application, see profiles, and then you get the data basically of the user who's there.

E

You can get the token like basically on signing in as well, because someone asked me in the chat where we basically like pass the scope when you log in in the login requests, or you can actually basically ask for the token when you make a request to a graph and that okay, let's get back to the presentation again and we have more links for more data details on our tutorials in the presentations.

E

Now we'll take any questions, if you guys have any question for us if you'd like to want to use the chat- and you would like to ask the question we're here- if you want to use the chat, we're also available.

E

So in terms of using the browser, it's recommended to use the browser tools to to sign in the user and to get to your tokens, because the browser like you get all the security features of the browser and, at the same time you get uh like single sign-on at the same sense like I, can easily get if there is an active session available so and if we use that is more recommended to use this approach than using electron. Basically, internally.

B

So yeah I'm just going to say that approach is possible if you want and there's a sample in msl.js triple that if you want to see how it's implemented, but that is not a best practice. uh Essentially, yes, uh you do get an access token when you first sign in uh that access token.

B

So, when you're signing in when you're using a token acquisition, API you'll specify Scopes that you want an access token for now, if you don't specify anything, you will still get an access token, but that token is essentially the token for the user in for endpoints, which is an end point to give more information about the user's profile. But that is not a graph token. So if you want a graph token, you'll need to use a read scope.

H

uh Can you show us the code where the Scopes are specified and how the access token looks like please? Thank you sure.

B

So yeah, if you see um here, we have uh every acquire token interactive acquire token API from msol will have will allow you to specify Scopes tell these are the Scopes that I want yes and it will try to get those, so all of those Scopes should be about the same resource. So if you're, let's say you have you want to call your graph and you want to call your own custom web API.

B

You can only get an access token for a specific resource at one at one time. If you want different access tokens for different resources, you'll have to uh use another required token call. You know to make another acquire token call. You can, though, uh prompt the user to consent for all the Scopes that you're going to use later on in your application.

B

So if you just want to simplify the user interaction, if you want to minimize the user interaction, you could do that, but yeah, essentially, all of the required token apis will allow you to specify the scope.

A

All right, we have a you, have your hands up, go ahead! Ask your question! Yeah.

D

So we have an application that you know we host on a website and we're using msl.js and everything works. Fine. We are also providing a download like a desktop app download, we're using electron, but we're loading it from that website. We're not loading uh local files, we're loading files from that from our website and we like to get a better login experience, single sign-on and all that stuff, in that you know when we're using that electron app.

D

So how can we mix msl.js? That's in the single page application and M sound node? Is there a way to use those together like to somehow use MSL node to you know, get some kind of token and then pass that into the to the browser via ipcu? Do we have to have in our in our uh website? Do we have to have you know two code paths, one? That's when we're when we're using it on the website at one where we're using a node or an electron.

B

So there's um off the top of my head, I could think of a couple of couple couple options you could go there. um You could use the same application, registration for your boat web clients and your desktop clients and um and you're launching the desktop application from the web. I think you're talking about something like a deep link that when you click on it, it launches the desktop application. No.

D

It's just so it's an electron application, but instead of loading from file we're loading from URL, so in main.js we're calling load from URL instead of load from file, and it basically is basically a shell. But we use that because we want to access some system capabilities that you can't get when you're running in the browser so for customers that want that additional functionality hey go download. This desktop app. That really just includes this website inside electron, I.

B

Think you should be able to pass some identified about the user to your electron app when you're when you're loading it from the URL. It could be. If I understand correctly, the user can sign into your web.

B

App you'll have a unique identified about the user, maybe some login hint as well and session ID, and then you should be able to pass this to your electron application and then re-authenticate from there, and this should be essentially um an authentication without any prompts if they are sharing the same application registration and if you pass a login hint uh there's also a.

D

um Well, so the challenge is um yeah. Authentication works, fine when you're running it from the electron, but but you don't get single sign-on. Just for just the reasons you said that it doesn't doesn't work in electron. So what we would like to achieve is we can you know we can determine when we're running an electron?

D

Do the authentication using the system browser, but then can we then uh pass some code using IPC to msl.js and then use msl.js to to you know, acquire an access token using that code that was acquired from node.

B

um You could also look into um we recently at the uh we have a hijus puff flow, which is essentially you start authentication on the back ends on the Node site could be our web service I think they also could be an electron application and you get two authorization codes, one for your app one for your node app and one for your single page application or web application, and essentially those both authorization codes will be usable.

B

So that means you only sign in once, and then you get two authorization codes to use in each of your application: I'm, not 100 sure if this would be applying, if there could be some cases, that would make it impossible. But that could be another approach that you could look into. This is called the hybrid Spa flow. You would definitely find samples on the msl.js repo as well and some documentation on it, but it sounds like an interesting scenario.

B

If you want to go ahead and uh create an issue in the msl.js triple that could maybe uh generate more discussion. It sounds like an interesting scenario.

E

Thank you. We have a question. You mentioned access token Explorer in an hour. How long until a refresh token expires.

B

E

It depends as well.

B

It also uh yeah, so access token is by normally um will be one out, but there's a continuous access evaluation or some CA policy this this could change, uh but the idea is that you shouldn't be concerned about the token lifetimes. The idea is to whenever you need to call a resource like graph or your own web API, you use msol. First, you attempt a silent token acquisition and if that fails, do an interactive token acquisition and amsol should handle the uh token lifetimes, for you essentially.

E

I'll, send you a document that explains like the lifetime of the access token and the ID tokens, because if you looked at our documentation, you'll find the details.

F

Sure, I guess the the plain text aspect of this again was bothering me here. You know the uh I guess: you'd spoken to the refresh token encryption of that cache coming up in the future. But to what extent I mean this is a JavaScript application right. So it's kind of easy to read anyway. To what extent is the access token, and especially the refresh token protected from prying eyes on that system? Given that you know, that's, that's a key: that's just floating somewhere that has the full or scooped authority of the user.

F

For that whole duration. So I get that you can say you know revoke it if suddenly it's being used across the world? Okay, that's that's nice! But what about the same building you know how how susceptible is that to someone just scooping that and great now, they're me for 90 days.

B

So there are two sides of two sides to this: if you're talking about electron, specifically um the electron or the authentication, is handled on the Node side and.

H

B

Won't be exposed to the outside world, but it's possible that your desktop itself gets compromised. So.

C

B

Talking about that um yeah that is possible, it could be that um they could be able to decrypt your cache if your cache is not encrypted. That's if you're saving it on desk that will be exposed, uh so you could def. You should definitely look into encrypting it there is possibly um there's. One thing I mentioned is that another malicious application running on your system might listen for the uh the authorization code, but, as I said, this won't be used. This will be useless because of the pixie uh proof key for code exchange and.

F

Those are some of I guess I mean that's the JavaScript question there right. You know why why you can't give secrets to say JavaScript programs running in the browser is because yeah you can encrypt it in the browser, but they can pop open. The dev tools read your logic for how you encrypted it, and you know they can see how you did it and reverse engineer it.

F

So I guess if you, if you're encrypting it on the client side, yeah, okay, you're, you're, saving, you know the I, guess the the low level uh people just trying to read the value out, but how secure is that value? Really, that's I! Guess that's just a question. That's generally flummoxed me about just desktop authentication anyway,.

H

No, so how do you are you sorry? This is not going back time. Are you? Are you referring to using secrets in a client application, or is it something else yeah.

F

H

Never use a secret in a client-side application. That's number one public clouds, never yeah, simply because you don't do that yeah, so pixie is somewhere to get get some of the benefits of the authorization code flow. So that's the answer. You don't use secrets in a client application, because your client application will be installed in maybe a 10 or 10 million desktops, so which makes sense. The second one is that hey? Can somebody look into my flow uh while it's happening? It's not going to be somebody.

H

It has to be somebody who is an admin on the machine or has full access to machine if somebody has full access to machine. The fact that you know M Sales traffic can be seen is hardly that relevant, because everything.

F

H

Not compromise battle at.

F

The same time yeah, so if they can install Fiddler, they can read it yeah yeah.

H

So so the answer here is that uh msos basically rely on https and the standards that are available in the HTTP and the internet internet world out there to to provide the necessary security. uh It's not Beyond.

H

It cannot do anything beyond what what is available via say. You know the https protocol. If you have Fiddler, if you are inspecting https traffic- yes, you can see it, but can a random person see it? No unless they have access to your machine and if they have access to your machine administrator, you have a lot more things. That's a problem within your plate than just your app and the secret that it might be a single sure.

F

But because of the nature, I I'm, just not that familiar with watch on applications because of the nature of electron, somehow it's difficult to access its memory to say, pull the secret of it because I get. You know three hcps. You know unless they've got something like Fiddler intercepting those requests, they can't see the token actually go to my machine.

F

So unless I'm caching, that thing plain text or you know whatever they- they can't otherwise intercept it, but what's the security of them simply just again, if it's a browser, I'm popping the dev tools, take a break point on that line and just read the value right out of the variable. So to what extent is does Electronics pose that well I get the tokens Now secret, the, but it it has the ability you know if I take that token I can drop it in another request myself and I've authenticated.

F

You know someone else has already done. The authentication I now have that person's credential I'm doing the operation on their behalf.

H

So the tokens access tokens issued by australity are better tokens and you can technically yes use it anywhere. You want uh saving the token encrypting it when you save it and providing making sure that you practice least privilege, because you don't want very powerful tokens- are- are advised because of this. uh The next set of features that we are building is called proof of position. It's not available yet. But the idea here is that, in those cases the access tokens will also be bound with on the machine that they were issued.

H

uh That is basically to handle scenarios. If access tokens are, you know, picked up from one machine and used in another one, just because there are better tokens, it's a known issue to us, but it will require a lot of protocol changes and uh a set of you know: Hardware bound Q features that are available via operating systems and evaporative systems and Windows and Android and iOS. We are working on it, uh I don't know when we will be making it available, but but we are aware of the problem.

H

uh We are trying to fix it today. You want to make sure that, if you're caching tokens first of all, your tokens should not be very high privileged. If you have very high privileged scenarios that require very high permissions. Please use it in your server applications that are not deployed on desktops on users and number two encrypt. Your token cash correctly think about it is how you can encrypt it and keep it up to date by using MSL on a regular basis to re-authenticate users, as as you see secret. Oh, that.

F

Makes sense, thank you.

A

Thanks Kalyan I think you pretty much covered the important points there.

C

We are working on proof of possession. We have no public timelines or commitments available to that. If that is a particular thing that you or your company is interested in, feel free to reach out to me and I can see about including you and some of our our previews for features as we try to develop that if you're really interested, we love people testing. These features before they're available um so feel free to reach out to me about that. If that's something that you or your company is particularly invested in.

F

Yeah, can you drop your email in the chat, yep, I, I, guess I, just typed it, but I realized I could just come back off made again. Can you authenticate with managed identities, so you know sort of like how I guess I don't know if Visual Studio is doing anything with electron, but you know: I I know that occasionally I'm asked to resign back end. Can. Can you uh use the managed identity on the machine itself instead of logging in with the credentials the incel.

H

So manager entities are only can only be used for client, credential or app only for us, so you cannot sign in a user with a managed identity. Did that answer your question or yeah? That makes.

F

Sense sure, okay.

A

All right thanks a lot folks. uh Thank you for joining the call, and uh you know we would love to get your your feedback. We use this to improve our call. The next call that we have will be on the next month, which is going to be the third Thursday, which is November 17th, and we're going to continue with our MSL series. We will be having an MSL, Android call so yeah, looking forward to you, you all folks joining us and yeah thanks a lot for the eventful discussion. Thank you very much. Nandish.

B

Thanks everyone thank.

E