Merge pull request #97147 from CelesteDG/celested-aadgraph-references

updated references to include Microsoft Graph

Author: GitHubber17

articles/active-directory-b2c/active-directory-b2c-apps.md

@@ -120,7 +120,7 @@ To set up client credential flow, see [Azure Active Directory v2.0 and the OAuth
 
 #### Web API chains (on-behalf-of flow)
 
-Many architectures include a web API that needs to call another downstream web API, where both are secured by Azure AD B2C. This scenario is common in native clients that have a Web API back-end and calls a Microsoft online service such as the Azure AD Graph API.
+Many architectures include a web API that needs to call another downstream web API, where both are secured by Azure AD B2C. This scenario is common in native clients that have a Web API back-end and calls a Microsoft online service such as the Microsoft Graph API or Azure AD Graph API.
 
 This chained web API scenario can be supported by using the OAuth 2.0 JWT bearer credential grant, also known as the on-behalf-of flow.  However, the on-behalf-of flow is not currently implemented in the Azure AD B2C.
 

articles/active-directory/develop/about-microsoft-identity-platform.md

@@ -49,7 +49,7 @@ The following diagram shows the Microsoft identity experience at a high level, i
 
 The Azure portal **[App registrations](https://go.microsoft.com/fwlink/?linkid=2083908)** experience is the one portal experience for managing all applications you’ve integrated with Microsoft identity platform. If you have been using the Application Registration Portal, start using the Azure portal app registration experience instead.
 
-For integration with Azure AD B2C (when authenticating social or local identities), you’ll need to register your application in a B2C tenant. This experience is also part of the Azure portal.
+For integration with Azure AD B2C (when authenticating social or local identities), you’ll need to register your application in an Azure AD B2C tenant. This experience is also part of the Azure portal.
 
 The **application API in Microsoft Graph** is currently in preview. Use this API to programmatically configure your applications integrated with Microsoft identity platform for authenticating any Microsoft identity. However, until this API reaches general availability, you should use the Azure AD Graph 1.6 API and the application manifest.
 

articles/active-directory/develop/active-directory-graph-api-quickstart.md

@@ -25,9 +25,9 @@ ms.collection: M365-identity-device-management
 # How to: Use the Azure AD Graph API
 
 > [!IMPORTANT]
-> We strongly recommend that you use [Microsoft Graph](https://developer.microsoft.com/graph) instead of Azure AD Graph API to access Azure Active Directory resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the [Microsoft Graph or the Azure AD Graph](https://dev.office.com/blogs/microsoft-graph-or-azure-ad-graph) blog post and [Migrate Azure AD Graph apps to Microsoft Graph](https://docs.microsoft.com/graph/migrate-azure-ad-graph-overview).
+> We strongly recommend that you use [Microsoft Graph](https://developer.microsoft.com/graph) instead of Azure AD Graph API to access Azure Active Directory (Azure AD) resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the [Microsoft Graph or the Azure AD Graph](https://dev.office.com/blogs/microsoft-graph-or-azure-ad-graph) blog post and [Migrate Azure AD Graph apps to Microsoft Graph](https://docs.microsoft.com/graph/migrate-azure-ad-graph-overview).
 
-The Azure Active Directory (Azure AD) Graph API provides programmatic access to Azure AD through OData REST API endpoints. Applications can use Azure AD Graph API to perform create, read, update, and delete (CRUD) operations on directory data and objects. For example, you can use Azure AD Graph API to create a new user, view or update user’s properties, change user’s password, check group membership for role-based access, disable, or delete the user. For more information on Azure AD Graph API features and application scenarios, see [Azure AD Graph API](https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/api-catalog) and [Azure AD Graph API prerequisites](https://msdn.microsoft.com/library/hh974476.aspx). Azure AD Graph API only works with work or school/organization accounts.
+The Azure AD Graph API provides programmatic access to Azure AD through OData REST API endpoints. Applications can use Azure AD Graph API to perform create, read, update, and delete (CRUD) operations on directory data and objects. For example, you can use Azure AD Graph API to create a new user, view or update user’s properties, change user’s password, check group membership for role-based access, disable, or delete the user. For more information on Azure AD Graph API features and application scenarios, see [Azure AD Graph API](https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/api-catalog) and [Azure AD Graph API prerequisites](https://msdn.microsoft.com/library/hh974476.aspx). Azure AD Graph API only works with work or school/organization accounts.
 
 This article applies to Azure AD Graph API. For similar info related to Microsoft Graph API, see [Use the Microsoft Graph API](https://developer.microsoft.com/graph/docs/concepts/use_the_api).
 

articles/active-directory/develop/active-directory-graph-api.md

@@ -13,7 +13,7 @@ ms.devlang: na
 ms.topic: conceptual
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 03/01/2019
+ms.date: 11/26/2019
 ms.author: ryanwi
 ms.reviewer: dkershaw, sureshja
 ms.custom: aaddev, identityplatformtop40
@@ -23,16 +23,9 @@ ms.collection: M365-identity-device-management
 # Azure Active Directory Graph API
 
 > [!IMPORTANT]
->
-> As of February 2019, we started the process to deprecate some earlier versions of Azure Active Directory Graph API in favor of the Microsoft Graph API. 
->
-> For details, updates, and time frames, see [Microsoft Graph or the Azure AD Graph](https://dev.office.com/blogs/microsoft-graph-or-azure-ad-graph) in the Office Dev Center.
->
-> Moving forward, applications should use the Microsoft Graph API. 
+> We strongly recommend that you use [Microsoft Graph](https://developer.microsoft.com/graph) instead of Azure AD Graph API to access Azure Active Directory (Azure AD) resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the [Microsoft Graph or the Azure AD Graph](https://dev.office.com/blogs/microsoft-graph-or-azure-ad-graph) blog post and [Migrate Azure AD Graph apps to Microsoft Graph](https://docs.microsoft.com/graph/migrate-azure-ad-graph-overview).
 
-
-
-This article applies to Azure AD Graph API. For similar info related to Microsoft Graph API, see [Use the Microsoft Graph API](https://docs.microsoft.com/graph/use-the-api). 
+This article applies to Azure AD Graph API. For similar info related to Microsoft Graph API, see [Use the Microsoft Graph API](https://docs.microsoft.com/graph/use-the-api).
 
 The Azure Active Directory Graph API provides programmatic access to Azure AD through REST API endpoints. Applications can use Azure AD Graph API to perform create, read, update, and delete (CRUD) operations on directory data and objects. For example, Azure AD Graph API supports the following common operations for a user object:
 

articles/active-directory/develop/active-directory-how-applications-are-added.md

@@ -15,22 +15,25 @@ ms.devlang: na
 ms.topic: conceptual
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 06/04/2019
+ms.date: 11/26/2019
 ms.author: ryanwi
 ms.custom: aaddev
-ms.reviewer: elisol, lenalepa
+ms.reviewer: lenalepa, sureshja
 ms.collection: M365-identity-device-management
 ---
 
 # How and why applications are added to Azure AD
 
-There are two representations of applications in Azure AD: 
+There are two representations of applications in Azure AD:
+
 * [Application objects](app-objects-and-service-principals.md#application-object) - Although there are [exceptions](#notes-and-exceptions), application objects can be considered the definition of an application.
 * [Service principals](app-objects-and-service-principals.md#service-principal-object) - Can be considered an instance of an application. 
 Service principals generally reference an application object, and one application object can be referenced by multiple service principals across directories.
 
 ## What are application objects and where do they come from?
+
 You can manage [application objects](app-objects-and-service-principals.md#application-object) in the Azure portal through the [App Registrations](https://aka.ms/appregistrations) experience. Application objects describe the application to Azure AD and can be considered the definition of the application, allowing the service to know how to issue tokens to the application based on its settings. The application object will only exist in its home directory, even if it's a multi-tenant application supporting service principals in other directories. The application object may include any of the following (as well as additional information not mentioned here):
+
 * Name, logo, and publisher
 * Redirect URIs
 * Secrets (symmetric and/or asymmetric keys used to authenticate the application)
@@ -42,13 +45,15 @@ You can manage [application objects](app-objects-and-service-principals.md#appli
 * Proxy metadata and configuration
 
 Application objects can be created through multiple pathways, including:
+
 * Application registrations in the Azure portal
 * Creating a new application using Visual Studio and configuring it to use Azure AD authentication
 * When an admin adds an application from the app gallery (which will also create a service principal)
-* Using the Microsoft Graph API, Azure AD Graph API, or PowerShell to create a new application
+* Using the Microsoft Graph API or PowerShell to create a new application
 * Many others including various developer experiences in Azure and in API explorer experiences across developer centers
 
 ## What are service principals and where do they come from?
+
 You can manage [service principals](app-objects-and-service-principals.md#service-principal-object) in the Azure portal through the [Enterprise Applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/) experience. Service principals are what govern an application connecting to Azure AD and can be considered the instance of the application in your directory. For any given application, it can have at most one application object (which is registered in a "home" directory) and one or more service principal objects representing instances of the application in every directory in which it acts. 
 
 The service principal can include:

articles/active-directory/develop/azure-ad-endpoint-comparison.md

@@ -12,7 +12,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: conceptual
-ms.date: 08/01/2019
+ms.date: 11/26/2019
 ms.author: ryanwi
 ms.reviewer: saeeda, hirsin, jmprieur, sureshja, jesakowi, lenalepa, kkrishna, negoe
 ms.custom: aaddev
@@ -58,9 +58,9 @@ Admin consent done on behalf of an organization still requires the static permis
 
 ## Scopes, not resources
 
-For apps using the v1.0 endpoint, an app can behave as a **resource**, or a recipient of tokens. A resource can define a number of **scopes** or **oAuth2Permissions** that it understands, allowing client apps to request tokens from that resource for a certain set of scopes. Consider the Azure AD Graph API as an example of a resource:
+For apps using the v1.0 endpoint, an app can behave as a **resource**, or a recipient of tokens. A resource can define a number of **scopes** or **oAuth2Permissions** that it understands, allowing client apps to request tokens from that resource for a certain set of scopes. Consider the Microsoft Graph API as an example of a resource:
 
-* Resource identifier, or `AppID URI`: `https://graph.windows.net/`
+* Resource identifier, or `AppID URI`: `https://graph.microsoft.com/`
 * Scopes, or `oAuth2Permissions`: `Directory.Read`, `Directory.Write`, and so on.
 
 This holds true for the Microsoft identity platform endpoint. An app can still behave as a resource, define scopes, and be identified by a URI. Client apps can still request access to those scopes. However, the way that a client requests those permissions have changed.

articles/active-directory/develop/msal-v1-app-scopes.md

@@ -13,7 +13,7 @@ ms.devlang: na
 ms.topic: conceptual
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 04/23/2019
+ms.date: 11/25/2019
 ms.author: twhitney
 ms.reviewer: saeeda
 ms.custom: aaddev
@@ -23,10 +23,11 @@ ms.collection: M365-identity-device-management
 
 # Scopes for a Web API accepting v1.0 tokens
 
-OAuth2 permissions are permission scopes that a Azure AD for developers (v1.0) web API (resource) application exposes to client applications. These permission scopes may be granted to client applications during consent. See the section about `oauth2Permissions` in the [Azure Active Directory application manifest reference](reference-app-manifest.md#manifest-reference).
+OAuth2 permissions are permission scopes that a Azure Active Directory (Azure AD) for developers (v1.0) web API (resource) application exposes to client applications. These permission scopes may be granted to client applications during consent. See the section about `oauth2Permissions` in the [Azure Active Directory application manifest reference](reference-app-manifest.md#manifest-reference).
 
 ## Scopes to request access to specific OAuth2 permissions of a v1.0 application
-If you want to acquire tokens for specific scopes of a v1.0 application (for example the Azure AD graph, which is https:\//graph.windows.net), you need to create scopes by concatenating a desired resource identifier with a desired OAuth2 permission for that resource.
+
+To acquire tokens for specific scopes of a v1.0 application (for example the Azure AD graph, which is https:\//graph.windows.net), you need to create scopes by concatenating a desired resource identifier with a desired OAuth2 permission for that resource.
 
 For example, to access on behalf of the user a v1.0 web API where the app ID URI is `ResourceId`:
 
@@ -38,7 +39,7 @@ var scopes = new [] {  ResourceId+"/user_impersonation"};
 var scopes = [ ResourceId + "/user_impersonation"];
 ```
 
-If you want to read and write with MSAL.NET Azure Active Directory using the Azure AD graph API (https:\//graph.windows.net/), you would create a list of scopes as in the following:
+To read and write with MSAL.NET Azure AD using the Azure AD Graph API (https:\//graph.windows.net/), you need to create a list of scopes as shown in the following examples:
 
 ```csharp
 string ResourceId = "https://graph.windows.net/";
@@ -50,7 +51,7 @@ var ResourceId = "https://graph.windows.net/";
 var scopes = [ ResourceId + "Directory.Read", ResourceID + "Directory.Write"];
 ```
 
-If you want to write the scope corresponding to the Azure Resource Manager API (https:\//management.core.windows.net/), you need to request the following scope (note the two slashes):
+To write the scope corresponding to the Azure Resource Manager API (https:\//management.core.windows.net/), you need to request the following scope (note the two slashes):
 
 ```csharp
 var scopes = new[] {"https://management.core.windows.net//user_impersonation"};
@@ -64,11 +65,12 @@ var result = await app.AcquireTokenInteractive(scopes).ExecuteAsync();
 
 The logic used by Azure AD is the following:
 
-- For ADAL (v1.0) endpoint with a v1.0 access token (the only possible), aud=resource
-- For MSAL (Microsoft identity platform (v2.0) endpoint) asking an access token for a resource accepting v2.0 tokens, aud=resource.AppId
-- For MSAL (v2.0 endpoint) asking an access token for a resource accepting a v1.0 access token (which is the case above), Azure AD parses the desired audience from the requested scope by taking everything before the last slash and using it as the resource identifier. Therefore if https:\//database.windows.net expects an audience of "https:\//database.windows.net/", you'll need to request a scope of "https:\//database.windows.net//.default". See also GitHub issue [#747: Resource url's trailing slash is omitted, which caused sql auth failure](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/747).
+- For ADAL (Azure AD v1.0) endpoint with a v1.0 access token (the only possible), aud=resource
+- For MSAL (Microsoft identity platform (v2.0)) endpoint asking an access token for a resource accepting v2.0 tokens, `aud=resource.AppId`
+- For MSAL (v2.0 endpoint) asking an access token for a resource that accepts a v1.0 access token (which is the case above), Azure AD parses the desired audience from the requested scope by taking everything before the last slash and using it as the resource identifier. Therefore, if https:\//database.windows.net expects an audience of "https:\//database.windows.net/", you'll need to request a scope of "https:\//database.windows.net//.default". See also GitHub issue [#747: Resource url's trailing slash is omitted, which caused sql auth failure](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/747).
 
 ## Scopes to request access to all the permissions of a v1.0 application
+
 If you want to acquire a token for all the static scopes of a v1.0 application, append ".default" to the app ID URI of the API:
 
 ```csharp
@@ -81,5 +83,6 @@ var ResourceId = "someAppIDURI";
 var scopes = [ ResourceId + "/.default"];
 ```
 
-## Scopes to request for client credential flow / daemon app
+## Scopes to request for a client credential flow/daemon app
+
 In the case of client credential flow, the scope to pass would also be `/.default`. This tells to Azure AD: "all the app-level permissions that the admin has consented to in the application registration.

articles/active-directory/develop/reference-saml-tokens.md

@@ -152,6 +152,7 @@ This is a sample of a typical SAML token.
     </t:RequestSecurityTokenResponse>
 
 ## Related content
+
 * See the Azure AD Graph [Policy operations](https://msdn.microsoft.com/library/azure/ad/graph/api/policy-operations) and the [Policy entity](https://msdn.microsoft.com/library/azure/ad/graph/api/entity-and-complex-type-reference#policy-entity), to learn more about managing token lifetime policy via the Azure AD Graph API.
 * For more information and samples on managing policies via PowerShell cmdlets, including samples, see [Configurable token lifetimes in Azure AD](active-directory-configurable-token-lifetimes.md). 
 * Add [custom and optional claims](active-directory-optional-claims.md) to the tokens for your application.