我正在研究适合以下客户端/服务器方案的安全设置，并且我有几个问题/注意事项想与您分享。
情况：我在不同平台上有多个客户：
- HTML 客户端（使用 jQuery/AJAX 的单页应用程序 (SPA)）
- 安卓应用
- Silverlight 客户端
- Windows 客户端
- Windows 移动客户端
大多数相应的服务器组件都基于使用 REST 的 .NET WCF（但对于某些后端，我使用的是其他协议）。
我发现ThinkTecture 的开源项目 IdentityServer v2对我的解决方案来说是一个不错且灵活的安全令牌服务 (STS)。它支持多种令牌类型、协议，并且具有高度可扩展性，如果需要，它还具有基于 ASP.NET 成员资格数据库的自包含身份提供程序 (IdP)。
客户端使用用户名/密码的基本流程如下：
- 客户端对其服务器上的资源（需要授权访问）进行未经授权的 HTTP 调用
- 由于客户端尚未经过身份验证，服务器返回 HTTP 401（未经授权），在 HTTP Location 标头中向 STS 提供地址（请参阅下面的注释）
- 客户端在 HTTP Basic Auth 标头中将其凭据提交给 STS
- STS 返回一个包含所有相关用户声明的 JWT 令牌
- 客户端现在重复第 1 步的初始请求，包括 HTTP Auth Bearer 标头中的 JWT 令牌
- 服务器验证令牌，因为它源自受信任的 STS 源，并返回请求的资源
我知道第 2 步将 HTTP 401 错误消息与通常与 HTTP 3xx 状态代码关联的 HTTP Location 标头结合起来有点不正统。我需要 401 状态代码，因为我的 jQuery/AJAX 客户端会自动处理 302 重定向消息，而没有任何机会拦截重定向。
现在，系统需要使用外部 IdP。“内部”STS 被定制为将身份验证请求转发到外部 IdP 处理声明从外部 IdP 格式到内部格式的转换。一个问题是它暗示了“密码反模式”，但目前所有系统都是内部且值得信赖的。
WS Federation 可以成为我的朋友吗？
上述基本流程适用于所有客户端，无论是否基于浏览器。但对于特定的浏览器客户端，我一直在研究联合安全方案，让 IdP/STS 为客户端提供登录机制。我使用的 STS (IdentityServer) 可以配置为与符合 WS-Federation 的 STS 结合使用。因此，令牌会自动转换为目标令牌格式（在我的例子中，例如从外部 STS 的 SAML 令牌到内部 JWT 令牌）。有了这个，我可以拥有某种 SSO 机制。
现在我的问题：
- 我描述的基本安全流程是最优的吗？
- WS-Federation 是否仅适用于浏览器客户端？
- 如果没有，它如何与我的 android 客户端一起使用？
- 在具有更多 STS 的 WS-Federation 中，以下之间的通信流程如何：客户端 - 内部 STS - 外部 STS（在 HTTP 通信、cookie 和其他方面）。