cas 登录之后不跳转_信息安全中单点登录的应用

单点登录如何解决身份认证问题？

那么单点登录（Single Sign On，SSO）到底是什么呢？单点登录的概念很简单：用户只需要进行一次认证，就可以访问所有的网页、应用和其他产品了。随着互联网产品形式的不断发展，单点登录的实现方式也经历了多次的升级革新。下面我为你介绍几种典型的单点登录方式，它们分别是：CAS 流程、JWT、OAuth 和 OpenID。

第一个要讲的是 CAS（Central Authentication Service，集中式认证服务）流程。

CAS 是一个开源的单点登录框架，它不属于某一种单点登录的实现方式，而是提供了一整套完整的落地方案。整体的流程如下图所示，具体步骤我会通过访问极客时间 App 的例子来为你详细讲解。

1. 假如用户现在要访问某个应用，比如知乎APP。
2. 应用需要进行认证，但应用本身不具备认证功能。因此，应用将用户重定向至认证中心的页面。比如，你在登录一个应用的时候，它显示你可以选择微信、QQ、微博账号进行登录，你点击微信登录，就跳转至微信的登录页面了。
3. 用户在认证中心页面进行认证操作。如果用户之前已经在其他应用进行过认证了，那么认证中心可以直接识别用户身份，免去用户再次认证的过程。
4. 认证完成后，认证中心将认证的凭据，有时会加上用户的一些信息，一起返回给客户端。也就是你在微信登录完成后，回到了极客时间 App。
5. 客户端将凭据和其他信息发送给应用，也就是说，极客时间 App 将微信的登录凭据发送给了极客时间后端。
6. 应用收到凭据后，可以通过签名的方式，验证凭据的有效性。或者，应用也可以直接和认证中心通信，验证凭据并获取用户信息。这也就是为什么极客时间能够拿到你的微信头像了。用户完成认证。

CAS 的流程非常经典，你现在应该理解了吧？我们后面要讲的 3 种单点登录方式，都和 CAS 的流程相似，说它们是 CAS 的“衍生品”也不为过。所以说，你一定要先掌握了 CAS 流程，然后再来看下面这 3 种。

JWT（JSON Web Token）是一种非常轻量级的单点登录流程。它会在客户端保存一个凭证信息，之后在你每一次登录的请求中都带上这个凭证，将其作为登录状态的依据。JWT 的好处在于，不需要应用服务端去额外维护 Cookie 或者 Session 了。但是，正是因为它将登录状态落到了客户端，所以我们无法进行注销等操作了。

OAuth（Open Authorization）的主要特点是授权，也是我们通常用 QQ、微信登录其他应用时所采用的协议。通过 OAuth，用户在完成了认证中心的登录之后，应用只能够验证用户确实在第三方登录了。但是，想要维持应用内的登录状态，应用还是得颁发自己的登录凭证。这也就是为什么 QQ 授权后，应用还需要绑定你的手机号码。这也就意味着，应用是基于 QQ 的信息创建了一个自身的账号。

OpenID（Open Identity Document）和 OAuth 的功能基本一致。但是，OpenID 不提供授权的功能。最常见的，当我们需要在应用中使用微信支付的时候，应用只需要收集支付相关的信息即可，并不需要获取用户的微信头像。

在实际情况中，基于各种业务需求的考虑，很多公司都倾向于自己去实现一套 SSO 的认证体系，它的认证流程如下图所示：

在这个流程中，应用的服务器直接接收用户的认证信息，并转发给认证中心。对用户来说，这个认证中心是完全透明的。但是，这个流程给予了应用过多的信任，从安全性方面考量的话，是不合理的。在这个过程中，应用直接获取到了用户的认证信息，但应用能否保护好这些信息呢？我们并没有有效的办法去做确认。

因此，我的建议是，多花一些功夫去接入成熟的单点登录体系，而不是自己去实现一个简化版的。JWT 适用范围广，在单点登录的选取上面，如果想要将用户信息做统一管理，选择它最为简单；如果认证中心只是被用来维护账号密码，由业务去维护用户所绑定的其他手机等信息，那么，采用 OAuth 更合适。

写在最后：

有些公司是这样的情况：应用服务和中间件（这两个以下简称服务）部署在公司的机房里，服务通过nginx对外暴露。nginx在机器A上，其余服务在机器B~N，公司的安全人员要扫描所有机器上的应用。个人感觉如果机器B~N上做好防火墙设置，只需要关系机器A上的安全问题就可以了，机器B~N不对外暴露，觉得在应用服务层面就没有安全问题了。

实际上这么做，一定程度上能缓解安全问题。比如nginx如果只暴露80端口，那么B~N的漏洞则主要集中在Web漏洞上。但是，内网并不是绝对安全的，通过Web漏洞，也可以实现内网穿透，访问内网的其他服务。如果你的防火墙只是做在A和BN之间，那么对于这种横向渗透，就起不到防御作用了。

我们现在已经越来越习惯用这种通过微信/微博或者其他CAS来认证登陆的场景了，那在CAS完成认证过程后，登陆凭据是如何从CAS服务器转移到欲登陆的APP中的呢。我们知道Cookie等内容都是严格遵循浏览器的同源策略的，就算使用30X跳转，设置的Cookie也只能存在CAS域名内。实际上跳转使用的的是类似在Reloacation的URL后面跟上认证凭证跳转实现的。不过在网页中，一般是会生成一个form表单，表单的内容就是各种凭证，然后提交的时候，相当于以POST请求跳转到新页面，这样传递信息的长度也不受限制。具体可以看一下，SAML，网页时代比较流行的单点登录机制。