scenario-protected-web-api

Author: BobbySchmidt2

articles/active-directory/develop/scenario-protected-web-api-app-configuration.md

@@ -109,7 +109,7 @@ The middleware is added to the web API by this instruction:
  services.AddAzureAdBearer(options => Configuration.Bind("AzureAd", options));
 ```
 
- Currently, the ASP.NET Core templates create Azure Active Directory (Azure AD) web APIs that sign in users within your organization or any organization. They don't sign in users with personal accounts. But you can change the templates to use the Microsoft identity platform endpoint by adding this code to the Startup.cs file:
+ Currently, the ASP.NET Core templates create Azure Active Directory (Azure AD) web APIs that sign in users within your organization or any organization. They don't sign in users with personal accounts. But you can change the templates to use the Microsoft identity platform endpoint by adding this code to Startup.cs:
 
 ```csharp
 services.Configure<JwtBearerOptions>(AzureADDefaults.JwtBearerAuthenticationScheme, options =>
@@ -131,7 +131,7 @@ services.Configure<JwtBearerOptions>(AzureADDefaults.JwtBearerAuthenticationSche
 });
 ```
 
-This preceding code snippet is extracted from the ASP.NET Core web API incremental tutorial in [Microsoft.Identity.Web/WebApiServiceCollectionExtensions.cs#L50-L63](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/blob/154282843da2fc2958fad151e2a11e521e358d42/Microsoft.Identity.Web/WebApiServiceCollectionExtensions.cs#L50-L63). The **AddProtectedWebApi** method, which does more than the snippet shows, is called from Startup.cs.
+The preceding code snippet is extracted from the ASP.NET Core web API incremental tutorial in [Microsoft.Identity.Web/WebApiServiceCollectionExtensions.cs#L50-L63](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/blob/154282843da2fc2958fad151e2a11e521e358d42/Microsoft.Identity.Web/WebApiServiceCollectionExtensions.cs#L50-L63). The **AddProtectedWebApi** method, which does more than the snippet shows, is called from Startup.cs.
 
 ## Token validation
 
@@ -149,7 +149,7 @@ There can also be special validations. For example, it's possible to validate th
 
 The validation steps are captured in validators, which are provided by the [Microsoft IdentityModel Extensions for .NET](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet) open-source library. The validators are defined in the library source file [Microsoft.IdentityModel.Tokens/Validators.cs](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/master/src/Microsoft.IdentityModel.Tokens/Validators.cs).
 
-The validators are described in this table:
+This table describes the validators:
 
 | Validator | Description |
 |---------|---------|
@@ -160,9 +160,9 @@ The validators are described in this table:
 | **ValidateSignature** | Ensures the token hasn't been tampered with. |
 | **ValidateTokenReplay** | Ensures the token isn't replayed. There's a special case for some onetime-use protocols. |
 
-The validators are associated with properties of the **TokenValidationParameters** class. The properties are initialized from the ASP.NET and ASP.NET Core configuration. In most cases, you don't need to change the parameters.
+The validators are associated with properties of the **TokenValidationParameters** class. The properties are initialized from the ASP.NET and ASP.NET Core configuration.
 
-Apps that aren't single tenants are exceptions. These web apps accept users from any organization or from personal Microsoft accounts. In this case, issuers must be validated.
+In most cases, you don't need to change the parameters. Apps that aren't single tenants are exceptions. These web apps accept users from any organization or from personal Microsoft accounts. Issuers in this case must be validated.
 
 ## Token validation in Azure Functions
 

articles/active-directory/develop/scenario-protected-web-api-app-registration.md

@@ -52,7 +52,7 @@ After you create the application, you can determine or change the accepted token
 
 Web APIs don't need to register a redirect URI because no user is interactively signed in.
 
-## Expose an API
+## Exposed API
 
 Other settings specific to web APIs are the exposed API and the exposed scopes.
 
@@ -132,7 +132,7 @@ The web API checks for the app role. This role is a software developer's way to
 To add this increased security:
 
 1. Go to the app **Overview** page for your app registration.
-1. Under **Managed application in local directory**, select the link with the name of your app. The name of this selection might be truncated. For example, you might see **Managed application in ...**
+1. Under **Managed application in local directory**, select the link with the name of your app. The label for this selection might be truncated. For example, you might see **Managed application in ...**
 
    > [!NOTE]
    >

articles/active-directory/develop/scenario-protected-web-api-verification-scope-app-roles.md

@@ -52,7 +52,7 @@ But this protection isn't enough. It guarantees only that ASP.NET and ASP.NET Co
 - The *scopes* if the API is called on behalf of a user.
 - The *app roles* if the API can be called from a daemon app.
 
-## Verifying scopes in APIs called on behalf of users
+## Verify scopes in APIs called on behalf of users
 
 If a client app calls your API on behalf of a user, the API needs to request a bearer token that has specific scopes for the API. For more information, see [Code configuration | Bearer token](scenario-protected-web-api-app-configuration.md#bearer-token).
 
@@ -81,7 +81,7 @@ public class TodoListController : Controller
 The `VerifyUserHasAnyAcceptedScope` method does something like the following steps:
 
 - Verify there's a claim named `http://schemas.microsoft.com/identity/claims/scope` or `scp`.
-- Verify that the claim has a value that contains the scope expected by the API.
+- Verify the claim has a value that contains the scope expected by the API.
 
 ```csharp
     /// <summary>
@@ -113,7 +113,7 @@ The `VerifyUserHasAnyAcceptedScope` method does something like the following ste
 
 The preceding [sample code](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/blob/02352945c1c4abb895f0b700053506dcde7ed04a/Microsoft.Identity.Web/Resource/ScopesRequiredByWebAPIExtension.cs#L47) is for ASP.NET Core. For ASP.NET, just replace `HttpContext.User` with `ClaimsPrincipal.Current`, and replace the claim type `"http://schemas.microsoft.com/identity/claims/scope"` with `"scp"`. Also see the code snippet later in this article.
 
-## Verifying app roles in APIs called by daemon apps
+## Verify app roles in APIs called by daemon apps
 
 If your web API is called by a [daemon app](scenario-daemon-overview.md), that app should require an application permission to your web API. As shown in [Exposing application permissions (app roles)](https://docs.microsoft.com/azure/active-directory/develop/scenario-protected-web-api-app-registration#exposing-application-permissions-app-roles), your API exposes such permissions. One example is the `access_as_application` app role.