Security 使用CAS或OAuth的SSO？

我想知道我是否应该使用协议或某种身份验证提供程序进行单点登录

示例场景：

用户试图访问受保护的资源，但未经过身份验证

应用程序将用户重定向到SSO服务器

如果Being已通过身份验证，则用户将从SSO服务器获取令牌

SSO将重定向到原始应用程序

原始应用程序根据SSO服务器检查令牌

如果令牌正常，将允许访问，并且应用程序知道用户id

用户执行注销并同时从所有连接的应用程序注销（单次注销）

据我所知，这正是CAS发明的目的。CAS客户端必须实现CAS协议才能使用身份验证服务。现在我想知道如何在客户（消费者）站点上使用CAS或OAuth。OAuth是CAS的替代品吗？OAuth作为一个新的事实标准是否应该被优先考虑？CAS的身份验证部分是否有易于使用（不是Sun OpenSSO！）的替代品，支持不同的方法，如用户名/密码、OpenID、TLS证书

背景：

• 不同的应用程序应该依赖于SSO服务器的身份验证，并且应该使用类似于会话的东西
• 应用程序可以是GUI web应用程序或（REST）服务
• SSO服务器必须提供用户id，这是从中央用户信息存储获取有关用户的更多信息（如角色、电子邮件等）所必需的
• 单点注销应该是可能的
• 大多数客户端都是用Java或PHP编写的

我刚刚，它可能成为OAuth的继承人。这是微软、谷歌和雅虎指定的新协议

附录

我了解到OAuth不是为身份验证而设计的，即使它可以用于实现SSO，但只能与类似OpenID的SSO服务结合使用

在我看来，OpenID是“新的CA”。CAS有一些OpenID未命中的特性（如单点注销），但在特定场景中添加未命中的部分并不难。我认为OpenID已被广泛接受，最好将OpenID集成到应用程序或应用服务器中。我知道CAS也支持OpenID，但我认为CAS与OpenID是不必要的。

是一种身份验证协议，也是授权协议。它们可以结合在一起

我强烈希望看到人们建立在具有强大动力的标准之上（更多可用的支持，更容易让第三方参与），即使他们并不完全适合手头的应用程序。在这种情况下，OAuth具有动量，而不是CAS。您应该能够使用OAuth完成所有或至少几乎所有需要完成的工作。在将来的某个时候，OAuth WRAP应该进一步简化事情（它通过使用承载令牌和将加密向下推到协议层来进行一些有价值的权衡），但它仍处于初级阶段，同时，OAuth可能会很好地完成这项工作

---

最终，如果您选择使用OpenID和OAuth，您和任何需要与系统集成的人都可以使用更多语言库。你也有更多的眼球关注协议，确保它们真的像预期的那样安全。

我倾向于这样想：

如果您控制/拥有用户身份验证系统，并且需要支持需要集中身份验证的一组异构服务器和应用程序，请使用CAS

---

如果您想支持来自您不拥有/不支持的系统（如Google、Facebook等）的用户身份验证，请使用OAuth。

OpenID不是CAS的“继承者”或“替代者”，它们在意图和实现上都不同

CAS集中化身份验证。如果您希望所有（可能是内部）应用程序要求用户登录到单个服务器（所有应用程序都配置为指向单个CAS服务器），请使用它

OpenID分散身份验证。如果您希望您的应用程序接受用户登录到他们想要的任何身份验证服务（用户提供OpenID服务器地址-事实上，“用户名”是服务器的URL），请使用它

上述任何一项都不能处理授权（无扩展和/或自定义）

OAuth处理授权，但它不能替代传统的“用户角色表”（用户访问）。它为第三方处理授权

例如，您希望您的应用程序与Twitter集成：用户可以允许它在更新数据或发布新内容时自动发布Twitter。您希望代表用户访问某些第三方服务或资源，而不获取其密码（这对用户来说显然是不安全的）。应用程序请求Twitter访问，用户授权它（通过Twitter），然后应用程序可以访问

因此，OAuth不是单点登录（也不是CAS协议的替代品）。它不是关于你控制用户可以访问的内容。它是让用户控制第三方如何访问他们的资源。两个非常不同的用例

根据您描述的上下文，CAS可能是正确的选择

[更新]

，如果您将用户的身份视为安全资源，可以使用OAuthe实现SSO。基本上，这就是“注册GitHub”和类似网站所做的。可能不是协议的初衷，但它是可以做到的。如果您控制OAuth服务器，并将应用程序限制为仅通过它进行身份验证，那么这就是SSO

---

虽然没有强制注销的标准方法（CAS具有此功能）。

旧帖子，但这可能有用：

CAS 3.5将支持oAuth