使用CAS还是OAuth进行SSO？

Question

我在考虑单点登录应该使用CAS协议还是OAuth + 某些认证提供程序。

示例场景：

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

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

3.如果经过身份验证，则用户从SSO服务器获取令牌。

4.SSO重定向到原始应用程序。

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

6.如果令牌正确，则允许访问，并且应用程序知道用户ID。

7.用户执行注销并同时从所有连接的应用程序中注销（单点注销）。

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

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

我刚刚发现了WRAP，它可能成为OAuth的继任者。这是由Microsoft、Google和Yahoo指定的新协议。

补充说明

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

对我来说，OpenID似乎是“新的CAS”。CAS具有一些OpenID缺失的功能（如单点注销），但在特定情况下添加缺失的部分应该不难。我认为OpenID得到了广泛接受，最好将其集成到应用程序或应用程序服务器中。我知道CAS也支持OpenID，但我认为有了OpenID，CAS就可以被替代。

- deamon

---

单点登出是一种反功能。我所知道的所有用户研究都表明，对于初学者和专业用户来说，它都很容易让人感到困惑，程度从轻微到极其严重不等。我个人每天都需要使用一个采用单点登出的系统，但我觉得这非常令人恼火，因为它几乎从来不是我想要的行为。 - Bob Aman

不同意单点注销是一种反功能。这完全取决于所涉及的应用程序。对于某种程度上相关的Web应用程序，例如Google邮件和Google日历，如果您明确从其中一个登出，则注销另一个是有意义的。对于没有明显“关联”的应用程序，我同意Bob的观点。 - ashwoods

请注意，此问题最初是在OAuth 2.0发布之前提出的，因此与OAuth相关的信息可能不再准确。 - Andrew

Answer 1

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

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

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

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

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

例如，您想让您的应用程序与Twitter集成：用户可以允许其在更新数据或发布新内容时自动发送推文。你想在不获得用户密码的情况下访问某些第三方服务或资源（这对用户显然是不安全的）。应用程序请求Twitter访问权限，用户通过Twitter授权之后，应用程序可能会获得访问权限。

所以，OAuth不涉及单点登录（也不是CAS协议的替代品）。它不是关于让您控制用户可以访问什么。它是关于让用户控制第三方如何访问他们的资源。两种非常不同的用例。

针对您所描述的情况，CAS可能是正确的选择。

[更新]

也就是说，如果您将用户的身份视为受保护的资源，则可以使用OAuth实现SSO。这基本上就是“使用GitHub注册”的做法。虽然这可能不是协议最初的意图，但确实可行。如果您控制OAuth服务器并限制应用程序仅与其进行身份验证，那么这就是单点登录。

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

- tetsuo

---

虽然OAuth主要是关于授权的，但它也可以被用作中心认证服务器。就像许多网站（包括Stack Overflow）使用Google OAuth帐户进行身份验证一样，而不实际使用OAuth提供者的任何服务。 - Amir Ali Akbari

此外，正如Bertl的回复中所说，CAS现在提供OAuth作为客户端或服务器。 - Anthony O.

现在OAuth 2.0已经存在，这个回答还有参考价值吗？随着OAuth 2.0的出现，你的观点有何变化？ - Andrew

OAuth 2.0仍然是一种授权协议而不是认证协议，但人们可以在OAuth 2.0的基础上构建一个认证协议，这就是Facebook/LinkedIn等公司所做的；唯一提供认证的OAuth 2.0标准扩展是OpenID Connect，它是OpenID的指定继任者。 - Hans Z.

只是为了确保我们正在讨论什么。我们在这里谈论的是在没有“作用域”功能的情况下，我们将Oauth用于同一公司的所有微服务/资源的场景，对吗？ - Whimusical

@Whimusical 这篇答案是一段时间前写的，所以我当时还没有考虑到微服务。那时候的情境是关于多个 Web 应用程序使用单个服务器来验证用户，而不是内部微服务。我目前没有足够的知识来推荐任何关于这方面的东西，抱歉。 - tetsuo

Answer 2

我的想法是这样的：

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

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

- Lance Weber

---

OpenID 是一种身份验证协议，OAuth 是一种授权协议。 - zenw0lf

Answer 3

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

我强烈建议人们在已经有大量支持的标准上进行开发（更多可用的支持，更容易让第三方参与），即使它们不能完全符合当前应用。在这种情况下，OAuth具有较大的发展势头，而不是CAS。您应该能够使用OAuth来完成所有或至少几乎所有需要完成的工作。在将来的某个时间点，OAuth WRAP应该会进一步简化事情（它通过使用承载令牌和将加密推到协议层下面做出了一些值得的权衡），但它还处于初期阶段，与此同时，OAuth可能已经可以很好地完成工作。

最终，如果选择使用OpenID和OAuth，则会为您和任何需要与系统集成的人提供更多语言的库。您还拥有更多的眼球关注协议，确保它们真正如它们应该一样安全。

- Bob Aman

Answer 4

在我看来，SSO和OAuth之间的真正区别在于授权而不是身份验证， 因为实现OAuth的服务器显然已经具备了身份验证功能（您必须登录到您的Google、OpenID或Facebook才能让OAuth与客户端应用程序交互）。

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

我不明白为什么OAuth协议不能作为SSO服务器的一部分使用。只需从流程中去除授权屏幕，让OAuth服务器从后台数据库中查找授权即可。

- redben

Answer 5

虽然这篇文章已经有一段时间了，但是它可能会对你有所帮助：

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

- Bertl

---

对于可能感到困惑的读者，这里提到的“CAS”是指CAS服务器而不是CAS协议。 - Ng Sek Long