Build Android native apps with the Microsoft Graph Android SDK - June 2019

Key Takeaways

welcome to this screencast on developing with the Microsoft graph let me first talk a little bit about what this screencast is and what you can expect from it before we start diving into the content this screencast is a going to accompany a hands-on lab and a training module that you can take advantage of that goes along with everything you're gonna find in this screencast specifically you're gonna find in this screencast is really going to be a example of someone presenting the content from the training module as a way for you to learn how you could train use this module and delivering it to a different user group or to at a conference however you can also use it as self-paced learning now the way that this module is set up is that it's broken up into a series of a couple different sections we'll go through each one of them in just a few minutes each one of these sections is going to finish with a demonstration now the demonstration we don't walk through the entire step of creating the application or walking through the steps of writing all the code instead we look at the final solution that has already been built and kind of picked through the code and pick through the important parts that you should take advantage of or you need to take note of and we'll see it working as well if you want to go through and you want to build the application you want to see how it's being built then what we will recommend that you do is go check out the hands-on lab that accompanies this module because the hands-on lab each of the exercises maps to one of the demos inside of this screencast that you're going to see so if you want to see how to build it you want to walk through the steps you can walk through the hands-on lab exercise that accompanies this module and get to the exact same place that we're showing you here in the screencast instead we're not going to show in the screencast all the individual steps of creating the application and part of that is because things change on a rapid cadence and the lab is gonna have the most updated steps and dependencies and stuff that you're gonna need the screencast is more or less showing you how the thing works or how the final solution works so that's how you can learn more about taking advantage of this content and how we've all have we've structured this let's go ahead and dive into the actual module itself in this module we're going to look at how to build Android native apps with the Microsoft graph Java SDK in this first section we're going to do an introduction to the Microsoft graph API a little bit of getting started content and then we're going to talk about Android and how to develop for Android applications and then we're going to talk about building a Android application for Azure ad in Microsoft graph this module has a couple different sections associated with it the first section is more introductory the second section is going to be about the authentication piece and more depth and then the third piece is going to be more about integrating the Microsoft graph in an Android application office 365 developer vision focuses on the users experience and their data and as a developer you can bring your application into the user experience with over 1.2 billion users of office worldwide this is a huge opportunity to provide a window into your application as well as being able to connect into their data and add intelligence to your application there are currently over 850 million events created each month and a total of over 400 petabytes of data stored in the service that can add value for your users the Microsoft graph is the Gateway to your data in the Microsoft cloud as you see there from the bottom of the list we've got a lot of different services and data types that we can actually take advantage of from office 365 and Microsoft and it's all considered part of the Microsoft 365 platform we can work with mail and calendar contacts tasks we can work with content inside of SharePoint sites and lists files inside of onedrive things inside of Microsoft teams think users inside of Azure Active Directory there's so many different things that we can take advantage of the nice thing here that each one of these different services usually has its own API where we can talk to these different services to get the data out it can be challenging to go get the data from all these individual services as they each have their own endpoints they may have their own permissions and that also means that with their different access control that we have in talking to these different services using an OAuth style authentication via Azure Active Directory that means that each one of these different endpoints is gonna have to require their own access token one of the nice things about the service called the Microsoft graph is that the Microsoft graph is gonna serve as a proxy endpoint to all of these other different services it's gonna in cover encompass things such as office 365 Windows 10 and enterprise mobility and security and it brings all of these different services under one top-level service called graph Microsoft comm the advantage to using the Microsoft graph is that it's going to allow you to just have a single point resource which means you're only going to need a single access token to be able to talk to all these different services they still have their own individual permissions or as we refer to them as scopes so that everything is still secured in a very individual way but this makes it easier for developers to build applications all office 365 cloud services including SharePoint Online and the Microsoft graph leverage Azure ad for authentication and authorization this means there's a single authentication flow that you can use inside of your office 365 applications as well as those created to leverage the Microsoft graph this single authentication flow means that we're just gonna have one way that we have to log in to all these different services and obtain an access token either using a web application or a native application it also has a whole consent model and we'll look at that a little bit more in the future section everything is also very secure everything is based off the OAuth 2 protocol which means that the application that you build is never going to collect user credentials we're always going to redirect them over to Azure ad have the users log in and then azure ad will provide my application that I can build as a developer with a special code that the application can then use to exchange for an access token to be able to call these different endpoints and services such as the Microsoft graph on behalf of these different users we also have some very fine-grained permissions otherwise known as scopes so that users can only grant the application specific permissions of different things that they want to allow the application to do and then we can also have some special considerations that we have to into account if we're building native applications so there's some things like when you build a web application you have a client ID in secret you can protect the secret because there's server-side code that the web application doesn't have to expose to the end-users but as we'll talk about a little bit later the native applications do have a little bit of a challenge where once the code has been distributed we can't include both the client ID and the secret because if we distribute the secret well technically it's no longer a secret anymore we'll see how this works in a native application in just a little bit now office 365 has a single authentication flow for office 365 and the Microsoft graph users are going to sign in using a technology called Open ID Connect which is an open standard and what that does is that once people have logged in there's this nice little envelope wrapper that will include details about the individual who's just logged in as your ad is going to be used for all of the authentication the Microsoft graph is built on top of the authentication model of azure ad office 365 is also built on top of the authentication model of Azure ad so both of these services trust Azure ad by having this single level of trust they are single service that they both trust then we can leverage the authentication to Britain to take advantage of both of these different services with the same authentication flow this authentication flow is also going to support multi-factor authentication also referred to as MFA and federated user sign ons and it's going to support all different kinds of applications from device applications such as those on a mobile device websites single page applications that live 100% my client or as a headless application with no user involvement also referred to as a daemon or as a service based application you'll be able to pin applications to your office 365 app launcher from the my apps page which is like that little menu that you have in the top left corner within Office 365 now let me talk a little bit about working with Android and Android development the Microsoft graph provides a Java SDK that you're going to use with Android based development developers can leverage either the Azure Active Directory authentication library which is used for the azure ad v1 endpoint or the Microsoft authentication library which is referred to as the MSA L which is good with the azure ad v2 endpoint now we're going to see the differences of these in the next section when we talk more about authentication and security and azure ad but for now we're just gonna leave it at that just from the high level you can use either a tout or MSA L inside of your application the Microsoft graph does recommend though that you use the v2 endpoint which means you're going to be using the Microsoft authentication library but again we'll get to that in a little bit so what does the development story look like when you're building Android apps well there's always lots of different ways you can do things but the way that we're gonna focus on it inside of this screencast and in this module is probably the most standard way of doing it developers are gonna use something called Android studio which is a free IDE implementation on top of the IntelliJ platform that's provided by the Android development team um all application registration is going to be done using one of the using the azure ad admin portal so you're going to create your application that's the code and then you're gonna register a logical application with Azure ad and that's how your application is gonna be able to identify itself with Azure ad how users are gonna be able to grant your application permissions to act on their behalf and to talk to the Microsoft graph on their behalf you're also gonna be using a tool called Gradle and what Gradle is is it's a package management in a build tool that is commonly used in Android development if you're familiar with dotnet development this is very similar to MS build and new get in a dotnet project where we use ms build for a lot of our build tasks and we use nougat for package acquisition and management now you need to think a little bit when you're building a native application when you should consider doing native Android development you have a couple different options on how to do this well native a native mobile development is really going to come into play when you have device specific capabilities you want to take advantage of and these are things that are very specific to the mobile device or the tablet that you're working on that you need native SDKs to do that work or if you're doing some complex or advanced user experiences or visualizations and you don't want to go with a more abstract kind of model you could always look to use a cross-platform option such as something like xamarin or Cordova they have their own advantages and disadvantages but that is an abstraction layer that is not going to be native to the device that you're working on and so you do lose a little bit of low level control but you do gain from the developer productivity where you want you can just still use the exact same languages that you're used to working with like in the case of xamarin you're still working with net you're still working with common controls that you're used to working with but they are cross-platform meaning that they're gonna work both on a native experience inside say an android device or an iOS device or Windows Device and because they're common across all of them some things kind of have to be dumbed down a little bit which means you don't get the low level access to the actual device controls themselves now let's look a little bit about creating an Android native java application for Android and let's see what's involved with this so what you're gonna do is you're gonna first create the application you're gonna write the code using Android studio to go build the application now the way I would recommend you do this is to implement the user experience and really have like a functioning prototype that's just to click through it doesn't have any logic in it it doesn't do any authentication or anything like that but it just focuses on giving you an experience of I've got the application up and running then the next step you're gonna want to do is handle authentication so I would extend the app to support authentication and granting acquiring the token and access token from Azure ad and you use that to talk to the Microsoft graph and then that's the last step is to integrate the Microsoft graph Java SDK into your application to get information back out of the of the application so what does that story look like well here's just a little screenshots of kind of what you would see first you're gonna create the application using Android studio that's a native app that's gonna be running on your desktop then you're gonna implement the user experience and so here you can see all I've done has done a really simple user experience that has a sign-in button and then you're going to test the application prior to implementing your authentication and the azure ad and the MS al library and integrating the Microsoft graph and so here once I click sign-on it assumed that I was signed on so it showed a button about getting events and it even shows a little toast notification at the bottom that says hello your you know welcome to signing in now let's see how to go about doing this now what we've got here is a demo that we're going to look at which is the built solution of a sample Android application this Android application doesn't do anything special other than it just provides a little click through of what the application would look like if it was up and running so I don't have any asher ad authentication setup in here there's no authentication piece to it there is also no calls that are gonna be calling the Microsoft graph we've just kept the bare bare-bones minimum stuff in here just to make this application work walk through the code and kind of see what this experience looks like just so you can get familiar with this again just like all the other demos that we have in this screencast and other graph related development screencasts that we have in other DS training modules if you want to see the step by step process and walk through this yourself go check out the hands-on lab exercises that accompanies this screencast that's in the module that accompanies the screencast if you want to go through and do that yourself okay as I said previously that in this demo we're going to look at a pre-built application that I've already gone through and followed all the steps that we have in our hands on to create this application as an Android based application that is really just a click through wireframe so let me show you some of the stuff that I did I went through and I created a brand new project and one of the first things that we did is I came over here to the build Gradle section and I added in this section that you see right here which says Android support design 28 and this is allowing me to do certain kind of navigation elements for my application allows me to do what's called like a drawer or navigation drawer layouts making them available to my application so this is one thing that I ended up doing another thing that we end up doing here is this packaging options thing this is just another kind of a setup thing that we wanted to end up implementing here so one of the things if I come over here and look at the res folder in the drawable section what I've got is a couple different things that I've set up so you see I have this home vector that I have here for one menu item I have a calendar option I have a sign-in option and I have a sign out option as well that I've created for each one of these different elements and then one of the other things that we did is I created and then I went over here and I created this new menu folder and I have this drawer menu and so what this is this is kind of what my navigation is gonna look like and it's using those different elements that I just created from the drawable section so there's home there's calendar sign-in and sign-out and so that's the little drawer menu that I had defined that you see right here I then went into the Styles folder that you'll find over here under value and styles and I defined a couple different colors that I wanted to end up using here but specifically I added in these things here so the window action bar I have that set to false I have no title on the window and then I also have on the status bar color I also define this as transparent now back over here to my layout one of the things did is I created a nav header so this is my nav header and this is what the application looks like so I have this header up here at the top when I build my application and I've defined it all using this XML so I have like an it's been set up textview another textview they just have some text right here for an email address and a test user so that's all stuff that's gonna get replaced a little bit later now the main activity here that you see this is my main application and so here what you've done what you see here that I've got is there's my navigation menu that was defined using the nav header so that's where this whole menu is set up over here where I've got my drawer set up and I've got the main navigation set up and then I've also got everything else set up behind the scenes here with this relative layout using a tool bar having a progress bar and a frame layout that's all like the main structure of how my application is gonna be set up then I also went add some localization stuff here where I have some other references in my application so in the strings I set some things to this like there's the graph tutorials the name one application the open and the close for the drawer I put some I want to do that we went through and set those different strings that you see here now the last thing I need to do or the main thing I had to do here is I had to set up my application if I look at the main activity I do then go build the application itself that was gonna do all the logic here so what does this do so I've got a lot of import statements that you see up here at the very top and then I've got my main activity this is like my the main thing that's gonna run with my application runs so when the application is actually being created you can see here I'm saying the content view equal to the resource layout called activity main we saw what that was defined a little bit earlier I set the toolbar and I set up the little menu piece that you see there on the top right hand corner and then I'm also setting the current users name and then I'm also going to set the navigation element and the home fragment in the home from these different fragments are the different ways you're able to see how things are are defined like what they the way that the UI is gonna be kind of laid out here so that's when things get created and then here's what happens when I call the home fragment I'm passing in a username that you see right here defining an instance of it and then I'm simply going to be setting it to the navigation element where I want this to be displayed and then there's a couple other elements here I've got the home the open calendar fragment the sign-in and sign-out buttons which really don't do anything today and then I have this other section here on navigation items selected so this is just watching for the different elements that are selected in my navigation and doing different things like opening different fragments that we're going to be defined so signing in signing out or opening the calendar fragment or opening up the home fragment if I go back home right a couple of things have been set up here like the progress bar hiding and showing it and then the setting of the state of what's going on with this so now one thing I want you noticed though is I've gone ahead and I've set up for just my demo purpose here is I've set up a hard-coded thing to where the person that's signing in is Megan Brown so when I run the application that it's going to show that I'm logged in as Megan Brown but remember I'm not doing I don't have any authentication stuff that's been defined just yet then I'm going to define my different fragments so I come over here and I create a fragment over here is my fragment home to go to the layout fragment home so here's the home fragment looks like so I've just got welcome please sign in so there's my text view and another text view listed right here and then I have another fragment for my calendar so this is where I'm going to list out all the different items and right here there's really nothing to show we're gonna deal with this in a later in a later module now if I come over here to my my home fragment code that you see listed here now what am I doing with this this home fragment here what this is this is the code that's gonna run the kulluk the code behind for the actual UI that I just defined so what happens when it's create when a new instance is created when it's on create fires when it's on view fires or on creating the view fires all this stuff is pretty static right now it's not really doing anything all that special other than it's taking in the username when the thing is actually created and I'm setting the username to a specific property on the the application as far as the calendar fragment goes to kind of the same thing it's just some bare bones here that we see that I have all set up with us okay so let's test our application and see if everything works so I'm going to come over here and just click the play button it's gonna fire up an emulator and here's our emulator right here now I might have to try and move the screen around a bit to make sure we can see everything so here you can see welcome to sign-in so there's our application come over here and click on this you can see it please sign in so I'll click on sign in and I can see I'm already signed in as Megan Bowen and we can see how the sign out button is kicked in and I see Megan bonus information so we can see the basics of this application up and running it's not you know it's not a very full fledged application just yet but that's because we need to go through and start adding all of the extra code for doing authentication with Azure ad and also setting up everything that we need for getting our application to work with the Microsoft graph so we're gonna see that in future demos but in this demo I just wanted you to see a little tour of the project that we've built and to see it up and running in this second section of this module we're going to focus on the authentication piece and how we can deal with authentication inside of a native application specifically a native Android application we're gonna look at the authentication overview talk a little bit about azure ad the application registration portal or the azure ad admin portal and then how we can implement the Microsoft authentication library in Android based applications before we do that let's talk a little bit about azure ad o auth in Microsoft 365 again as we talked about in the previous section both office 365 and the Microsoft graph both leverage Azure ad for their authentication model what's nice about this is that once a user is logged in they don't have to log in twice they're logged in once they're gonna be able to use the Microsoft graph to talk to all of their office 365 application this provides us a single authentication flow that is available on all office 365 services and a lot of other Microsoft 365 services as well native applications can levers using this authentication model which is what we're doing in this module but we can also build websites services Damons etc there are two different types of consents that we're going to have to also implement as well and what the way this the way this works is that in the different consent we'll talk more about the details about what static and dynamic consent is and a little bit but you have also have two other types of consent which is in user consent and admin consent end-user consent is me as a user granting an application access to my calendar to act on my behalf so that is only me working with this application and granting it access to to use my calendar or the data in my calendar that's end-user consent admin consent is something that's much more far-reaching and should be used sparingly actually I've been consented for our for certain permissions where an organisation wants to give an application access to all users calendar or all users contacts or all files stuff like that are all groups within the tenant that's something that the global tenant administrator is gonna have to do you won't be able to do that as an individual user as radio auth is also a very secure protocol and I talked about this in the last section but the big thing here to take the take note of is that the OAuth 2 protocol does not allow the application or ism it doesn't encourage the application to collect user credentials to be able to log in to some other service like the Microsoft graph or Azure ad instead what we're going to do and you'll see this in the demo is that instead we are going to have code up our application to send the user somewhere else to go log in which is Azure ad they're going to do that by popping up a browser on the device and then it's going to give control back to Azure ad is gonna give control back to the application and provide it with a code that was signed by Azure ad the application can then use that code to go back to Azure ID and say this code is something that you provided the user and I need to get an access token on behalf of this user and that code contains all the information that Azure ad needs to provide that token this process also supports very fine-grained access scopes we refer to access scopes also as permissions it also supports different types of authentication so such as multi factor auth and federated user sign-ins and these tokens are only going to be valid for a very limited amount of time but for user consent we will also allow us to have refresh tokens where we can ask our application can ask without user involvement for an updated token that they could use now we do have some special considerations when it comes to native applications on a mobile device these things are inherently multi-tenant and we also have the challenge of dealing with an app secret so in that process I talked about a minute ago we're going to look at it more depth on the next slide where the application receives a code and then goes back to Azure ad and says hey here's a code I need an access token when it does that the application has to I'm going to put it in air quotes login to Azure ad and the way we do that on like say a web-based application or on a service is that we the application has his own credentials a client ID and a client secret think of it like a username and password but just for the app well that we can't do that same process on a native app because we're going to be building some code building our application and then distributing that code to many many users mobile devices and once that codes been distributed well if that code has a secret in it then we've kind of compromised ourselves a little bit and so with a native app it works a little bit different a native app we don't use an app secret instead we only provide in a client ID and then we have a special redirection URL that will be used for the by Azure ad that will hand back to the client application so that it knows that the authentication model is a little more secure and it's a little more tight it's just not as it doesn't use the client ID and secret that a web application can do because it can protect that that model now let's look at the flow here and you get a better understanding of how this whole thing works so we've got four different pieces here that I want you to take note of here so in the bottom left corner that's the user we're gonna I'm just gonna say that's me and in the top left corner you've got something called the OAuth client that's our native application that we're going to build on the mobile device in the top right corner you've got the resource server that's where the API is or in our case that's where the Microsoft graph is and then finally you've got the authorization server and again in this scenario that's as your ad so everything starts in the bottom left corner where the user opens up the application on their mobile device and they want to go look at say some calendar items in their calendar using the Microsoft graph what the application is going to do is it's gonna realize that the users not logged in and so what it does is it will then take the user it'll open up a browser on the mobile device and it will send the user to the authentication URL or authorization URL at Azure ad so our resource owner in the bottom left corner is then going to log in to Azure ad that's that line going across the bottom of our of the slide there it says grant access the authorization server is going to prompt the user for their credentials that are gonna log in with their username and password keep note though that the user is not providing their credentials to the application is providing it to Azure ad that we trust if the application if the user has not already granted the mobile application um specific permissions to the Microsoft graph then Azure ad is going to prompt the user to grant at those permissions and that's the common consent framework that's where it's gonna say this application needs access to this permission this permission this permission do you accept those permissions and you say yes or accept the authorization server is then going to hand back the resource owner a code an authorization code and the user is then going to inside the mobile client that's going to then go from the browser login back over to the client the application there's a certain code that we're gonna have to write to make this work and the application then in the top left corner we'll be able to take that authorization code and then go log into Azure ad and provided this code and say I need access token for this user as your ad is gonna look at that code and say I can tell that this is a code that I created I being as your ad because it was digitally signed by Azure ad with their private key so they know that the contents of these sort of the code are valid because it has digital signature that matches one that only as your ad could have signed so we it trusts that service so it will then take that code it knows that in that code it says things like it was the user was me if they're trying to access the Microsoft graph and that it's coming from this application this native app so as your ad will look inside of his database and say has this user granted this application permissions to the Microsoft graph and the answer is yes because that's what we just did it will then create an OAuth access token and it will hand that back and that diagnol line going from the bottom left to the top right that says issue token it will send that over to the back to the native application and that access token will contain the user it will contain the resource that the token is is valid for in our case the Microsoft graph and it will contain all the Scopes or permissions that the user granted the application and now from the top left corner the native app can then request the make an access data request over to the Microsoft graph that's the horizontal line across the top going from left to right to the resource server the Microsoft graph the Microsoft graph will get that token it will look at the token and it will say is this token valid it knows it's valid because it's going to look at the digital signature and it knows that it's going to be able to match the digital signature against the public key that Azure ad uses because the only thing that that's going to match is the private key that Azure ad uses so Microsoft graph can say I trust that this access token was created by a gerrate he and the applications giving it to it's then going to open up that access token and know that I can see that this is a request for this specific user this access token is intended for the mark soft grass and it has these permissions so it will then access the data that's being requested and then hand that back to our native ooofff client our native application and that's how the whole authentication dance and authentication flow is going to work here you notice here that both the client and the resource server need to know about the authorization server which in our case is Azure ad let me talk a little bit about different endpoint versions that we have in Azure ad we have a v1 endpoint and a v2 endpoint v1 came first obviously v2 came second now how did this work well in the v1 endpoint there was two characteristics to it that were that are worth noting here that and why we don't use it in a scenario for the Microsoft graph anymore one of the scenarios is that as your ad only supported in the v1 endpoint only supported the azure active directory authentication it did not support any other styles of authentication and so what that meant is that if the user was logging in with a personal account or consumer account also known as a Microsoft account and they wanted to access things like their onedrive consumer account or their outlook comm account things like that they our application would have to know what kind of account they were signing in with and we would have to send them to a whole different authentication model so that's one downside because as your ad or the v1 endpoint only supported work in school accounts or accounts with that leverage - your ad the other challenge that we had is that with a v1 endpoint it required what's called static consent which meant that every single permission that our application was going to need when the user first logged in they were gonna have to grant all the permissions upfront at that time had to declare everything at the very first time but what that's going to allow us to do then is that we don't have to worry about that that extra complexity we're gonna let azure ad figure all that out for us so that's one nice thing that's the first two points converged authentication accept sign-in for both Microsoft personal accounts and Azure ad work in school and it enables the same code the code that we write for using the Microsoft graph for things like reading mail and retrieving contacts now the next thing that's really important here is the dynamic consent and what's nice about this this differs from v1 where we had static consent where now every time you go to request a access token from Azure ad you specify the permissions that you need for that access token now let's say for example in the example I gave a minute ago when the user went to login they had to grant all permissions that this application could possibly need up front well now when the user signs in all I really need to do is I just need to request the user impersonation scope and that's gonna allow me to get information about the current user just get their name their email address etc and now they get a much better experience and they log into my app maybe they're only gonna use the capability to reorder reorganize their email into different folders when they go to do that I can request another access token that says I need mail dot read and mail dot write and when I do that then the users only be prompted for those permissions if they had not already granted those permissions to the app the next time they go to use the app same thing it's gonna go check to see we need these permissions as your ad says I can tell this user has already granted those permissions so we don't need to go through that whole process a second time but we don't have to request permissions for their calendar for their tasks or for their files in onedrive we only need to ask that stuff when they actually need it so that's a I think that's a better experience because your users aren't hit with a lot of stuff and you've seen a similar model with this like on your mobile devices you an application may like if you were gonna use one of these social apps and you wanted to post something to this social network let's say you just want to post some text well it doesn't need a permission for that but then if you wanted to say post a picture that you had taken they need access to your photos on your phone and so it prompts you for do you grant this application access to your photos yes or no the next thing is maybe I want to take a picture and have it send right away so then it's gonna ask for permissions to your your camera or you want to do a little video so now it wants permissions to your camera and your microphone if you would installed the app and the first time you want to log in it says I need access to your microphone and your camera and your photos you may be a bit turned off by the app and say I don't want to give you all those permissions I just want to post some text to this social network that's what dynamic consent is all about it allows you to incrementally just grant these permissions and you can learn more about the v2 end point if you - aka EMS hey dv2 now let me talk about some of the other improvements from the v1 endpoint to the v2 endpoint in the v1 endpoint you had to provide a resource parameter to identify which resources you were requesting an access token for and the challenge with this is that some of the open source libraries were not able to easily incorporate that into their requests so now we use the scope parameter which is supported by all the libraries - compound and combine both the resource and the permission when you build applications with Azure ad v1 you also had to register all permissions the application needed that was called static consent we just went through that a minute ago the user had to consent to all of those things statically but with v2 we can now send scopes that you want at the time you want them we don't have to ask for them all up front that's the dynamic consent we're also going to change the contents of the ID token this is the the token that is going to be included with the response from the login that contains information about the current user like their email address and their name etc and this is going to better conform to the open ID Connect v1 specification for example we're using things like preferred username claim instead of a claim called UPN and also in the past if you needed a client application or a single page application or a web app or a web API or a daemon service we had to create multiple azure ad registrations and wire up each of the relationships between each one of those and it was a bit of a pain but now in the v2 this is now is going to enable us just one after edge astray ssin across a single logical application and we can then open up all the different areas that we support for the different applications such as representing a native in a web application if we wanted to for more information you can use that link at the bottom of the slide to learn more about the v1 vers v2 key improvements now let me talk a little bit about working with the different SDKs when it comes to Azure ad now the nice thing about this is that you really are going to self-select yourself into which one you're going to use if you're using the v1 authentication endpoint you have to use the Azure Active Directory authentication library or a towel it only works at v1 if you're gonna be using the v2 endpoint with the dynamic consent and some of the other things we've talked about which is the recommendation from the Microsoft graph team you're gonna be using the Microsoft authentication library this targets the v2 endpoint it's got a new conceptual model of two different kinds of applications once called a public client app and one it's called a confidential client app a confidential client is one that has a like runs and a as a web experience where you can put both the client ID in the secret in the application where a public client application is one going to be it to be more like a native app where I'm not gonna be able to provide the the secret I'm going to be prying providing the client ID we also have a couple different platforms on where this is supported there's MSA l net for the.net client Windows Store asp.net core Android iOS xamarin Universal Windows platform there's a JavaScript implementation and objective-c implementation for iOS and Mac OS and an Android implementation as well now where are we going to register our applications um this has changed a little bit over the years but now where we would recommend that you go is to go to the azure ad admin portal that's at a ad portal Dodger comm now there's a bunch of advantages to using this first advantage here is that you don't need to have a asher subscription to get to the azure ad admin portal you can log in with either a Microsoft account or an azure ad account and you'll see in the demo when we log into this it looks like the azure portal except the options of all the different Azure resources that are available to us are all gone except for asher ad this new admin portal is also going to allow you to create and manage both v1 and v2 style azure ad applications so you can have access to both the v1 and v2 authorization endpoints you're also going to be able to leverage either a Dell or MS al for authentication and as I said in the last slide that really is gonna be dictated based on what you end up doing with your using either the v1 of the v2 end point but because we're dealing with a Microsoft graph as I said before you really are going to want to focus on using the v2 end point so what does it look like well you're gonna go to the azure ad admin portal and you're gonna create a new application so here I give it a name and then I specify what account types are available to me so I could say that I want to use this is where you're really gonna pick are you going to support working school accounts in Azure ad or Microsoft accounts and the first two choices that you see they're worth accounts in the organization directory only or organizations in any organization directory that basically is saying is it multi tenant or single tenant the first option is saying single tenant meaning only people inside of my Azure ad or inside of my organization can use this app the second one is multi tenant saying the apps going to be registered in my Azure ad but anybody can use it that has Azure ad and the last one is saying really anybody both anybody in any Azure ad and anybody with a personal account a Microsoft account or an MSA such as a Skype account an Xbox account or an outlook.com account once you've done that your application has been created and you're gonna have an application ID so you're going to grab that ID and copy that down and then you're gonna have these redirect URIs and this basically it's gonna say once someone logs in where should they be sent or what valid places can they be sent and at the top you see that there's a web option and that's where if I was building a web site where would I redirect them to after they signed in but that doesn't work on a mobile experience or on a native experience like on the desktop and so instead we're gonna choose this first option here which is using MSA L which basically is going to have a special kind of a code that includes the ID of the application that the native SDKs are gonna understand how to work with now let's talk a little bit about implementing Azure ad authentication for Android based apps the azure ad team is going to provide Android SDK for native Android applications what you're going to do is you're going to add this to your project using the Gradle tool that I talked about earlier again Gradle is a tool for build and package management that is commonly used in Android development and it's very similar to ms build in new get that we're familiar with in the.net world you're also going to want to add in a reference to something called volley volley is a Android based package library that is used for HTTP networking as well so you can see I have these listed here the version numbers may be different based on what you're doing and where you are when you're watching this video as the Microsoft authentication library is relatively new in terms of being generally available as of mid 2019 and so you may see new versions of this that are available and you may not be using the version that you see listed here alright let's see a demo now in this demo we're going to create an application using the azure ad admin portal and then I'm going to show you how what we've done to our Android application since the last demo to add in the Microsoft authentication library and then some of the configuration changes that we have to do in order to make our application work with Azure ad so let's go and dive into the demo alright the first step that we're going to need to integrate the Microsoft authentication library in our application is I'm going to start by going to the Azure Active Directory admin center and creating a new application in Azure ad that we can use as our app so what I'm going to do first I've gone ahead and gone to the azure ad admin portal that you see listed here and I've gone and logged in so now I'm gonna go over here to the app registrations and create a brand new app so I'm gonna go to a preju stration z-- and I'm going to select new registration and I'm gonna go ahead and give this a name so we'll just call us our native oh three sixty-five calendar events and when I do that I'm going to say I'm gonna allow any organization to use it so I could use my Microsoft account like use my my Azure Active Directory account and anybody else could use it as well inside their applications as well so go through and I'll then select register here or if you see down here at the bottom the URI I'm gonna leave that blank and you'll see because we're not doing anything with a web-based application so I go ahead and do this and I'm gonna copy need to create a copy of this good here so I'm gonna go ahead and copy this and paste it down and a little scratch pad off to the side now that I've done that let's go over here and let's add in a redirect URI so I'm gonna go to so I'm gonna select add a redirect URI and I'm gonna choose this MSA el option right here so this has the entire string of my ID of my my application I'm gonna go ahead and select that one and then I'm gonna go ahead and hit save now while it's doing that I'm actually gonna copy this to the clipboard as well is I'm gonna need this in a later step now let's go through unless I know you set this up we're pretty much pretty much good to go for our application now that we've got our application all set up the next thing we're gonna need to do is then go modify the actual code so let's switch over to the code okay so let's see what we've done with our application to add in the Microsoft authentication library support so I go over here to my build.gradle and what you'll see is I've added in a couple options now we see the graph SDK here we're gonna deal with that in the next demo but what you'll notice here is I've added in an implementation here for the Microsoft authentication library now what I've also done is over here under resources and values I have an OAuth strings section and so this section right here is where I'm going to define things like the permissions that my application is going to need as well as the ID of my app inside of azure ad so what I'm gonna do is I'm gonna grab the gooood of what we just created a minute ago I'm gonna go ahead and paste that in like so I'm also going to include here where I have this word ask for the redirect URI now if you recall from what we actually created a couple minutes ago when we create our redirect URI and I copied it in there's something you really want to pay attention here because the MS al Android SDK has got an interesting kind of little way of dealing with this and you this is a something you could run into so if I go back if I go back to the browser notice here that this is what my string looks like here for my my redirect URI and notice it starts with MS al and then there's the long GU it and then it finishes with colon slash slash off and it says you're gonna use this for MS al but if you look at the code for my project you'll notice here that it just says your app ID here and knows MSA ELLs in the front at the front and then the colon slash slash off at the very end is missing well now in the lab what I tell you to do is I tell you to make sure that you d