使用CAS或OAuth进行SSO？

我想知道我是否应该使用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可以用于实现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是授权协议。它们可以与混合OpenID扩展结合使用。

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

最终，如果您选择使用OpenID和OAuth，则会有更多的库供您和需要与系统集成的任何其他人使用的更多语言。您还会有更多关注这些协议的内容，以确保它们确实像预期的那样安全。

对我来说，SSO和OAuth之间的真正区别是授予而不是身份验证，因为实现OAuth的服务器显然具有身份验证（您必须登录到google，openId或facebook才能在客户端应用程序中发生OAuth）

在SSO中，高级用户/ sysadmin预先授予最终用户对“ SSO应用程序”上的应用程序的访问权限。在OAuth中，最终用户授予应用程序对“ OAuth应用程序”上的“数据”的访问权限

我看不到为什么不能将OAuth协议用作SSO服务器的一部分。只需从流程中取出授权屏幕，然后让OAuth服务器从后备数据库中查找授权即可。

旧帖子，但这可能有用：

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