Merge pull request #108077 from miguel-s-ferreira/patch-20

Standardize the usage of references

Author: Court72

articles/active-directory/develop/application-model.md

@@ -28,9 +28,9 @@ For an identity provider to know that a user has access to a particular app, bot
 * Decide if you want to allow users to sign in only if they belong to your organization. This architecture is known as a single-tenant application. Or, you can allow users to sign in by using any work or school account, which is known as a multi-tenant application. You can also allow personal Microsoft accounts or a social account from LinkedIn, Google, and so on.
 * Request scope permissions. For example, you can request the "user.read" scope, which grants permission to read the profile of the signed-in user.
 * Define scopes that define access to your web API. Typically, when an app wants to access your API, it will need to request permissions to the scopes you define.
-* Share a secret with the Microsoft identity platform that proves the app's identity. Using a secret is relevant in the case where the app is a confidential client application. A confidential client application is an application that can hold credentials securely. A trusted back-end server is required to store the credentials.
+* Share a secret with the Microsoft identity platform that proves the app's identity. Using a secret is relevant in the case where the app is a confidential client application. A confidential [client application](developer-glossary.md#client-application) is an application that can hold credentials securely, like a [web client](developer-glossary.md#web-client). A trusted back-end server is required to store the credentials.
 
-After the app is registered, it's given a unique identifier that it shares with the Microsoft identity platform when it requests tokens. If the app is a [confidential client application](developer-glossary.md#client-application), it will also share the secret or the public key depending on whether certificates or secrets were used.
+After the app is registered, it's given a unique identifier that it shares with the Microsoft identity platform when it requests tokens. If the app is a confidential client application, it will also share the secret or the public key depending on whether certificates or secrets were used.
 
 The Microsoft identity platform represents applications by using a model that fulfills two main functions:
 
@@ -44,14 +44,14 @@ The Microsoft identity platform:
 * Provides infrastructure for implementing app provisioning within the app developer's tenant, and to any other Azure AD tenant.
 * Handles user consent during token request time and facilitates the dynamic provisioning of apps across tenants.
 
-*Consent* is the process of a resource owner granting authorization for a client application to access protected resources, under specific permissions, on behalf of the resource owner. The Microsoft identity platform enables:
+[*Consent*](developer-glossary.md#consent) is the process of a resource owner granting authorization for a client application to access protected resources, under specific permissions, on behalf of the resource owner. The Microsoft identity platform enables:
 
 * Users and administrators to dynamically grant or deny consent for the app to access resources on their behalf.
 * Administrators to ultimately decide what apps are allowed to do and which users can use specific apps, and how the directory resources are accessed.
 
 ## Multi-tenant apps
 
-In the Microsoft identity platform, an [application object](developer-glossary.md#application-object) describes an application. At deployment time, the Microsoft identity platform uses the application object as a blueprint to create a [service principal](developer-glossary.md#service-principal-object), which represents a concrete instance of an application within a directory or tenant. The service principal defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. The Microsoft identity platform creates a service principal from an application object through [consent](developer-glossary.md#consent).
+In the Microsoft identity platform, an [application object](developer-glossary.md#application-object) describes an application. At deployment time, the Microsoft identity platform uses the application object as a blueprint to create a [service principal](developer-glossary.md#service-principal-object), which represents a concrete instance of an application within a directory or tenant. The service principal defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. The Microsoft identity platform creates a service principal from an application object through consent.
 
 The following diagram shows a simplified Microsoft identity platform provisioning flow driven by consent. It shows two tenants: *A* and *B*.