单Duende IdentityServer对接多客户端可行性及方案咨询

完全可以通过单个Duende IdentityServer实例实现Angular和.NET Maui两类客户端的集中认证与授权，以下是针对不同客户端的适配方案及业内通用实践：

一、Angular客户端的认证方案 #

你提到的BFF模式是当前SPA场景下的安全首选，同时也有其他可选方案：

• BFF方案：部署一个基于ASP.NET Core的BFF中间层，将其配置为IdentityServer的ConfidentialClient。Angular通过Cookie与BFF通信，BFF负责和IdentityServer交互获取、刷新令牌，并将令牌附加到API请求中转发。这种方式避免了SPA直接存储令牌的安全风险，同时天然支持单点登录（SSO）。
• PKCE授权码流（无BFF）：若不想引入BFF层，可将Angular配置为IdentityServer的PublicClient，强制启用PKCE、禁用隐式流。前端用oidc-client-ts这类库处理认证流程，令牌建议存储在HttpOnly Cookie中（需配合后端代理），规避XSS攻击风险。

二、.NET Maui客户端的认证方案 #

Maui作为原生公共客户端，完全适配Duende IdentityServer的授权码流+PKCE模式，这也是原生客户端的标准安全实践：

• 在IdentityServer中注册Maui客户端：设置客户端类型为PublicClient，开启PKCE，配置对应的重定向URI（比如myapp://callback，需在Maui项目中提前配置URI关联）。
• Maui端实现认证：使用Microsoft.Identity.Client (MSAL)或Duende.AccessTokenManagement库，调用系统浏览器（而非嵌入WebView）打开IdentityServer的登录页面完成认证。登录后通过授权码交换获取访问令牌、刷新令牌，后续调用API时携带令牌即可。
• 注意：Maui无法直接嵌入IdentityServer的登录页，使用系统浏览器是符合OAuth2安全规范的做法，同时能自动利用浏览器的Cookie实现SSO（若用户已在Angular端登录，Maui认证时无需重复输入账号密码）。

三、集中认证的核心配置要点 #

1. 统一客户端注册：在单个IdentityServer实例中分别注册Angular（或BFF）、Maui两个客户端，配置各自的授权类型、允许的API范围、重定向URI等。
2. 共享用户存储：将两类客户端的用户数据统一存储到IdentityServer关联的用户系统（比如ASP.NET Core Identity），实现跨客户端的身份统一管理。
3. SSO支持：利用IdentityServer的Cookie机制，用户在任意客户端登录后，其他客户端发起认证时会自动识别登录状态，实现单点登录。

业内同类场景通用实践 #

跨Web+原生客户端的认证场景，几乎都采用单个身份提供商（IdentityProvider）+ 分客户端适配授权流的方案：

• Web SPA优先BFF模式，兼顾安全与开发体验；
• 原生客户端（Maui、iOS、Android）统一使用授权码流+PKCE，配合系统浏览器完成认证；
• 令牌生命周期管理：Maui通过MSAL自动处理令牌刷新，BFF层也可负责令牌的刷新与缓存，无需前端业务代码关心令牌细节。

内容的提问来源于stack exchange，提问作者Thimo Luijsterburg