 Hello and welcome everybody. Thank you for joining. This is integrating Microsoft Identities into your application, otherwise known as Converged Authentication for Microsoft Services. My name is Danny Strokes. I'm a Program Manager in the Microsoft Identity Division, and I'm here to talk a little bit today about the path forward for the Microsoft Identity Services. Here we have Office.com, and when you first come to Office.com, you try to sign in, and you'll notice there's a decision that you have to make right off the bat. Do I sign into Office for home or for work school or university? Well, if you click work school or university, you'll end up here on this page. This is the Azure Active Directory sign-in page. It allows users to sign into Office with their work or the school account that's been provided to them by their organization. So this is my Danny at Microsoft.com account or the Bob at Contoso.com account, etc. Azure Active Directory is a Cloud Authentication Service. It's actually the Cloud Authentication Service that does all the authentications for Office 365, and every single Office 365 customer that has a subscription with Office 365 has an associated Azure AD tenant or an instance of Azure AD. For developers, Azure AD is a way to sign users into an app using users' work accounts. It allows you to outsource authentication to Microsoft into a Cloud Service so that you don't have to collect usernames and passwords yourself or integrate with any sort of complex configured on-prem directories. For IT admins, Azure AD is a way for them to manage users, groups, the apps that their organization uses the permission to those applications and the permission to resources in their organization. Now, if you click the For Home button on the Office.com page, you would have ended up here. This is the Microsoft account sign-in page. It's the sign-in page for consumers. Any single person on the planet can go and sign up for Microsoft accounts and provide an email address and create a password and have one of these accounts. Microsoft account is another Cloud Authentication Service. It's also known as Windows Live ID, MSA, your personal account, things like that. For developers, Microsoft account has really just been a way to get access to Microsoft first-party services. The canonical example is OneDrive. If you wanted to access a user's OneDrive file using their personal OneDrive, you would integrate with a Microsoft account service, have the user login, grant your app some access to talk to OneDrive, get a token back and play that against OneDrive's REST APIs. For IT admins, well, this is the consumer space and there aren't any for Microsoft accounts. You are your own IT admin in this world. So we have these two systems, Azure AD and Microsoft accounts. And these kind of span the Microsoft identity services. For personal Microsoft accounts, it's a fairly large service. It's been running for years and years. There's over a billion accounts in total and there's been a lot of great investment put into the service around threat detection, risk analysis, and it's a very advanced security system. On the other hand, we have Azure AD, which is a slightly newer service. It's growing very rapidly. It has tens of millions of active users, over a million active tenants. And like I said, it's the authentication service for all of Office 365 today. My point here is that both these services have been fairly successful. They have scaled to millions and millions of users and they've been running reliably for several years. So doing pretty well in their own right. However, there's been a trend in industry that we're seeing and that we're seeing in many, many different industries as well, is that the lines between consumer and enterprise are starting to blur a bit. I'll give you some examples. Here we have Office. Office is one of the biggest examples of an app which wants to target both consumer customers and business customers. Another example might be Google Apps for Work. Google Apps started as a consumer oriented service and now it's expanding into the enterprise space. GitHub for Enterprise. Dropbox for Business. Evernote, Uber, Amazon, Azure. The list goes on and on and on. All of these applications are apps which want to target both consumers and enterprise customers. They want to be able to have users sign in with both their everyday regular life credentials as well as their work provided credentials that are managed by their IT administrators. So when we have these two different authentication services, Azure AD and Microsoft Account, it can lead to some not so great behavior when you try to build an app that has both types of customers. Here for DocuSign and Cool Learning, we have two different buttons. We have a Microsoft Account button and an Office 365 button, which does easier click, we're not really sure. Two different user experiences. Both of these UXs look kind of similar. It could be pretty easy to mistake one for the other. You might enter your credentials in the wrong place and think that you've forgotten your password. Two different authentication endpoints for developers that they have to hit to integrate with the systems themselves. Two different app registrations when you want to sign up for an application with Microsoft. Two different SDKs to use, the Live SDK and the Active Directory Authentication Library and two different APIs to hit when you actually want to get some data from Microsoft. Our poor developer here just wants to get some calendar data about his users and he has to put intelligent logic into his application to say, okay, if the user is a consumer user, let's sign him in and get a token from MSA and hit the apis.live.net API and get back some calendar data. But if the user is a work account user, let's instead go talk to Azure AD, get a token from Azure AD, play that against outlook.office365.com and get back probably a pretty different representation of a calendar event. That makes life pretty hard for the developers that want to span both the consumer and organizational spaces. So what we're doing to ease the pain for some of these challenges for developers is introducing what's called App Model V2.0. App Model V2.0 is a union of the Microsoft account and Azure AD authentication services. It's a new endpoint with a new URL that you can hit in your applications. It allows you to authenticate users with both their personal and their work or school accounts. It gives your users a single login page with the familiar look and feel. You have a single app registration portal for your applications, some new protocol features and a single set of libraries which allows you to take advantage of those protocol features. The point here is that as a developer, you make one integration with Microsoft in your application and you can reach both the consumer and enterprise worlds. It is not, however, a new service. The App Model V2.0 is served by the same exact infrastructure that serves the Microsoft account and Azure AD request today. You get the same reliability, same scalability that's been going on for the last few years. Now, an authentication service is only as good as the resources which it protects. And in this case, we're talking about Office 365. Also as part of Connects, we're introducing what's called the Microsoft Graph. The Microsoft Graph is a single endpoint that will serve all of REST API requests for Microsoft online services. Today, this includes things like mail contacts and calendar from Outlook and Exchange as well as files from OneDrive and a user's profile data. Over time, the Microsoft Graph will grow to include many more entities such as the groups a user is a member of, the files they have access to, their relationships with their managers, the things that are trending in their organization. It's a very people-centric view of the Microsoft online services world. All of this information will be served at a single endpoint called graph.microsoft.com and there's some great sessions this week as well on the Microsoft Graph in particular. The point here is that every single request to the Microsoft Graph in graph.microsoft.com is served by authentication tokens from the app model V2. The way you authenticate to graph.microsoft.com will be the same for consumers as it will for businesses. I'd like to show you just how this works in a little web application I threw together. So let's have a quick look. So the first thing you'll need to do when you wanna integrate an application with app model V2.0 is register an application with Microsoft. To do that, you'll come to apps.dev.microsoft.com which is the new location for our application registration portal. You can see I already have a few applications registered. You can always add a new one providing some basic information like the name of the app, but we'll use my convergence demo application that I've already curated. I've given it a name. It's assigned my application and identifier already and I've provided some additional information like the URL of my application and you can customize your app if you want to as well. Once you've registered an app, you can go to your code and plug in this information. Here I have a .NET MVC framework web application that uses the same client ID that I just got from the portal. It's already running, so let's take a look. Here's my web app running at localhost. And what I can do here is sign in and it'll take me to the app model V2 Converged Authentication page. Here I'm going to sign in first as a user, an organizational user, and an Azure AD tenant. So strokastev9.onmicrosoft.com is one of my tenants that I have here. And I can sign in, get some claims to the token, display the user's email, so on and so forth. And what I can do is when I click on the calendar tab, I make a rest request to the Outlook and Exchange calendar API and get some calendar events, the most recent calendar events from sample admins calendar here. You can see it hasn't had much going on, so the last event was back in July. But it's cool, I can make a request and get the information back from the calendar API. Now we can switch users and send a new request to the app model V2 endpoint and say, okay, let's use a different account this time. And this time I'm going to use a personal account. I already have one set up here. So we'll plug that information in. And now I'm signed into the same application using a MSA account or a live ID. I can go to the calendar tab and the same rest request that we made and as you can see it returns the most recent information, the most recent calendar events for this user also back in July. So this is pretty cool. We've created a web application that uses a single library. It's using Microsoft's own.net framework. And we've made rest requests using a single token type to the Microsoft graph and got back information about our users' calendars. The vision behind app model V2.0 is that you have a single development experience for accessing all Microsoft online services. Users get a consistent user experience when they log in and they grant consent to your application, something that they come to no interest over time. You get the best features of Microsoft account and Azure AD authentication services and we omit some of the worst features from the past. So if you wanna get involved, try things out. There's some great resources out there for you. The documentation is definitely the best place to start. It'll be available for you shortly at graph.microsoft.com. There's also some additional reference information available at aka.ms.aaddev, which will take you to the azure.com documentation. If you're trying things out and you hit some sweet bumps and stumbles, try Stack Overflow, that's the best place that we monitor very closely. If you use the tags Microsoft Graph or Office 65 or Azure Active Directory, you'll get our attention the quickest. And if you wanna reach out to me personally at any time, my Twitter handle is on the screen here. Thank you so much for joining. I hope I sparked your interest in some of the Microsoft identity features and platforms that we offer for you and happy coding.