使用CAS或OAuth的SSO？

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

示例场景：

  1. 用户尝试访问受保护的资源，但未通过身份验证。
  2. 应用程序将用户重定向到SSO服务器。
  3. 如果通过身份验证，用户将从SSO服务器获得一个令牌。
  4. SSO重定向到原始应用程序。
  5. 原始应用程序根据SSO服务器检查令牌。
  6. 如果令牌正常，则允许访问，并且应用程序知道用户ID.
  7. 用户执行注销，并同时从所有连接的应用程序中注销（单次注销）。

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

上下文：

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

我刚刚已发现的包装，它可能成为OAuth的继任者。它是Microsoft、Google和Yahoo指定的新协议。

补遗

我了解到，OAuth并不是为身份验证而设计的，即使它可以用于实现SSO，但只能与像OpenID这样的SSO服务一起使用。

在我看来，OpenID是“新的CAS ”。CAS有一些OpenID缺失的功能（如单点登录），但在特定场景中添加缺失的部分应该不难。我认为OpenID得到了广泛的认可，最好将OpenID集成到应用程序或应用服务器中。我知道CAS也支持OpenID，但我认为CAS对于OpenID是可有可无的。

79573 次浏览
小开

OpenID是认证协议，OAuth和OAuth包装是授权协议。它们可以与混合OpenID扩展结合使用。

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

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

小开

我倾向于这样想：

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

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

小开
最佳答案

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

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

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

以上都不能处理授权（没有扩展和/或自定义）。

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

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

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

对于您所描述的环境，CAS可能是正确的选择。

[已更新]

也就是说，如果您将用户的身份视为安全资源，则可以使用OAuth实现SSO.基本上，这就是“注册GitHub ”之类的网站所做的事情。这可能不是协议的初衷，但这是可以做到的。如果您控制OAuth服务器，并限制应用程序只能使用它进行身份验证，这就是SSO.

不过，没有强制注销的标准方法（CAS具有此功能）。

小开

旧的帖子，但这可能是有用的：

CAS 3.5将支持OAuth作为客户端和服务器。 请参阅：https://wiki.jasig.org/display/CASUM/OAuth

小开

对我来说，SSO和OAuth之间的真正区别是授权，而不是身份验证。 因为实现OAuth的服务器显然有身份验证（您必须登录到您的Google、OpenID或Facebook才能使用客户端应用程序进行OAuth）。

在SSO中，高级用户/系统管理员事先在“ SSO应用程序”上授予最终用户对应用程序的访问权限。 在OAuth中，最终用户授予应用程序访问“ OAuth应用程序”

上其“数据”的权限

我不明白为什么OAuth协议不能用作SSO服务器的一部分。只需从流中取出授权屏幕，并让OAuth服务器从备份数据库中查找授权。


提交答案