Updates after review

Author: hansenms

articles/healthcare-apis/fhir-app-registration.md

@@ -13,7 +13,7 @@ ms.date: 10/13/2019
 
 # Register the Azure Active Directory apps for Azure API for FHIR
 
-You have several configuration options to choose from when you're setting up the Azure API for FHIR or the FHIR Server for Azure (OSS). For open source, you will need to create your own resource application registration. For Azure API for FHIR, this resource application is created automatically.
+You have several configuration options to choose from when you're setting up the Azure API for FHIR or the FHIR Server for Azure (OSS). For open source, you'll need to create your own resource application registration. For Azure API for FHIR, this resource application is created automatically.
 
 ## Application registrations
 
@@ -22,12 +22,12 @@ In order for an application to interact with Azure AD, it needs to be registered
 1. Resource application registrations.
 1. Client application registrations.
 
-**Resource applications** are representations in Azure AD of an API or resource that is secured with Azure AD, specifically it would be the Azure API for FHIR. A resource application for Azure API for FHIR will be created automatically when you provision the service, but if you are using the open source server, you will need to [register a resource application](register-resource-azure-ad-client-app.md) in Azure AD. This resource application will have an identifier URI. It is recommended that this URI be the same as the URI of the FHIR server. This URI should then be configured as the required `Audience` for the FHIR server. A client application can request access to this FHIR server when it requests a token.
+**Resource applications** are representations in Azure AD of an API or resource that is secured with Azure AD, specifically it would be the Azure API for FHIR. A resource application for Azure API for FHIR will be created automatically when you provision the service, but if you're using the open-source server, you'll need to [register a resource application](register-resource-azure-ad-client-app.md) in Azure AD. This resource application will have an identifier URI. It's recommended that this URI be the same as the URI of the FHIR server. This URI should be used as the `Audience` for the FHIR server. A client application can request access to this FHIR server when it requests a token.
 
-*Client applications* are registrations of the clients that will be requesting tokens. Often in OAuth 2.0, we distinguish between at least 3 different types of applications:
+*Client applications* are registrations of the clients that will be requesting tokens. Often in OAuth 2.0, we distinguish between at least three different types of applications:
 
-1. **Confidential clients**, also known as web apps in Azure AD. These are clients that will use [authorization code flow](https://docs.microsoft.com/azure/active-directory/develop/v1-protocols-oauth-code) to obtain a token on behalf of a signed in user presenting valid credentials. They are called confidential clients because they are able to hold a secret and will present this secret to Azure AD when exchanging the authentication code for a token. Since confidential clients are able to authenticate themselves using the client secret, they are trusted more than public clients and can have longer lived tokens and be granted a refresh token. Read the details on how to [register a confidential client](register-confidential-azure-ad-client-app.md). Note that is important to register the reply url at which the client will be receiving the authorization code.
-1. **Public clients**. These are clients that cannot keep a secret. Typically this would be a mobile device application or a single page javascript application, where a secret in the client could be discovered by a user. Public clients also use authorization code flow, but they are not allowed to present a secret when obtaining a token and they may have shorter lived tokens and no refresh token. Read the details on how to [register a public client](register-public-azure-ad-client-app.md).
+1. **Confidential clients**, also known as web apps in Azure AD. Confidential clients are applications that use [authorization code flow](https://docs.microsoft.com/azure/active-directory/develop/v1-protocols-oauth-code) to obtain a token on behalf of a signed in user presenting valid credentials. They are called confidential clients because they are able to hold a secret and will present this secret to Azure AD when exchanging the authentication code for a token. Since confidential clients are able to authenticate themselves using the client secret, they are trusted more than public clients and can have longer lived tokens and be granted a refresh token. Read the details on how to [register a confidential client](register-confidential-azure-ad-client-app.md). Note that is important to register the reply url at which the client will be receiving the authorization code.
+1. **Public clients**. These are clients that cannot keep a secret. Typically this would be a mobile device application or a single page JavaScript application, where a secret in the client could be discovered by a user. Public clients also use authorization code flow, but they are not allowed to present a secret when obtaining a token and they may have shorter lived tokens and no refresh token. Read the details on how to [register a public client](register-public-azure-ad-client-app.md).
 1. Service clients. These clients obtain tokens on behalf of themselves (not on behalf of a user) using the [client credentials flow](https://docs.microsoft.com/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow). They typically represent applications that access the FHIR server in a non-interactive way. An example would be an ingestion process. When using a service client, it is not necessary to start the process of getting a token with a call to the `/authorize` endpoint. A service client can go straight to the `/token` endpoint and present client ID and client secret to obtain a token. Read the details on how to [register a service client](register-service-azure-ad-client-app.md)
 
 ## Next steps

articles/healthcare-apis/find-identity-object-ids.md

@@ -24,7 +24,7 @@ When you create a new Azure API for FHIR instance, you can configure a list of a
 
 These object IDs can either be IDs for specific users or service principals in your Azure Active Directory.
 
-## Find user object ID using PowerShell or Azure CLI
+## Find user object ID
 
 If you have a user with user name `[email protected]`, you can locate the users `ObjectId` using the following PowerShell command:
 
@@ -38,7 +38,7 @@ or you can use the Azure CLI:
 az ad user show --upn-or-object-id [email protected] | jq -r .objectId
 ```
 
-## Find service principal object ID using PowerShell or Azure CLI
+## Find service principal object ID
 
 Suppose you have registered a [service client app](register-service-azure-ad-client-app.md) and you would like to allow this service client to access the Azure API for FHIR, you can find the object ID for the client service principal with the following PowerShell command:
 

articles/healthcare-apis/register-confidential-azure-ad-client-app.md

@@ -48,7 +48,7 @@ Next add API permissions:
 
 3. Select appropriate resource API:
 
-    > For the Azure API for FHIR (managed service), click **APIs my organization uses** and search for "Azure Healthcare APIs".
+    For the Azure API for FHIR (managed service), click **APIs my organization uses** and search for "Azure Healthcare APIs".
 
     For the Open Source FHIR server for Azure, select your [FHIR API Resource Application Registration](register-resource-azure-ad-client-app.md):
 

articles/healthcare-apis/register-public-azure-ad-client-app.md

@@ -14,7 +14,7 @@ ms.author: mihansen
 
 In this article, you'll learn how to register a public application in Azure Active Directory.  
 
-Client application registrations are Azure Active Directory representations of applications that can authenticate and ask for API permissions on behalf of a user. Public clients are applications such as mobile applications and single page javascript applications that can't keep secrets confidential. The procedure is similar to [registering a confidential client](register-confidential-azure-ad-client-app.md), but since public clients can't be trusted to hold an application secret, there's no need to add one.
+Client application registrations are Azure Active Directory representations of applications that can authenticate and ask for API permissions on behalf of a user. Public clients are applications such as mobile applications and single page JavaScript applications that can't keep secrets confidential. The procedure is similar to [registering a confidential client](register-confidential-azure-ad-client-app.md), but since public clients can't be trusted to hold an application secret, there's no need to add one.
 
 ## App registrations in Azure portal
 
@@ -40,7 +40,7 @@ Similarly to the [confidential client application](register-confidential-azure-a
 
 1. Open the **API permissions**.
 
-    > If you are using the Azure API for FHIR, you will add a permission to the Azure Healthcare APIs by searching for Azure Healthcare APIs under **APIs my organization uses** (image below).
+    If you are using the Azure API for FHIR, you will add a permission to the Azure Healthcare APIs by searching for Azure Healthcare APIs under **APIs my organization uses** (image below).
 
     If you are referencing a different Resource Application, select your [FHIR API Resource Application Registration](register-resource-azure-ad-client-app.md) that you created previously under **My APIs**: