前后端分离下的用户认证
如今的网页开发，遵从前后端分离，前端注重用户层的体验，后端注重背后的数据，逻辑。这样无论对于开发还是维护都是很有益。但前后端分离，也带来了用户认证的思考。
在经过几个项目的架构设计，开发，这块有了更为系统的认识，这里总结下，欢迎批评指正。
如何进行用户认证呢?
传统方案-session,cookie
HTTP是无状态的，但随着需求的丰富，我们需要了解用户的状态，从而提供不一样的服务，由此催生了cookie和session的存在
Cookie的真面目
Cookie是通过客户端保持状态的解决方案。从定义上来说，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。
Session的真面目
Session是通过服务器来保持状态的。由于Session这个词汇包含的语义很多，因此需要在这里明确一下Session的含义。首先，我们通常都会把Session翻译成会话，因此我们可以把客户端浏览器与服务器之间一系列交互的动作称为一个Session。从这个语义出发，我们会提到Session持续的时间，会提到在Session过程中进行了什么操作等等；其次，Session指的是服务器端为客户端所开辟的存储空间，在其中保存的信息就是用于保持状态。从这个语义出发，我们则会提到往Session中存放什么内容，如何根据键值从Session中获取匹配的内容等。
我们如何利用Session,Cookie
当用户访问登录的时候，服务端创建session,生成sessionId,然后写到前端Cookie中去，在接下来的每次请求中都会带上sessionId，服务端通过sessionId拿到对应用户的身份信息。
当然比如我们实际开发使用Spring框架的话，其实创建session，写到回复Cookie中去，都会是自动的。
进步方案-JWT的出现
令牌机制对比之前的session,cookie，我认为是一种进步，对于用户认证这块，其实服务端的session是可以不要的，其实不需要任何的存储。
当用户登录成功，后端给发放一个令牌，对应的身份校验的用户信息可以直接加密封装在令牌中，服务端返回令牌给前端，前端Cookie存储令牌，而服务端是不需要任何存储的。
用户在接下来的请求中，在头部均携带令牌，服务端会在请求中去解开令牌，来判别令牌是否过期，或者是否携带令牌。
为什么是一种进步?
- 前端并不需要是浏览器
当我们使用传统方案session,cookie的时候，其实我们需要把session写到cookie中去，这样就决定了我们的前端必须是浏览器，在今天盛行的APP时代，这样是过于局限的,比如APP，其实存储介质SQLite
- 用户认证可以是独立的服务
传统方案其实束缚了用户认证这块，捆绑了API服务与用户认证，而JWT其实只是个简单的令牌但是同时又携带了关键的用户信息，所以可以单独出来一个服务，专门发放令牌。
我们现在做SSO，做第三方API继承等等会注意，其实很多授权服务都是独立的，这就是解耦，这就是进步，这也是这种方案的魅力所在。