好坏与协议的使用有关。SAML 占有一席之地，SWT/JWT/et al 占有一席之地。SAML 规范几乎是一成不变的，而 SWT/JWT 确实处于起步阶段并不断变化。

SAML 有很多旋钮，这使得它相当复杂，这是良好安全性的敌人，但几乎每个人都以相同的方式实现它。SWT/JWT 的设计相当简单，但没有人能就单一的血腥实现标准达成一致，而且许多使用的公共库没有经过安全审查。

它还取决于令牌的签名方式以及用于签名的密钥的保护方式。共享机密往往更难保护，PKI 是一种 PITA，但其他人可能不同意。

从安全角度来看，JWT 和 SAML 令牌规范之间没有太大区别；它主要归结为支持的签名和加密算法（JWT 在这方面受到更多限制；请参阅https://datatracker.ietf.org/doc/html/draft-jones-json-web-token-10#appendix-A） .

对于这个用例，最后他们都只提供声明（以及所有必要的包袱，如过期时间、受众等）。但是，链接的站点表示 ACS 的 JWT 实施不支持加密，因此可能“不太”安全。这当然取决于您的实际用例。

SWT 令牌也是如此，它根本不支持加密。但这实际上可能不是问题，因为令牌可以通过提供机密性的安全通道（例如 HTTPS）传输。

从非安全的角度来看，可能存在非疏忽的性能差异（通常 SAML 对您的资源造成最大压力）。

归根结底，我认为这并不重要，因为这是格式的偏好。SAML 2.0 是一成不变的，但非常庞大且冗长（正如 XML 所趋向的那样）。但根据我个人的喜好，这些天来我自己的项目。我说试试 JWT 令牌，它是 JSON 格式的令牌。如果您的客户端应用程序跨越不同的平台，那么查看和处理 JSON 对象可能会容易得多。

我的客户端应用程序是

• 纯 AngularJS 应用程序
• iOS iPad 和 iPhone 应用程序
• 视窗 8 应用程式
• 安卓应用

它由一个 Web API 保护，该 API 接受授权标头令牌以及 JSON 格式的所有有效负载，因此 JWT对我来说似乎是一个合乎逻辑的选择。当您完全使用 .NET 时，为方便起见，只需使用 SAML 令牌。

当你被公然传播到纯粹的微软世界之外时：我强烈建议使用 JSON 作为一种格式，而不是任何其他可用的格式。JSON 是当今现代网络的格式，因此您也几乎可以保证这一点。

我意识到这是一个老问题，无论如何我都不是安全专家。但是，我在 Azure ACS 和令牌类型方面的经验让我得出了三个结论：

1. SAML 或多或少是开箱即用的。JWT 更加繁琐，我不得不依靠博客来让它工作。
2. SAML 和 JWT 之间的 cookie 大小相同。我的演示应用通过了大约 30 项声明；我没有看到任何可以证明 JWT 比 SAML 轻得多的断言是合理的。
3. Identity and Access Visual Studio 插件提供了一种设置本地 STS 的方法，该 STS 可能用于在开发中模拟令牌。JWT 在此工具中不是一个选项。

所以我选择了 SAML。