{"id":2002,"date":"2018-11-08T11:00:50","date_gmt":"2018-11-08T11:00:50","guid":{"rendered":"https:\/\/developer.microsoft.com\/en-us\/office\/blogs\/?p=2002"},"modified":"2018-11-08T11:00:50","modified_gmt":"2018-11-08T11:00:50","slug":"30daysmsgraph-day-8-authentication-roadmap-and-access-tokens","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/30daysmsgraph-day-8-authentication-roadmap-and-access-tokens\/","title":{"rendered":"30DaysMSGraph \u2013 Day 8 \u2013 Authentication roadmap and access tokens"},"content":{"rendered":"

List of all posts in the #30DaysMSGraph series<\/a><\/p>\n

In Day 7<\/a> we discussed paging results for Microsoft Graph requests.\u00a0 Today we’ll look at the current and future states of authenticating to Microsoft Graph, specifically obtaining access tokens.\"\"Any calls made to Microsoft Graph need to be properly authenticated by including an access token.\u00a0 In the case of Microsoft Graph an access token is a base 64 encoded JSON web token (JWT) which must be issued by Azure Active Directory (Azure AD).<\/p>\n

There are 2 primary authentication flows against Azure Active Directory:<\/p>\n

    \n
  1. On behalf of user\n
      \n
    1. Also called delegated or app + user<\/li>\n<\/ol>\n<\/li>\n
    2. Application\n
        \n
      1. Also called app-only<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

        Depending on which authentication flow you build into your application the high-level steps will be as follows:<\/p>\n

          \n
        1. Register application in Azure AD<\/li>\n
        2. Configure \/ grant permissions<\/li>\n
        3. Get access token<\/li>\n
        4. Use access token to call Microsoft Graph<\/li>\n<\/ol>\n

          We’ll cover each of these steps in greater detail in later posts.<\/p>\n

          Knowing that we need to obtain an access token, let’s discuss the current and future states of authenticating to Microsoft Graph.\u00a0 Keep in mind there are a few elements that are currently in production supported preview<\/a>.<\/p>\n

          Current state<\/h3>\n

          Currently, authenticating against Microsoft Graph involves a few decisions as there are multiple portals to register an application, multiple client SDKs, and multiple Azure AD endpoints.\u00a0 Knowing your target audience is a key decision point as it influences which components you can or can’t use.\u00a0 MSAL and the Azure AD v2 endpoint are the go-forward direction (see Future state below) and as such we recommend you start there.\u00a0 ADAL and the v1 endpoints currently support a limited number of authentication scenarios that aren’t yet in MSAL \/ Azure AD v2 endpoint but those differences are expected to be addressed soon\u00a0.\u00a0 Please see the article for Comparing the Azure AD v2.0 endpoint with the v1.0 endpoint<\/a> link in the appendix for the most up-to-date information on deciding between v1 or v2.<\/p>\n

          \"\"<\/p>\n

          Future state<\/h3>\n

          The future state of authenticating to Microsoft Graph is targeting the following diagram.\u00a0 In this diagram notice that the Azure AD v2 endpoint can issue v1 or v2 tokens.\u00a0 Additionally, the Azure Portal is the sole location for registering applications.\u00a0 \u00a0 Overall the future state simplifies authenticating to Microsoft Graph by reducing the number of decision points and providing support for the broadest set of requirements.<\/p>\n

          \"\"<\/p>\n

          <\/h3>\n

          We’ll cover the actual steps to obtain an access token over the next few posts.\u00a0 For the time being let’s inspect an access token such as the below sample (sensitive information obscured):<\/p>\n

          \"\"<\/p>\n

          Note: An Azure AD access token is a Bearer token meaning any person or application that has possession of it can use it to make calls against Microsoft Graph with the consented permissions.\u00a0 As such you must ensure secure transmission and \/ or storage of them to prevent unintended use.<\/em><\/p>\n

          At first glance the format of these access tokens may appear unreadable, but you can decode them using various tools.\u00a0 The Azure AD team has provided the website http:\/\/jwt.ms<\/a> as one example.\u00a0 The following is an example of the output from a sample access token.<\/p>\n

          \"\"<\/p>\n

          Use the Claims<\/strong> tab after decoding an access token for additional information on each of the claims presented.\u00a0 This can be very helpful for troubleshooting an issue where an access token was generated with the incorrect scopes \/ roles, was issued for the wrong resource \/ audience, and more.\u00a0 Find additional information on the access token schema available in the\u00a0Azure Active Directory Access Tokens<\/a>\u00a0resource.<\/p>\n

           <\/p>\n

          Try It Out<\/h2>\n

          Navigate to the documentation for Azure AD Access Tokens.\u00a0 Decode the v1 and v2 sample tokens using http:\/\/jwt.ms<\/a>.\u00a0 Inspect the claims used for each<\/p>\n

          Day 8 repo link<\/a><\/p>\n

            \n
          1. V1 sample token\n