Merge pull request #191690 from rwike77/screenshots

updating screenshots

Author: v-regandowner

articles/active-directory/develop/consent-framework.md

@@ -10,10 +10,10 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/21/2020
+ms.date: 03/14/2022
 ms.author: ryanwi
-ms.reviewer: zachowd, lenalepa, jesakowi
-ms.custom: has-adal-ref
+ms.reviewer: phsignor, jesakowi
+ms.custom: 
 ---
 
 # Azure Active Directory consent framework
@@ -32,17 +32,17 @@ The following steps show you how the consent experience works for both the appli
 
 1. Assume you have a web client application that needs to request specific permissions to access a resource/API. You'll learn how to do this configuration in the next section, but essentially the Azure portal is used to declare permission requests at configuration time. Like other configuration settings, they become part of the application's Azure AD registration:
 
-    ![Permissions to other applications](./media/consent-framework/permissions.png)
+    :::image type="content" source="./media/consent-framework/permissions.png" alt-text="Permissions to other applications" lightbox="./media/consent-framework/permissions.png":::
 
 1. Consider that your application’s permissions have been updated, the application is running, and a user is about to use it for the first time. First, the application needs to obtain an authorization code from Azure AD’s `/authorize` endpoint. The authorization code can then be used to acquire a new access and refresh token.
 
 1. If the user is not already authenticated, Azure AD's `/authorize` endpoint prompts the user to sign in.
 
-    ![User or administrator sign in to Azure AD](./media/consent-framework/usersignin.png)
+    :::image type="content" source="./media/consent-framework/usersignin.png" alt-text="User or administrator sign in to Azure AD":::
 
 1. After the user has signed in, Azure AD will determine if the user needs to be shown a consent page. This determination is based on whether the user (or their organization’s administrator) has already granted the application consent. If consent has not already been granted, Azure AD prompts the user for consent and displays the required permissions it needs to function. The set of permissions that are displayed in the consent dialog match the ones selected in the **Delegated permissions** in the Azure portal.
 
-    ![Shows an example of permissions displayed in the consent dialog](./media/consent-framework/consent.png)
+    :::image type="content" source="./media/consent-framework/consent.png" alt-text="Shows an example of permissions displayed in the consent dialog":::
 
 1. After the user grants consent, an authorization code is returned to your application, which is redeemed to acquire an access token and refresh token. For more information about this flow, see [OAuth 2.0 authorization code flow](v2-oauth2-auth-code-flow.md).
 
@@ -53,7 +53,7 @@ The following steps show you how the consent experience works for both the appli
    1. Go to the **API permissions** page for your application
    1. Click on the **Grant admin consent** button.
 
-      ![Grant permissions for explicit admin consent](./media/consent-framework/grant-consent.png)
+      :::image type="content" source="./media/consent-framework/grant-consent.png" alt-text="Grant permissions for explicit admin consent" lightbox="./media/consent-framework/grant-consent.png":::
 
    > [!IMPORTANT]
    > Granting explicit consent using the **Grant permissions** button is currently required for single-page applications (SPA) that use MSAL.js. Otherwise, the application fails when the access token is requested.