条件访问策略不影响 MSAL 应用程序-不要求用户重新进行身份验证
Conditional Access Policy does not affect MSAL app - user not asked to reauthenticate
Azure AD Premium 具有条件访问策略的概念。当您更改 sign-in 频率时，它不会影响访问令牌或刷新令牌的生命周期。
由于访问令牌的默认生命周期为 1 小时，无论您在 Azure 中将 sign-in 频率设置为什么，1 小时后刷新令牌都将用于获取新的访问令牌。
因此，在 Azure AD premium 中设置 sign-in 频率对默认的 msal 应用程序没有影响。
事实上，我通过执行以下简单步骤对此进行了测试：
下载 msal angular 示例，该示例使用 PKCE 的身份验证代码流 (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular)
在 Azure AD premium 中为上述应用程序的应用程序注册添加条件访问策略
确保在用户登录时应用策略（例如，通过检查企业应用程序上的登录 blade 或 what-if 工具）。
以下是条件访问策略：
下面的租户配置显示用户无法select“保持登录状态？”登录此租户中的任何应用程序时的选项。
下面是dsregcmd /status结果的相关部分。我知道 SSO 状态对条件访问策略有影响。
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : <redacted>
Device Name : <redacted>
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : YES
NgcKeyId : <redacted>
CanReset : NO
WorkplaceJoined : YES
WorkAccountCount : 2
WamDefaultSet : NO
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
我从 Microsoft 服务器团队获得了以下回复，我可以确认它是准确的，尽管不直观：
Conditional access executes based on token audiences, and we don’t
execute it for id_tokens where the token audience is a public client.
That’s why the CA policy doesn’t kick in
The reason why CA doesn’t execute for id_token for public clients is
because CA is meant to protect data from the cloud, and having an
id_token from a public client doesn’t grant access to any data from
the cloud.
It’s about the data that could be accessed in their request.
They can try few other options:
They can change their policy to apply to “All apps”, then SIF (Sign In
Frequency) will kick in. E.g. They can try to set the policy on
Exchange Online, and request mail.read scope Another example: They can
try to set the policy for Sharepoint Online, and request files.read
scope
So, we will apply the conditional access policy if the conditions are
met, but only for tokens that could access data in the cloud.
我更改了条件访问策略以应用于“所有应用”，而不仅仅是 msal 应用的应用注册。 MSAL 应用确实正确地拒绝了刷新令牌并在 1 小时后重定向。我没有尝试其他示例，但考虑到什么会触发 SIF 启动，它们似乎也是有效的解决方法。
Azure AD Premium 具有条件访问策略的概念。当您更改 sign-in 频率时，它不会影响访问令牌或刷新令牌的生命周期。 由于访问令牌的默认生命周期为 1 小时，无论您在 Azure 中将 sign-in 频率设置为什么，1 小时后刷新令牌都将用于获取新的访问令牌。 因此，在 Azure AD premium 中设置 sign-in 频率对默认的 msal 应用程序没有影响。
事实上，我通过执行以下简单步骤对此进行了测试：
下载 msal angular 示例，该示例使用 PKCE 的身份验证代码流 (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular) 在 Azure AD premium 中为上述应用程序的应用程序注册添加条件访问策略 确保在用户登录时应用策略（例如，通过检查企业应用程序上的登录 blade 或 what-if 工具）。
以下是条件访问策略：
下面的租户配置显示用户无法select“保持登录状态？”登录此租户中的任何应用程序时的选项。
下面是dsregcmd /status结果的相关部分。我知道 SSO 状态对条件访问策略有影响。
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : <redacted>
Device Name : <redacted>
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : YES
NgcKeyId : <redacted>
CanReset : NO
WorkplaceJoined : YES
WorkAccountCount : 2
WamDefaultSet : NO
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
我从 Microsoft 服务器团队获得了以下回复，我可以确认它是准确的，尽管不直观：
Conditional access executes based on token audiences, and we don’t execute it for id_tokens where the token audience is a public client.
That’s why the CA policy doesn’t kick in
The reason why CA doesn’t execute for id_token for public clients is because CA is meant to protect data from the cloud, and having an id_token from a public client doesn’t grant access to any data from the cloud.
It’s about the data that could be accessed in their request.
They can try few other options:
They can change their policy to apply to “All apps”, then SIF (Sign In Frequency) will kick in. E.g. They can try to set the policy on Exchange Online, and request mail.read scope Another example: They can try to set the policy for Sharepoint Online, and request files.read scope
So, we will apply the conditional access policy if the conditions are met, but only for tokens that could access data in the cloud.
我更改了条件访问策略以应用于“所有应用”，而不仅仅是 msal 应用的应用注册。 MSAL 应用确实正确地拒绝了刷新令牌并在 1 小时后重定向。我没有尝试其他示例，但考虑到什么会触发 SIF 启动，它们似乎也是有效的解决方法。