初识SSO与JWT

以前在学校做项目的时候，登录注销，权限验证这些事情，都是交给框架来做的，每次都是把这个架子拿到项目中去，也没有真正思考过它的过程，总觉的这些都是十分简单的逻辑。

然而来公司工作之后，慢慢觉得登录和权限虽然固定，但确实不容出错的。并且，在一个大型的公司或是多系统中，登录和权限都是抽离开来的，它们有复杂的逻辑以及高安全性，并且使得多个系统可以有一个统一登录和认证的接口。这就是今天想描述的单点登录SSO。

1. 关于SSO：

SSO是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。

它包含的核心有两点：

1）所有应用系统共享一个身份认证系统。

　　　　统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

2）所有应用系统能够识别和提取ticket信息

　　　　要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

那具体公司的SSO是怎样的原理和过程呢？

首先是我看到的一个原理图：

其实主要包含两种情况：

1. 当在统一认证处没有认证，或者本身访问子系统浏览器客户端没有cookie保存的ticket时，会进行账号密码登录的过程，登录成功便会通过回调的url返回code给子系统。这时子系统需要拿code到checkCodeUrl去拿ticket和用户信息。拿到userInfo和ticket后，可以做一些权限的调用，也可以对ticket，userInfo信息进行处理加密生成token串（这里我们用的是JWT，一会会讲到），然后讲token放入客户端的cookie中，以便下次使用。

2. 当访问子系统的浏览器有token信息时，则会通过JWT进行token串的解密，拿到userInfo和ticket，然后携带ticket去checkTicketUrl去校验ticket，而如果统一认证处保存了用户的登录信息，则认证通过。

讲完这两种情况，想贴一下我前两天看了这部分代码的画的一个逻辑草图：

这里还有一点在wiki上看到了，想记录一下：

由于所有项目都采用前后端分离设计，而前后端分离后，静态页面无法受到后端服务的权限控制。通常作法是页面请求后发ajax到后端验证，如果验证失败后后端返回跳SSO的必要数据，由前端再302到SSO登录页。但这并不符合SSO的接入标准的要求。

现在的解决方式是：

• 后端加入对根路径的请求拦截。以现在前端架构设计看，类似于http://domain/#/XXX的请求格式，其实都是对根路径的请求。

• 在nginx中加入转发规则，对根路径的请求转到后端服务器上。

• 后端接收到页面请求后先通过SSO Check，如果验证不通过，在后端直接发起重定向到SSO登录页。

2. 关于JWT

首先想比较一下传统的session认证和token的认证方式：

http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

 

基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来。

总结一下，session的认证方式，除了增加服务器压力，还会导致不好扩展，分布式环境会涉及到session同步的问题，并且还会容易受到CSRF攻击（这个我还没有细看）。

那么token的方式就显得十分轻便和灵活了。客户端负责存储token（一般用cookie作为存储方式），并在每次请求时附送上这个token值，由服务端完成校验（就是刚刚SSO的那个流程），这样一来，也为扩展提供了遍历，客户端不需要知道请求哪一台服务器。

然后关于JWT的格式，这里就不细说了，它有三段部分，并用到了Base64加密，使得信息更加安全。通过jwt工具的加密和解析可以很方便的把需要的信息存入token，满足系统需要的各个需求。

最后再说两个点吧：

　　1） 由于jwt是对称加密，是可以被解密的，所以有些极为敏感的数据还是不要放在token中为好。

　　2） jwt还支持token的过期处理和刷新等功能，但我们的系统中并没有用到，如果今后有这方面的需求，可以做一些改进吧。