我有一个应用程序，用户将使用 Entra(Azure AD) 的 AddMsalAuthentication 登录，这工作正常。在应用程序的某些页面上，用户将使用 oidc 对我们的帮助台进行身份验证，获取身份验证令牌，以便可以进行 API 调用。
我通过实现自己的 AuthorizeView、AuthenticationStateProvider 和 RemoteAuthenticatorView 来实现这项工作，这似乎可以工作，但我怀疑我是否应该这样做。我担心这方面的安全性，并且我一直在对此进行更多研究，看看是否可以在 program.cs 中使用 AddOidcAuthentication，但看起来不是这样。
我想也许我可以构建另一个 blazor wasm 应用程序，用户可以导航到该应用程序，然后我可以使用 AddOidcAuthentication 来管理身份验证和令牌刷新。我觉得这会很笨拙，而且也可能是错误的方向。
实现自定义
AuthorizeViewAuthenticationStateProviderRemoteAuthenticatorView关于创建一个单独的 Blazor wasm 应用程序来处理帮助台系统的 OIDC 身份验证的想法，它有其优点和缺点。首先，它将使身份验证流程变得简单，因为您将使用不同的应用程序进行分离。另一个优点是两个应用程序都可以处理自己的配置，而不会干扰其他身份验证。缺点是用户可能会发现用于身份验证的应用程序之间的导航笨拙或令人困惑。在两个应用程序之间管理会话和令牌可能很困难。
在我看来，创建另一个 Blazor WASM 应用程序来处理帮助台的 OIDC 身份验证可能确实会感觉很笨重，并且可能会带来额外的复杂性，而不一定会提高安全性或用户体验。
作为替代方法，您可以使用 Azure AD 作为与帮助台的 OIDC 提供商联合的集中式身份提供商。实施 API 网关或自定义 STS，以处理 Azure AD 和帮助台 OIDC 的身份验证。
更简化的方法将涉及最大限度地减少用户需要浏览的不同身份验证流程的数量，并尽可能集中身份验证逻辑。这可能意味着通过 Azure AD 联合您的 OIDC 提供商或实施一项从您的 Blazor 应用程序中提取这些详细信息的服务。考虑使用现有的库、模式和实践来安全地管理用户身份验证和会话管理。