fix acrolinx issues

davidmu1 · davidmu1 · commit 4c423f6237d7 · 2020-03-04T13:16:56.000-08:00
diff --git a/articles/active-directory/develop/TOC.yml b/articles/active-directory/develop/TOC.yml
@@ -646,7 +646,7 @@
   - name: Azure AD blog
     href: https://cloudblogs.microsoft.com/enterprisemobility/?product=azure-active-directory
   - name: Microsoft identity platform developer blog
-    href: https://developer.microsoft.com/en-us/identity/blogs/
+    href: https://developer.microsoft.com/identity/blogs/
   - name: Try Sign in with Microsoft
     href: https://azure.microsoft.com/develop/identity/signin/
   - name: Getting help
diff --git a/articles/active-directory/develop/access-tokens.md b/articles/active-directory/develop/access-tokens.md
@@ -78,7 +78,7 @@ Claims are present only if a value exists to fill it. So, your app shouldn't tak
 
 | Claim | Format | Description |
 |-----|--------|-------------|
-| `aud` | String, an App ID URI | Identifies the intended recipient of the token. In id tokens, the audience is your app's Application ID, assigned to your app in the Azure portal. Your app should validate this value and reject the token if the value does not match. |
+| `aud` | String, an App ID URI | Identifies the intended recipient of the token. In ID tokens, the audience is your app's Application ID, assigned to your app in the Azure portal. Your app should validate this value and reject the token if the value does not match. |
 | `iss` | String, an STS URI | Identifies the security token service (STS) that constructs and returns the token, and the Azure AD tenant in which the user was authenticated. If the token issued is a v2.0 token (see the `ver` claim), the URI will end in `/v2.0`. The GUID that indicates that the user is a consumer user from a Microsoft account is `9188040d-6c67-4c5b-b112-36a304b66dad`. Your app should use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable. |
 |`idp`| String, usually an STS URI | Records the identity provider that authenticated the subject of the token. This value is identical to the value of the Issuer claim unless the user account not in the same tenant as the issuer - guests, for instance. If the claim isn't present, it means that the value of `iss` can be used instead.  For personal accounts being used in an organizational context (for instance, a personal account invited to an Azure AD tenant), the `idp` claim may be 'live.com' or an STS URI containing the Microsoft account tenant `9188040d-6c67-4c5b-b112-36a304b66dad`. |  
 | `iat` | int, a UNIX timestamp | "Issued At" indicates when the authentication for this token occurred. |
diff --git a/articles/active-directory/develop/active-directory-claims-mapping.md b/articles/active-directory/develop/active-directory-claims-mapping.md
@@ -1,5 +1,5 @@
 ---
-title: Customize Azure AD tenant app claims (Powershell)
+title: Customize Azure AD tenant app claims (PowerShell)
 titleSuffix: Microsoft identity platform
 description: This page describes Azure Active Directory claims mapping.
 services: active-directory
@@ -410,7 +410,7 @@ Based on the method chosen, a set of inputs and outputs is expected. Define the
 
 ### Custom signing key
 
-A custom signing key must be assigned to the service principal object for a claims mapping policy to take effect. This ensures acknowledgment that tokens have been modified by the creator of the claims mapping policy and protects applications from claims mapping policies created by malicious actors. In order to add a custom signing key, you can use the Azure Powershell cmdlet `new-azureadapplicationkeycredential` to create a symmetric key credential for your Application object. For more information on this Azure Powershell cmdlet click [here](https://docs.microsoft.com/powershell/module/Azuread/New-AzureADApplicationKeyCredential?view=azureadps-2.0).
+A custom signing key must be assigned to the service principal object for a claims mapping policy to take effect. This ensures acknowledgment that tokens have been modified by the creator of the claims mapping policy and protects applications from claims mapping policies created by malicious actors. In order to add a custom signing key, you can use the Azure PowerShell cmdlet `new-azureadapplicationkeycredential` to create a symmetric key credential for your Application object. For more information on this Azure PowerShell cmdlet, see [New-AzureADApplicationKeyCredential](https://docs.microsoft.com/powerShell/module/Azuread/New-AzureADApplicationKeyCredential?view=azureadps-2.0).
 
 Apps that have claims mapping enabled must validate their token signing keys by appending `appid={client_id}` to their [OpenID Connect metadata requests](v2-protocols-oidc.md#fetch-the-openid-connect-metadata-document). Below is the format of the OpenID Connect metadata document you should use: 
 
diff --git a/articles/active-directory/develop/microsoft-graph-intro.md b/articles/active-directory/develop/microsoft-graph-intro.md
@@ -41,17 +41,14 @@ To read from or write to a resource such as a user or an email message, you cons
 
 For more information about the elements of the constructed request, see [Use the Microsoft Graph API](https://docs.microsoft.com/graph/use-the-api)
 
-Quick start samples are available to show you how to access the power of the Microsoft Graph API. The samples that are available access two services with one authentication: Microsoft account and Outlook. Each quick start accesses information from Microsoft account users' profiles and displays events from their calendar.
-The quick starts involve four steps:
+Quickstart samples are available to show you how to access the power of the Microsoft Graph API. The samples that are available access two services with one authentication: Microsoft account and Outlook. Each quickstart accesses information from Microsoft account users' profiles and displays events from their calendar.
+The quickstarts involve four steps:
 - Select your platform
 - Get your app ID (client ID)
 - Build the sample
 - Sign in, and view events on your calendar
 
-
-
-
-When you complete the quick start, you have an app that's ready to run. For more information, see the [Microsoft Graph quick start FAQ](https://docs.microsoft.com/graph/quick-start-faq). To get started with the samples, see [Microsoft Graph Quick Start](https://developer.microsoft.com/en-us/graph/quick-start).
+When you complete the quickstart, you have an app that's ready to run. For more information, see the [Microsoft Graph quickstart FAQ](https://docs.microsoft.com/graph/quick-start-faq). To get started with the samples, see [Microsoft Graph QuickStart](https://developer.microsoft.com/graph/quick-start).
 
 ## Tools
 
diff --git a/articles/active-directory/develop/v2-permissions-and-consent.md b/articles/active-directory/develop/v2-permissions-and-consent.md
@@ -162,7 +162,7 @@ To see a code sample that implements the steps, see the [admin-restricted scopes
 
 ### Request the permissions in the app registration portal
 
-Applications are able to note which permissions they require (both delegated and application) in the app registration portal.  This allows use of the `/.default` scope and the Azure Portal's "Grant admin consent" option.  In general, it's best practice to ensure that the permissions statically defined for a given application are a superset of the permissions that it will be requesting dynamically/incrementally.
+Applications are able to note which permissions they require (both delegated and application) in the app registration portal.  This allows use of the `/.default` scope and the Azure portal's "Grant admin consent" option.  In general, it's best practice to ensure that the permissions statically defined for a given application are a superset of the permissions that it will be requesting dynamically/incrementally.
 
 > [!NOTE]
 >Application permissions can only be requested through the use of [`/.default`](#the-default-scope) - so if your app needs application permissions, make sure they're listed in the app registration portal.
