Understanding single sign-on (SSO) with Azure AD and Microsoft Teams

hi everyone this video is understanding single sign-on for microsoft teams developers my name is bob german and i'm a cloud developer advocate at microsoft and something i've heard a lot from my teammates and our partners alike is that there's a common challenge in trying to figure out single sign-on when developing a microsoft teams application this video will attempt to explain the situation give you some of the theories so that you can better understand and troubleshoot your solution and walk you through some common scenarios for single sign-on with microsoft teams there are a number of reasons to support azure ad single sign-on in your team's application it's easier for users who don't have to juggle multiple usernames and passwords and it's much easier for team owners who don't have to match all of the m365 logins in their t of their team members with app logins when assigning permissions within the app it's also easier for microsoft 365 admins who can control access without having to set up saml or other federation it's required for monetization in the team store and for the microsoft 365 app compliance program which is a program that helps enterprise customers to purchase applications with confidence so what is sso we know that it's something we want but do we really know what it means it means single sign-on right well yeah is that mean one user id for many applications so i don't have to remember more than one username and maybe password okay or does it mean that people don't have to type their username and maybe their password or does it mean that people don't even notice that they've logged in all of these different levels of single sign-on are commonly used in different applications even inside of microsoft the microsoft azure documentation takes a fairly broad view of sso including federation technologies like saml that's not true for microsoft teams who has very specific definition for sso that makes the login experience completely silent and is definitely azure active directory specific our commercial marketplace where you would build a transactable uh offer that could be sold in the microsoft team store they have yet another definition of sso which is a little simpler than the teams one but still requires logging in directly to azure active directory and acquiring an access token allowing the application to call the microsoft graph api this video will explain all of that and it will also explain the concepts that underlie any sso implementation inside of microsoft 365. i want to start at the beginning because i know a lot of people who are looking to build microsoft teams applications have experience on other platforms and may be new to microsoft 365. microsoft 365 is a suite of cloud-based applications some of which have an optional rich client or mobile application but they all have a cloud presence and are capable of running in a web browser from the cloud directly these applications include familiar ones like word excel and powerpoint microsoft teams of course outlook for email and calendar and a bunch of others including onedrive and sharepoint for file access now what these apps all have in common is that they all share a common identity service called azure active directory which of course is key to single sign-on in microsoft 365 and in teams if you were to purchase a microsoft 365 subscription or get a free one as a developer and i'll put the link on the screen here what you're really going to get is one instance of azure active directory and access to some or all of these applications depending on the plan that you have and the content that users create using those applications they all go into a tenant which is a security boundary and an administrative boundary around all of that content and all of your directory information in fact the users themselves are registered in that same directory along with their login information etc there's also a provision for guest users to come in and collaborate with those users the guest users have guest accounts inside that same active directory although the login is federated with their home tenant or whatever other identity provider they might use if you write an application it also needs to be registered inside of azure active directory so that it can be authorized to access the content on behalf of those users or on its own behalf this is core to understanding how microsoft 365 works azure active directory itself is well it's an identity service it can authorize users who are accessing apps via web browsers native applications or daemon or service applications which may not involve a specific user and it can authorize access to apps that are running in azure in microsoft 365 of course or your apps even if they're not running in azure actually if they're registered in azure id azure id can authorize users and apps to come in and access those services one thing that's important about azure ad to our enterprise customers it synchronizes with the on-premises active directory service so users in a hybrid environment can get seamless access to their on-premises and cloud-based assets using azure active directory and active directory directory services on-prem azure id provides a consent model it provides for something called conditional access so maybe users are only authorized during certain hours of the day or if they are in a certain location it has provisions for self-service password management group management etc three core concepts in azure ad our first app registration applications that want to authorize users whether the client or the service side of that application they need to be registered in azure ad we have resources which is the services that those apps are using some of which may be microsoft services like the microsoft graph which is the main api for microsoft 365 or your own services and it also deals with permissions which are called scopes so for instance directory.read scope gives the app permission to read the information inside of azure 80's directory why bother with all this well some viewers may be used to an old school operating system where applications are just files in the file system and users can run any application they want and once it's running the application has all the permissions of the user who runs it this is the traditional method that is used still in a lot of desktop operating systems the issue is that users have no way of knowing completely what the application is doing so as this user is playing a game the game may actually be reading her contacts list and sending spam emails to all of them a modern operating system such as any of the mobile operating systems such as windows store applications and yes microsoft teams applications and azure id applications takes a different strategy applications need to be registered and the apps need permissions just as the users would need permissions then users and or admins have to consent to those permissions so we're gonna ask that gamer if it's okay to read her contacts she's gonna say that silly and say no and the attempt to send the spam emails will be thwarted so now let me show you a simple example of how this works i'm going to start out inside of the azure ad admin center now you can get to this at aad.portal.azure.com or you can navigate here from inside the azure portal or from the microsoft 365 admin center now what i'm going to do is access the microsoft graph which is the main api for microsoft 365 using postman in order to do that i have to register an application that postman is going to use to get authorization to call the graph so let me go find that application i've already set it up and just kind of show you what i have a couple values i'm going to need to set this up in postman one is the application or client id that uniquely identifies this application and also since this is a single tenant app and we'll talk about multi-tenant later it's actually pretty simple but since this is a single tenant app i need to specify which tenant and so the directory or tenant id uniquely identifies this tenant i've also set up authentication so azure ad uses a protocol called oauth 2.0 and one of the ways of authenticating specifically to a web browser based off is to redirect the user over to azure id where maybe they log in maybe they provide some consents maybe they do two-factor authentication whatever they do azure id if they've authenticated will send an access token or actually an auth code back to the application so that it can get uh the information that it needs to call the graph so that redirect back needs to be registered for security reasons and this is the special magic redirect url that's used by postman this postman is going to basically pop up a web browser for me to do my login i also have set up an app secret which is here and you can't see it anymore but when you first create one of these you have to save it away somewhere safe because you can't see it after that and i've also gone in and set up some api permissions so these are all for calling the microsoft graph you can see there's a number of them here i'm just going to add one and specifically i'm going to show this call which allows you to show what microsoft teams a user is a member of the logged in user in particular so let me just come down here i've already looked up this call and team.readbasic.all is the minimum permission to get that information so inside of the graph documentation they're very detailed about what specific permission scopes are necessary to make any one of the calls now i'm going to grant consent see where it says on the right admin consent it's kind of chopped off but that's just is admin consent required um that's different from what i'm doing here i'm actually just granting the consent on behalf of all users because i have an admin all right so now i've done that let's go over to postman and i'm actually using a collection here called the microsoft graph collection for postman and you can download it here i'll put the url on the screen and there's some information that i need to now put in here specifically that client id and the tenant id that i had copied from the app registration so now let's go find that api call in the list actually before i do that let me come down and show you that i'm going to be authorizing using the browser using what's called an auth code flow and there's the auth url and the access token url both of them have the tenant id and then the client id the client secret all that information is there and you can see that it's actually showing up uh underneath of these special tokens inside of postman and i'm gonna go ahead now and get that access token here's the pop-up as i mentioned it's going to have me sign in and because i've pre-consented as an admin i don't really need to ask the user for permission and now postman gives me this access token and we'll look at one of those in more detail later but for now let's just go down and find the my joint teams so these are the teams that i'm a member of or the logged in user is a member of and that's going to be sent in in the http header to the graph and indeed i'm able to get back a list of the applications so this is the simplest form of azure id sign in now also point out that azure ad v2 also has a postman collection if you want to go a little bit deeper on how any of these protocols work you can take a look there and you can actually run it yourself and see how it works now in a few minutes i'll show you something very similar using a single page application but before we go there i want to try to clear up some common areas of confusion that people have when they're learning about azure ad and microsoft 365. the first area of confusion is different things called azure id it's really a naming problem inside of microsoft there have historically been four different products that look a lot like azure id the first is azure access control services or azure acs not to be confused with azure communication services which is also sometimes called acs azure acs has been deprecated and we don't really need to talk about it that much it's a federation for service that allows people to log in with google facebook microsoft etc so if you see azure acs on an article or some documentation that's not the one you want probably more confusing is over on the right side of the chart azure adb to c azure adb to c is also a social federation protocol that allows you to build high scale applications that have people logging in with google facebook microsoft consumer accounts etc but it's a completely different directory service than azure ad so if you see b to c on some documentation skip over it it's not going to work with microsoft 365 it's not going to work in microsoft teams so if we eliminate that we still have two different endpoints for azure ad itself the v1 endpoint obviously is older that only works with azure ad where the new v2 endpoint is quote unquote unified in other words your application can work with both azure id and microsoft consumer accounts the v1 endpoint only supports static consent meaning that people will consent once to every permission that the app needs whereas v2 allows dynamic consent so that the app can ask for more permission as the user is using the application v1 you would program it with an older now deprecated library called adol v2 program that with the mcel library and really and they have a unified registration portal writing your own services is now easier so i should update the slide in v2 in general we're going to be using v2 for everything but again i want to point it out because v1 is still shows up in the registration portal and there's still a lot of samples and documents out there that refer to the v1 so in general you're going to want the v2 endpoint for anything that you do going forward i've already explained tenants and subscriptions so this is something that confuses a lot of people when they're getting started the difference really is that a tenant is that azure id domain and the m365 content inside whereas a subscription is a way of charging for services so a microsoft 365 subscription or an azure subscription those are used to charge a customer or partner for the use of microsoft 365 or azure so they are related but they're really different and specific every microsoft 365 subscription has exactly one tenant one azure ad domain associated with it they always map one to one whereas many azure subscriptions can trust the same azure ad domain so you could decide to have a bunch of different azure subscriptions perhaps with different administrators different billing what have you and connect them all to the same azure ad domain so this is just something to be aware of and also if somebody gives you an azure subscription and says here use this to build this m365 application you have to be aware that it might be pointing to a different azure ad domain and you might need to switch that now i'll put a link here to an article that explains how to make that change but i'll tell you that you could also in doing this break other things that are already inside of that azure subscription so you may not want to reuse an azure subscription if it requires you to change to a different azure ad domain and if it's in use for other purposes another area of confusion and the ui has gotten much better about this is that there are different names for the same thing that are commonly used in our documentation and in our apps and even in the user interface a tenant id and a directory id are the same thing they're the same good same globally unique identifier client ids are often referred to as app ids or application ids client secrets are sometimes referred to as app secrets or app keys it's basically a password used to authenticate the application's identity and there's also something that we'll get to later called an enterprise application which is also called a service principle and so these things are you know hopefully less confusing now that you know that they're that they're really the same the final concept that confuses people and this is super important to understand is the idea of different permission types basically there are two different types of permissions in azure id that can be given to apps the first is user delegated permission and this means that your app is going to act on behalf of a user then there's app permissions which means that the app is going to act on its own behalf the different oauth flows lead you to one or the other of these types of permissions so user delegated is what i used in my web browser my postman example and that's how i was able to see which teams i was a member of right because i had to be logged in your effective permissions under delegated permissions is the intersection of what the user can access and what the app can access for instance suppose that alice has access to teams one two and three and the app has files.read permission when the app is running under alice's login it's going to be able to read the files in teams one two and three makes sense it's just the intersection you can't write the files because the app only has read access and it can't access the files in team four in any way because alice doesn't have access the other option is app permissions this is typically used in background services and also to elevate permissions if your app needs to do something that the user doesn't have permission to do like write to an audit trail or something like that so in that case you would use app permissions and these can only be consented by admins there's no associated user and typically you're going to get access to everything in the tenant so if i had files dot read app permission that allows me to read every single file inside of that microsoft 365 tenant there are good reasons to do that but i will warn you that admins are going to probably scrutinize your request a little bit more if it uses app permissions there's also something actually it's out of preview now called resource specific consent that allows a team owner to consent just for that team and that's actually a little bit different than either of these and i'm not going to get into it in this in this discussion but just make you aware that it's available as i mentioned azure ad uses oauth 2.0 as its protocol notice that most of these give you user delegated permission the only one that gives you app permission is the client credentials flow so the one that you saw earlier in the postman demo was off code pkce flow that would typically be used for a browser to call a web service and some of these others are also going to be used in teams development i'll discourage you from using implicit flow you'll still see it in some of our documentation because it wasn't that long ago that that was the only option from a web browser in azure id but we now support auth code pkce that's preferred the problem with that one is that it passes the access token back to the application in the url of a redirect so that means that anyone who could maybe see that url or if it's getting cached somewhere that that might be able to be reused in a replay attack https is mostly going to protect you from that but that's why we now avoid the implicit flow and the other one is a simple username password which is sometimes called user credentials flow or resource owner password credentials because we have to have fancy names for everything really want to avoid this it doesn't support multi-factor authentication it doesn't support conditional access it trusts the application to actually handle the user's password which could be used again later in general you don't want to use this at all and it really is of limited use in certain devops scenarios so inside of teams we're primarily going to use these four flows the auth code pkce flow is going to be used in side of the commercial marketplace so if you are programming your landing page for a user who has just purchased your application in the marketplace this is actually considered sso to the commercial marketplace people so when commercial marketplace says you need sso to sell in the team store they mean you must support the off code pkce flow to log the user in to the landing page after they've made a purchase that's really different from what teams means when the teams folks talk about teams sso if you use that same protocol from a microsoft teams app you can do it and i'll show you what that's like the user is going to see a pop-up window and that's not considered sso from a team's perspective you'll also see off code flow without pkce it's a subtle difference the bot framework if you're logging into a bot is going to use the off code flow on behalf of flow is used in teams sso and we have rabia williams and i recorded a whole video on that so i'm going to talk about it here but we'll go into the code and the details in that other video and then we have the client credentials flow so these are the ones that are going to be used the most frequently inside of a teams application i want to take a moment here to point out another protocol that you may encounter called open id connect openid connect is based on oauth 2.0 but where oauth 2.0 is about authorizing applications to do things so you get an access token which allows you to call a backend service of some kind web service open id connect is about authentication normally with teams apps that teams app is going to have to call the microsoft graph or some other back-end api even your own apps api that is secured with azure id and it's going to use oauth 2.0 that's why i'm mainly focusing on that in this video but if you simply want to authenticate the user for your app's own purposes perhaps to grant permission to certain assets inside of your app you can use open id connect which is the same pretty much as oauth 2.0 the difference being you're going to not request specific permission scopes and instead of an access token you're going to get back something called an id token that establishes the user's identity without granting permissions so as a teams developer as someone building a landing page for the commercial marketplace you're probably going to be using oauth 2.0 to not only establish the identity of the user but to also make calls into a back-end api on their behalf now let's use azure active directory in a single page application okay so let's take a look at this application the first thing it wants me to do is to sign in and when i do you'll see a pop-up flash by and because i had already previously logged in to azure active directory it recognized that i was already logged in and it continued from there without me actually being prompted this would be considered single sign-on for the purposes of the commercial marketplace landing page that you need to get into the team store it works and you can see that what it's doing here is it's um showing me a list of my files inside of the my onedrive and i can come in here and download one of the files and take a look at it it's my favorite cat and i can even upload a file if i want to so let me do that and show how that works and that all works fine so let's go back and look at the um at the registration for this app so this is a different app id uh same tenant id under authentication instead of web i said single page app with my app's url is localhost colon 8080 which is correct and it says here my redirect uri is eligible for auth code with pkce so that's what i'm using in the code i don't have a client secret don't really need one for this you can't actually in fact in postman i didn't need it either i just had it there so i could try other things in this case of a single page app you can't really trust a secret in the web browser anyway so you really just don't even need it here and then the api permissions all i have is user.read which is very limited just allows me to sign in and read the user profile so how is it that i was able to access my files list and upload and download files well it turns out that there's another part to this puzzle so this is where the app is registered but the consent of permissions is actually stored under enterprise applications so i could get it i could navigate there here but i'll just click into this and it'll bring me there directly and now you can see that this is the same application and as a user i went and gave it a bunch of different access rights so i had already consented to having it view my profile read user files and have access to my files so that i could do the upload and download part so what's with that let's take a look at the code so here is the graph code this is the code that calls the microsoft graph and the first thing i'm doing is creating an auth provider and an auth provider this is just part of the sdk you don't need any sdks you could do all of this with rest calls but in this case i'm using the graph sdk expects a thing called an auth provider which has one function in it get access token and that is going to call a function over here in off.js which gets the access token so there's a few things going on here i have this configuration where i've put my client id i also have down here the get token function which is calling this sdk another sdk called microsoft authentication library 2.0 or msl 2.0 and it's going to take care of a lot of the details for me one thing though that is specific to this app is this ensure scope function so this is going to allow me to dynamically add more permissions as i'm running and that's called dynamic consent so ensure scope if you look at the code all it's really doing is adding another scope which is just a string to this array of scopes which is ultimately going to be used by msl to give me the permission so then if i go back to my graph code again when i get the user account so that i can say hello to the user at the top of the screen i'm asking for user.read when i get the list of files and here's the call for that i'm going to ask for files.read when i want to download the file i don't need to do anything different but when i go to upload a file i need files.read write okay so what if i was to delete this enterprise app make sure you're in enterprise apps when you do this this is also called a service principle and i find service principle to be a lot more easier to understand if this was a multi-tenant app it would be registered in one tenant like the isvs tenant and then the consents would be in all of my customers tenants so every customer who granted consent to the app would have an entry under their enterprise applications for another service principle so it's like a one-to-many kind of relationship a little trick for testing your consent logic is to just go in here and delete the enterprise app make sure that you are indeed deleting the enterprise app and not the app registration when you do that and now if i come back and refresh the page you'll see that i'm going to get prompted first for my basic profile information and if i accept that i'm going to get prompted again to sign in and read my profile we're sort of doing it one little step at a time now it knows my name but it hasn't showed the list of files yet it's waiting for me to agree to read my files so i'll do that and then if i want to upload a file i'm going to get hit with yet another consent to have full access to my file so it just keeps adding more and more consents into there notice that the login button every time i refresh i have this login button again what that's about is it's really about the fact that you need to initiate any kind of a pop-up in a web browser using a user action right so that's been around for a while now it's a standard thing it's not a microsoft thing web browsers just to avoid filling people's screens with nefarious pop-ups you have to click a button or do some user interaction in order for that to work but let me just try here i've actually gone and turned off pop-ups in this particular app so what happens if i come in here and i just add a call to display the ui not by pushing the button right now it should come right back and notice that i saw the pop-up momentarily but i didn't actually have to click the button okay so now let's look at that same exact login method inside of a teams app and it does work it's just the user is going to see a pop-up so i'm going to use teams off pop-up with azure active directory and msl 2.0 as the libraries that i use inside of the pop-up the advantage of this method is that it works with any oauth provider so obviously i'm using azure id here but you could put something else inside of that pop-up that logs into whatever login service you want and there's no server-side code so this is a completely static website the limitation is that the user has to sign in to the tab even though they're already logged into teams every time they visit the tab or every time that they switch to a new client so let's see what that looks like here i am inside of teams this little app shows some email information so it's another very bare bones app and there we go so you saw the pop-up i didn't have to log in so what happened there was that azure ad when it was running in the pop-up saw its own cookie that it left from that was left from the last time i logged in and it said okay i know who that is and it issued the access token and sent it back via the pop-up and it worked but i still saw the pop-up and the unfortunate part is that if i leave the app and i go back again i'm going to have to log in again i'm going to have to see that button and i'm going to have to push it and see the pop-up go by again so the reason for that is that teams is not a web browser it's just presenting an iframe here and it's not going to keep the browser session alive or the http connection alive when i leave the tab so i'm starting over again every single time if i go over to the mobile client it looks slightly different but i still see the pop-up right and so uh this is sort of the reality of this method of log on so let's take a look at the code so here i am this is a react app so i'll try to explain the react bits away quickly because i want to really focus on getting the access token to call the graph right this is the tab and it's going to call a service my teams off service which is part of my project get access token with these two permission scopes here user.read and mail.read which it needed to actually get my mail if we look inside of teams off service what it's going to do is it's going to call the team's javascript sdk there's a call in the authentication namespace called authenticate which ironically doesn't actually authenticate you all it does is show a pop-up and then allow a value to be passed back to this application from the pop-up when it closes so in this case my pop-up code is under slash pound teams off pop-up right and then if it succeeds i'll grab that access token and and use it in the graph call here's teams off pop-up and it's going to call its own another little service i've written here which is ultimately going to call m cell here's that m cell config and here's where it's going to actually go in and um and get that access token from msl just just like before it's just the code is kind of structured differently so yes this works yes this is the shortest path to happiness for a application that is not using azure id you could get your app into the team store using this technique the mandatory sso is on the commercial marketplace side when somebody just bought your app and in that case it's just going to use normal web-based flow it's not going to do any of this teams pop-up stuff to do it so it's much more like the first example if i'm in teams however and i use this technique and particularly if i don't use azure active directory there are some usability issues that come up i mean okay you can publish that app and you can put people on the app they're gonna always see the pop-up first of all and second of all and possibly more importantly you're going to create a challenge for anyone who uses that app particularly for any owner of a team of people who are using the app suppose i adopt an app that uses some other directory system and i want to bring it into teams right so my users are going to be able to access that app from inside of teams so the first thing i have to do is go to every user in the team and ask them to sign up under whatever directory service that app uses and then tell me what's your login in that other directory service then i have to go give all those users permission to see whatever it is inside of the app that using their alternative user ids and if somebody new comes into the group i need to go through that again and say hey go go to servicex get a login tell me what it is and i'll give you permission otherwise they're going to click the tab and see a big access denied from your app right it actually gets worse though what if somebody leaves the team right is that admin going to remember to go find that matching user account inside of the other directory and remove them inside of your app or long after they've maybe left the company are they still going to be able to use that other id to log into the app and get at potentially confidential data that they shouldn't really have this all becomes administrative burden and those administrators are often going to be part of the decision factor of what app to use so i will tell you in no uncertain terms that the administrators and the users are both going to appreciate it if you integrate with azure ad and don't require them to maintain two sets of user accounts for you one for using your app and one for using the rest of m365 okay so now let's look at what teams engineering calls sso this is teams tab sso the user never has to sign in they don't see a pop-up nothing the user identities of course are the same as they would be in teams itself so there's no coordination that the administrator needs to do between the two and you don't need to write a login pop-up page at all and the user is never going to see one the limitation is well it does require you to write some server side code to do a token exchange as well as the client side code that is your user interface it only works with one domain per app so that means your app needs to be hosted in a single dns domain and it does not currently work if the dns domain is azurewebsites.net so those are kind of the limitations but this is so much better for the user let's take a look i have to do see i'm done it's that easy and now i'm showing all the tokens here but let me just show that again i can leave it and go back and it immediately comes up and if we switch to the mobile client it's going to be equally streamlined right just comes right up and we're done very very simple now robbie williams and i did a whole video on how to build this so um i'm not going to go into a lot of detail here before we look at the code though let's take a look at the app registration it's similar to the one we saw before except we also exposed an api and so that involved setting up the scope and i'll refer you to the other video on the detail on how to set this up notice that this uri now needs to show up inside of the app manifest for the app right and here it is that is what allows teams to give you an initial access token so if we take a look at that there are basically three steps this is the client side first we're going to get an auth token from microsoft teams so we're just going to call this function called get off token using the teams javascript sdk and magically through the use of that exposed api which is noted in the manifest it will give us an access token however this token has very very little permission it has to really be exchanged for a better token a more privileged token on the server side so the next step is we're going to send this off to our very own server side code to exchange it for a more privileged token and when i get that back i'm going to use that more privilege token to call the microsoft graph here you can see that that it gets passed in to as data in the authorization header bearer space and then the token that's just the way that all these tokens get passed in if we take a quick look at the server side code here's that slash off slash token call and what it's going to do is it's going to call azure ad using what's called an on behalf of flow to exchange our weak token for a stronger token that has permission that we want in the microsoft graph with all those scopes in it so that's again i'll refer you to the video for more details but that's what's involved in building one of these you really have to include a server side some server side code as well as coding these things on the client and there's also some logic if you want the user to be able to consent in the middle of all this rather than requiring the admin to pre-consent that's also explained in the other video the third option that's specifically for tabs is to use the sharepoint framework to write your tab sharepoint is a part of microsoft 365 that is included inside of teams so any team that you have is going to have a sharepoint site underneath of it now the main use for that sharepoint site is to store the files that are inside of that team it's also the same as onedrive so onedrive is really a different user interface on sharepoint so individual user files are stored there but sharepoint also has web pages and those web pages have things called web parts so if you write a web part which is sort of a it's less than a single page app because it shares the page with other things it's a partial page app if you will if you write one of those and set it up correctly you can use that as a teams application the advantage of that is that you don't have to host the solution at all you can host it in sharepoint which is part of your customers m365 subscription so you don't have to pay to host it this is going to work great for some applications and not so much for others there's no multi-tenant story here so for a typical isv it's not going to make sense but i still wanted to show it to you because it's the same as the sso case from a user experience point of view because guess what under the covers sharepoint is using that sso mechanism so you don't need a login page it works with any azure id secured service including the microsoft graph and the downsides are that the admin always has to consent and that consent is often going to be shared with other web parts in the tenant so um so let me show what that looks like that was it it's a really quick demo right if i leave and go and come back um you'll see that it's going to just come up immediately so that's great and even if i go over to my mobile client you'll see the same result it's just going to immediately come up for me and click it and okay just a sec there we go beautiful so let's take a look at the code for that this is it there's not a lot the sharepoint framework which is how you write a sharepoint web part it's written in this framework called a the sharepoint framework it has a graph client factory that will hand you a microsoft graph client it also has an object you can use to call arbitrary other azure id services maybe some that you've written yourself and you can call that and it takes care of the authorization for you automatically so in this case all i'm doing is calling the graph version of that api inside my sharepoint framework web part and i'm getting back the data and i'm done the only other thing i need to do is inside of my sharepoint package i need to declare that i need these permissions so microsoft graph mail.read right and then my admin needs to go in and consent to that permission and notice that all these permissions because these are web parts that could share the page with other web parts they are actually organization-wide so that's kind of a limitation right now is that um we have sharepoint has something called isolated web parts that will run the web part in an iframe with its own identity so that it doesn't have to share permissions with all the other web parts but currently that doesn't work in microsoft teams therefore you're going to have to share the permissions with all of the third-party web parts in the tenant now of course teams apps can have more than just tabs so the methods that i've showed you so far they work in any browser-based or iframe based teams app feature so they would work for a tab a configuration page or a task module where a task module is really a pop-up dialog box all this is explained in another video that i did with rabia williams which i'll point you to here in this case though i want to show authentication from a bot quickly and there's two ways to do that one is with an oauth login prompt dialog which is what i'll show now and another is to use teams bot sso which will be the subject of a future video but i'll point you to the documentation so the need for sso is not quite as severe in the case of a bot because the login prompt is only shown every few months there the bot framework will maintain a refresh token for us it will hide that auth dialog until the refresh token expires so let's see what that looks like for a user here i am in my bot and i'm just going to say log in and it's going to come in and say please log in okay so now i have to click the button and yeah i have to log in but i only have to do this when the refresh token expires so now i can show my email what have you and the nice thing is that if i leave it and come back later even if i come back on a different client in this case the refresh token is in the bot service so i don't i'm not going to get prompted again for months right so it's not nearly as important for a bot so the way this works is that in my bot registration not in azure id now i'm in azure services bot services and this is where i've registered my bot i need to come in here to the configuration and add an oauth connection now this oauth connection is for azure id and if i click it you can see here's the client id and secret and the other information that i would have used in a tab but i'll also point out that there are dozens of other services that are supported here in fact there's a generic oauth that you can use if one if your service is not here but if it handles oauth so this is how you would have your bot authenticate the user if you were not in azure id or if you just want to keep it simple and use azure id then create a second application here's the client id once again and add that as an azure ed oauth setting to your bot then inside the code and this is the main dialog there is going to be a child dialog which is an oauth prompt dialogue and here you can see the text please sign in that you saw come up on the screen and then this is i'm not going to get into the way that the bot works but it's basically going to go through all these different steps and the first step is going to show that oauth prompt dialog and then when the user finishes with that dialog it's going to have the access token that gets sent back right and so it's fairly simple and i'm going to point you to a to another video or actually series of videos that i made with another colleague aichabash where we go into some detail on this while these are the most common scenarios microsoft teams also allows its applications to authenticate in messaging extensions and other scenarios and that's all detailed here in the documentation and hoping to make future videos to cover some of those other scenarios so i want to close with a troubleshooting checklist to help you debug the situation if you have any problem with this the first thing that i always like to do is to start in postman if it works in postman and not in your code then you probably have a problem in your code if it doesn't work in postman check azure id and all the different values and make sure that that's working before you start looking at your code the next tip really is to inspect the access token itself and you can do that on a website called jwt dot ms so here i am back in postman i'm going to take that access token that i got earlier and i'm going to paste it into jwt.ms and what you'll see is that first of all these tokens aren't encrypted at all which is why you have to use https in order to get any kind of security here and then you'll see that this it's really just base64 encoded you'll see here are all these different claims that are part of the decoded token and you know this is a really pretty nice little tool because it'll actually go and explain everything for you if you click on the claims button in any case the audience or aud token that is the destination for whom this token is intended sometimes you'll see a url like this other times you'll see a globally unique id or good that represents that same application either way it needs to be that same application that you're granting authority to access in this case the microsoft graph and if i go down here a little bit you'll see some other useful things for me to check first of all make sure that the app id matches the app id that you expect make sure that the username is the one that you expect you can also look at the oid that is the object id for my user so if i was to go into azure id and look up my account it would be this cda79 guide another thing to look at is the scope so make sure that you've got the scopes that you expect and the tenant id make sure that that's right and then you can also check the signature and you can see here that it's saying that it is issued by azure id and the signature is checking out here it's green so just so that we know that the signature part was successful so that can just kind of help you maybe troubleshoot a little bit of what's going on now check the app id if your flow involves an app secret check that make sure it didn't expire app secrets or client secrets are a lot like digital certificates they expire after a while sometimes if you make a change to an app registration it might invalidate the app secret so check that maybe make a new app secret you can have more than one so you can kind of roll them over in your application make sure the permissions are correct are you using the right kind of permission app permissions for client credentials flow or delegated permissions for any other kind of a flow were there any admin consents that were required so if i go back to an azure id registration the permissions that are here you can see these have all been granted and they're checked off you can also see this column admin consent required so there are some permissions let's go find one that are so sensitive that you need the you need the admin to consent users just aren't allowed to consent to some of these so for instance if i go to sites.fullcontrol.all this gives access to all the sharepoint sites in the tenant possibly limited by what the user has access to but it's still full control this requires an admin to consent no matter what and so that's something to be aware of when you're building your application that you take those into account another thing to note by the way is that these permissions that are in the registration these become the default permissions for the app so if you if you request an access token from azure id with dot default as the scopes you'll get these permissions if you request specific named scopes and you're in the v2 endpoint it will actually go in and try to get more permissions potentially than what's listed here anyway you're going to want to make sure that all of those consents have been granted is the off url that you're referencing the right one for your resource and if you're using the implicit flow is that enabled in your app registration so let me show you where those are the off urls are actually out here at the in the overview and you can click endpoint here are all the different auth urls typically you're going to use this one if you're in the v2 endpoint and you're trying to get an access token with authorization you would use this first one here the implicit flow setting is down here under authentication and it's here so these ones are checked off as i mentioned we don't recommend using this anymore but if you need it for some reason it's here you just have to be aware that these would need to be checked off so just some troubleshooting tips because i know this can a lot of times you're not going to get a ton of information you might just get an access denied message they're trying to not give the hackers too many clues as to what's going on perhaps so having these troubleshooting steps handy can be a time saver and i will say that i myself go back to this checklist when i get stuck and just kind of use it as did i check this did i check this did i check this and usually i can find my my issue that way so thanks very much for watching this video i hope it was helpful to you in understanding the single sign-on system that's used by microsoft teams developers getting the concepts please if you like the video please give us a like and if you want to see more videos like this please subscribe to the channel and feel free to leave a comment with any special requests that you might have thanks very much and i'll see you in the next video

Channel: Microsoft 365 Developer

Views: 16,935

Keywords: sso, single sign on, single sign on sso, single sign on authentication, sso benefits, how does single sign on work, security, what is sso, how to build sso, what is single sign on, teams apps, aws, aws sso, azure, azure ad, azure sso, teams sso, sharepoint framework, oauth, oauth 2.0, oauth2, oauth 2.0 tutorial, oauth2 explained, multi tenant applications, azure ad app, azure ad app registration, microservices, saas application, multitenancy, cloud computing

Id: SaBbfVgqZHc

Length: 60min 28sec (3628 seconds)

Published: Wed Dec 01 2021