简单的SSO - 使用自定义身份验证 - CAS还是一些Oauth或openid服务器？

Oauth 旨在对应用程序进行身份验证，以允许它们以用户的名义执行操作。例如，Twitter客户端可以使用用户的帐户发布推文。它可以像Facebook显示的那样用于单点登录，但这需要一些额外的工作。

比较 CAS 和 OpenID

CAS 是一个具有一个帐户权限的集中式系统。OpenID是一个分布式系统，基本上任何人都可以设置身份提供者。当然，您可以将使用者限制为仅接受您自己的身份提供程序。

OpenID有两个（不兼容的）标准来提供有关帐户的其他属性，这些属性或多或少地受到公共库的支持。在标准设置中，CAS 仅提供用户名。虽然CAS在理论上确实支持属换，但目前只有PHP客户端支持它。

OpenID和CAS都可以进行自动登录。如果用户已登录，浏览器将立即重定向回您的应用程序。但是，在简单设置中，如果用户未登录，则标识提供者将显示登录页面。因此，如果您想允许匿名访问您的一方，这将需要人们单击专用的登录链接。

幸运的是，OpenID和CAS都允许透明的登录尝试。在此模式下，不显示登录表单。浏览器会立即重定向回去，无论是否包含身份验证信息。换句话说：您可以在所有新用户（没有会话）访问您的网站后立即将其重定向到身份提供商。有一个很好的图表详细解释了这一点。CAS 称之为“网关模式”，它是通过将 gateway=true 附加到登录 URL 来实现的。在OpenID中，它被称为“即时模式”，URL参数是openid.mode=checkid_immediate

CAS 支持单一注销。OpenID 不会。

我个人的经验是，CAS非常容易设置，并且非常可靠，具有适用于所有常见编程语言的高质量库。OpenID有许多微小的不兼容性，因为它是一个更复杂的系统。但是，OpenID允许使用Google帐户。

答案

首先，我不明白CAS的令牌验证的必要性，它有什么好处？

OpenID 和 CAS 都要求您让标识提供者验证提供的令牌。否则，攻击者可能能够创建自己的令牌或使用用户在注销之前创建的令牌。

客户端是否也应该使用 ssl？

是的。

在客户端，您是否会使用 iframe（如灯箱）来显示重定向的页面？为什么/为什么不呢？

全屏重定向是最简单的方法。我会从这个开始，让它工作。许多应用程序无论如何都需要在登录后重新加载当前页面，以便显示仅对登录用户可见的部分。

Iframe存在一个问题，即登录完成后您需要摆脱它。对于 CAS，有一个教程介绍如何将 CAS 登录表单直接嵌入到应用程序的 HTML 代码中。另一种选择是像Facebook Connect一样显示弹出窗口。

我可以回答一些关于CAS的问题，因为我以前用过它们。我对OAuth没有经验，因此不会对此发表评论。

首先，我不明白CAS的令牌验证的必要性，它有什么好处？

CAS 用于 SSO 目的。当您有多个应用程序（不同TLD上的桌面应用程序/Web应用程序）想要从单个源进行身份验证时，可以使用它。

它更安全吗？我注意到它是基于重定向的，因此同样容易受到中间人攻击，就像没有额外令牌验证步骤的“自定义”身份验证服务器一样。我是否缺少 CAS 中的安全性？

身份验证服务器使用 SSL 来防止 MitM 攻击。但我不明白这是SSO / CAS特有的问题，因为即使应用程序正在执行自己的身份验证，您也会遇到同样的问题。也许您可以告诉我们，使用CAS设置，您担心哪种类型的MitM攻击

令牌的目的是提供单一注销和/或超时吗？（我们不想要它，我们的用户会讨厌我们。我一直在研究CAS，因为有一些很棒的Ruby实现，但我不确定这是我们需要的。

令牌只是应用程序在没有密码的情况下对您进行身份验证的一种方式。它们是与用户凭据关联的短生存期/一次性令牌。应用程序向 CAS 服务器提供令牌，CAS 服务器使用凭据（如果有）进行回复。可以实现单一注销和超时，但不能直接与拥有令牌相关联。

我希望这很清楚。我试图让它成为一个高层次的解释。如果有任何不清楚的部分或您想要更多细节，请随时询问细节。

编辑：我发现了一个更好的解释CAS如何在 http://www.jasig.org/cas/proxy-authentication 工作（页面的其余部分讨论了代理身份验证。哪个更复杂，但前几段是我们在这里谈论的简单案例）

我转到我的门户实例。它将我重定向到 CAS 进行登录。CAS 会检测我的安全 cookie 并执行单点登录，这样我就不必再次提供我的用户名和密码。CAS 将我重定向回门户。门户验证票证，将我登录到门户，我看到我的默认布局填充了一些很酷的频道，告诉我外面真的很冷，新闻中有什么。

请注意，门户未获取我的密码。