SSO 与 CAS 还是 OAuth？
我想知道是否应该使用 CAS 协议或 OAuth + 一些身份验证提供程序进行单点登录。
示例场景：
用户尝试访问受保护的资源，但未通过身份验证。应用程序将用户重定向到 SSO 服务器。如果通过身份验证，用户会从 SSO 服务器获得一个令牌。 SSO 重定向到原始应用程序。原始应用程序根据 SSO 服务器检查令牌。如果令牌正常，则允许访问并且应用程序知道用户 ID。用户执行注销并同时从所有连接的应用程序中注销（单点注销）。
据我了解，这正是 CAS 发明的目的。 CAS 客户端必须实现 CAS 协议才能使用身份验证服务。现在我想知道在客户端（消费者）站点上使用 CAS 或 OAuth。 OAuth 是 CAS 的那部分的替代品吗？是否应该首选 OAuth 作为新的事实标准？是否有一个易于使用的（不是 Sun OpenSSO！）替代 CAS 的身份验证部分，支持不同的方法，如用户名/密码、OpenID、TLS 证书......？
语境：
不同的应用程序应该依赖于 SSO 服务器的身份验证，并且应该使用类似会话的东西。
应用程序可以是 GUI Web 应用程序或 (REST) 服务。
SSO 服务器必须提供用户 ID，这是从中央用户信息存储中获取有关用户的更多信息（如角色、电子邮件等）所必需的。
单点注销应该是可能的。
大多数客户端都是用 Java 或 PHP 编写的。
我只是 discovered WRAP，它可能成为 OAuth 的继任者。它是微软、谷歌和雅虎指定的新协议。
附录
我了解到 OAuth 不是为身份验证而设计的，即使它可以用于实现 SSO，但只能与 OpenID 等 SSO 服务一起使用。
在我看来，OpenID 是“新 CAS”。 CAS 有一些 OpenID 缺失的功能（如单点注销），但在特定场景中添加缺失的部分应该不难。我认为 OpenID 具有广泛的接受度，最好将 OpenID 集成到应用程序或应用程序服务器中。我知道 CAS 也支持 OpenID，但我认为 CAS 对 OpenID 是可有可无的。
OpenID 不是 CAS 的“继任者”或“替代者”，它们在意图和实现上是不同的。
CAS 集中认证。如果您希望所有（可能是内部的）应用程序要求用户登录到单个服务器（所有应用程序都配置为指向单个 CAS 服务器），请使用它。
OpenID 分散身份验证。如果您希望您的应用程序接受用户登录到他们想要的任何身份验证服务，请使用它（用户提供 OpenID 服务器地址 - 实际上，“用户名”是服务器的 URL）。
以上都没有处理授权（没有扩展和/或定制）。
OAuth 处理授权，但它不能替代传统的“USER_ROLES 表”（用户访问）。它处理第三方的授权。
例如，您希望您的应用程序与 Twitter 集成：用户可以允许它在更新数据或发布新内容时自动发送推文。您想代表用户访问某些第三方服务或资源，而无需获取他的密码（这对用户来说显然是不安全的）。应用程序请求 Twitter 访问，用户授权它（通过 Twitter），然后应用程序可以访问。
因此，OAuth 不是单点登录（也不是 CAS 协议的替代品）。这与您控制用户可以访问的内容无关。它是关于让用户控制第三方如何访问他们的资源。两个非常不同的用例。
根据您描述的情况，CAS 可能是正确的选择。
[更新]
也就是说，如果您将用户的身份视为安全资源，则可以使用 OAuth 实现 SSO。基本上，这就是“使用 GitHub 注册”之类的做法。可能不是协议的初衷，但可以做到。如果您控制 OAuth 服务器，并将应用程序限制为仅对其进行身份验证，那就是 SSO。
但是，没有强制注销的标准方法（CAS 具有此功能）。
我倾向于这样想：
如果您控制/拥有用户身份验证系统并且需要支持需要集中身份验证的异构服务器和应用程序集，请使用 CAS。
如果您想支持来自您不拥有/不支持的系统（即 Google、Facebook 等）的用户身份验证，请使用 OAuth。
OpenID 是身份验证协议，OAuth 和 OAuth WRAP 是授权协议。它们可以与 hybrid OpenID extension 结合使用。
我非常希望看到人们建立在具有很大动力的标准之上（更多可用的支持，更容易让第三方参与），即使他们不完全适合手头的应用程序。在这种情况下，OAuth 有动力，而不是 CAS。您应该能够使用 OAuth 完成所有或至少几乎所有需要执行的操作。在未来的某个时间点，OAuth WRAP 应该会进一步简化事情（它通过使用不记名令牌和将加密下推到协议层来做出一些有价值的权衡），但它仍处于起步阶段，与此同时，OAuth可能会很好地完成这项工作。
最终，如果您选择使用 OpenID 和 OAuth，那么您和需要与系统集成的任何其他人都可以使用更多语言的库。您还会有更多的眼球在查看协议，以确保它们确实像应有的那样安全。
对我来说，SSO 和 OAuth 之间的真正区别是授权，而不是身份验证，因为实现 OAuth 的服务器显然具有身份验证（您必须登录到您的 google、openId 或 facebook，OAuth 才能与客户端应用程序一起发生）
在 SSO 中，高级用户/系统管理员事先在“SSO 应用程序”上授予最终用户对应用程序的访问权限 在 OAuth 中，最终用户在“OAuth 应用程序”上授予应用程序对其“数据”的访问权限
我不明白为什么 OAuth 协议不能用作 SSO 服务器的一部分。只需从流程中取出授权屏幕，让 OAuth 服务器从支持数据库中查找授权。
旧帖子，但这可能有用：
CAS 3.5 将支持 oAuth 作为客户端和服务器。请参阅：https://wiki.jasig.org/display/CASUM/OAuth
CAS 是 CAS 服务器 而不是 CAS 协议。
