Merge pull request #227660 from rwike77/wifvideo

added video

Author: prmerger-automator[bot]

articles/active-directory/develop/workload-identity-federation.md

@@ -9,9 +9,9 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 10/31/2022
+ms.date: 02/16/2023
 ms.author: ryanwi
-ms.reviewer: shkhalid, udayh, vakarand
+ms.reviewer: shkhalid, udayh
 ms.custom: aaddev 
 #Customer intent: As a developer, I want to learn about workload identity federation so that I can securely access Azure AD protected resources from external apps and services without needing to manage secrets. 
 ---
@@ -23,6 +23,9 @@ You can use workload identity federation in scenarios such as GitHub Actions, wo
 
 ## Why use workload identity federation?
 
+Watch this video to learn why you would use workload identity federation.
+> [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RWXamJ]
+
 Typically, a software workload (such as an application, service, script, or container-based application) needs an identity in order to authenticate and access resources or communicate with other services.  When these workloads run on Azure, you can use [managed identities](../managed-identities-azure-resources/overview.md) and the Azure platform manages the credentials for you.  For a software workload running outside of Azure, you need to use application credentials (a secret or certificate) to access Azure AD protected resources (such as Azure, Microsoft Graph, Microsoft 365, or third-party resources).  These credentials pose a security risk and have to be stored securely and rotated regularly. You also run the risk of service downtime if the credentials expire.
 
 You use workload identity federation to configure an Azure AD app registration or [user-assigned managed identity](../managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md) to trust tokens from an external identity provider (IdP), such as GitHub.  Once that trust relationship is created, your software workload can exchange trusted tokens from the external IdP for access tokens from Microsoft identity platform.  Your software workload then uses that access token to access the Azure AD protected resources to which the workload has been granted access. This eliminates the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire.