我想知道是否应该使用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的继任者 . 这是微软，谷歌和雅虎指定的新协议 .
Addendum
我了解到OAuth不是为验证而设计的，即使它可用于实现SSO，但只能与OpenID等SSO服务一起使用 .
OpenID在我看来是“新CAS” . CAS具有一些OpenID未命中功能（如单点注销），但在特定场景中添加缺失部分并不困难 . 我认为OpenID已被广泛接受，最好将OpenID集成到应用程序或应用程序服务器中 . 我知道CAS也支持OpenID，但我认为CAS对OpenID来说是可有可无的 .
5 回答
OpenID不是CAS的“后继者”或“替代者”，它们在意图和实施方面都是不同的 .
CAS centralizes 认证 . 如果您希望所有（可能是内部）应用程序要求用户登录到单个服务器（所有应用程序都配置为指向单个CAS服务器），请使用它 .
OpenID decentralizes 身份验证 . 如果您希望应用程序接受用户登录他们想要的任何身份验证服务（用户提供OpenID服务器地址 - 实际上'username'是服务器的URL），请使用它 .
以上都不处理授权（没有扩展和/或定制） .
OAuth处理授权，但它不能替代传统的“USER_ROLES表”（用户访问权限） . 它处理第三方的授权 .
例如，您希望应用程序与Twitter集成：用户可以在更新数据或发布新内容时自动发送推文 . 您希望代表用户访问某些第三方服务或资源，而无需获取其密码（这对用户来说显然是不安全的） . 该应用程序要求Twitter访问， user 授权它（通过Twitter），然后该应用程序可以访问 .
因此，OAuth不是单点登录（也不是CAS协议的替代品） . 它不是关于 you 控制用户可以访问的内容 . 它是关于让 user 控制第三方如何访问 their 资源 . 两个非常不同的用例 .
对于您描述的上下文，CAS可能是正确的选择 .
[updated]
也就是说，如果您将用户的身份视为安全资源，则可以使用OAuth实施SSO . 这就是“与GitHub注册”和基本上喜欢做的事情 . 可能不是协议的初衷，但可以做到 . 如果您控制OAuth服务器，并限制应用程序仅对其进行身份验证，那就是SSO .
但是，没有强制注销的标准方法（CAS具有此功能） .
对我来说，SSO和OAuth之间的真正区别在于授权，而不是身份验证，因为实现OAuth的服务器显然具有身份验证（您必须登录到您的google，openId或facebook才能使OAuth与客户端应用程序一起发生）
在SSO中，超级用户/系统管理员在“SSO应用程序”中授予最终用户对应用程序的访问权限 . 在OAuth中，最终用户授予应用程序对“OAuth应用程序”上的“数据”的访问权限
我不明白为什么OAuth协议不能用作SSO服务器的一部分 . 只需从流中取出授权屏幕，让OAuth服务器从支持db中查找授权 .
我倾向于想到它这条路：
如果您控制/拥有用户身份验证系统并且需要支持需要集中身份验证的异构服务器和应用程序，请使用CAS .
如果要支持来自您不拥有/支持的系统（即Google，Facebook等）的用户身份验证，请使用OAuth .
OpenID是身份验证协议，OAuth和OAuth WRAP是授权协议 . 它们可以与hybrid OpenID extension结合使用 .
我非常希望看到人们 Build 在标准之上，这些标准具有很大的动力（更多的可用支持，更容易让第三方参与），即使它们不适合手头的应用程序 . 在这种情况下，OAuth有动力，而不是CAS . 您应该能够完成所有或至少几乎所有与OAuth相关的操作 . 在未来的某个时间点，OAuth WRAP应该进一步简化事情（它通过使用承载令牌并将加密推送到协议层进行一些有 Value 的权衡），但它仍处于起步阶段，同时，OAuth可能会做得很好 .
最终，如果您选择使用OpenID和OAuth，则可以使用更多库来获取更多语言，以及需要与系统集成的任何其他人 . 您还有更多关注协议的眼球，确保它们确实像它们应该的那样安全 .
旧帖子，但这可能有用：
CAS 3.5将支持oAuth作为客户端和服务器 . 见：https://wiki.jasig.org/display/CASUM/OAuth