说一说几种登陆认证方式，你用的哪种

登陆认证几乎是任何一个系统的标配，web 系统、APP、PC 客户端等，好多都须要注册、登陆、受权认证。

场景说明

以一个电商系统，假设淘宝为例，若是咱们想要下单，首先须要注册一个帐号。拥有了帐号以后，咱们须要输入用户名（好比手机号或邮箱）、密码完成登陆过程。以后若是你在一段时间内再次进入系统，是不须要输入用户名和密码的，只有在连续长时间不登陆的状况下（例如一个月没登陆过）访问系统，再次须要输入用户名和密码。若是使用频率很频繁，一般是一年都不用再输一次密码，因此常常在换了一台电脑或者一部手机以后，一些常用的网站或 APP 不记得密码了。

提炼出来整个过程大概就是以下几步：

1. 首次使用，须要经过邮箱或手机号注册；
2. 注册完成后，须要提供用户名和密码完成登陆；
3. 下次再使用，一般不会再次输入用户名和密码便可直接进入系统并使用其功能（除非连续长时间未使用）；

经常使用的认证方式

OAuth 认证

OAuth 认证比较常见的就是微信登陆、微博登陆、qq登陆等，简单来讲就是利用这些比较权威的网站或应用开放的 API 来实现用户登陆，用户能够不用在你的网站或应用上注册帐号，直接用已有的微信、微博、qq 等帐号登陆。

这同样一来，即省了用户注册的时间，又简化了你的系统的帐号体系。从而既能够提升用户注册率能够节省开发时间，同时，安全性也有了保障。

维基百科对它的解释摘要以下：

OAuth容许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每个令牌受权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户能够受权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非全部内容。

假设咱们开发了一个电商平台，并集成了微信登陆，以这个场景为例，说一下 OAuth 的工做原理。

讲以前须要了解其中涉及到的几个角色：

• 用户：即便用咱们平台的用户
• 用户终端：即最终用户使用的 APP 端或 web 端
• 应用服务器端：即咱们的服务器端
• 受权服务器端：这里就是微信处理受权请求的服务器

好的，接下来开始在咱们的电商平台web端实现微信登陆功能。微信网页受权是受权码模式（authorization code）的 OAuth 受权模式。

1. 咱们电商平台的用户过来登陆，经常使用场景是点击“微信登陆”按钮；
2. 接下来，用户终端将用户引导到微信受权页面；
3. 用户赞成受权，应用服务器重定向到以前设置好的 redirect_uri （应用服务器所在的地址），并附带上受权码（code）;
4. 应用服务器用上一步获取的 code 向微信受权服务器发送请求，获取 access_token，也就是上面说的令牌；
5. 以后应用服务器用上一步获取的 access_token 去请求微信受权服务器获取用户的基本信息，例如头像、昵称等；

Cookie-Session 认证

早期互联网以 web 为主，客户端是浏览器，因此 Cookie-Session 方式最那时候最经常使用的方式，直到如今，一些 web 网站依然用这种方式作认证。

认证过程大体以下：

1. 用户输入用户名、密码或者用短信验证码方式登陆系统；
2. 服务端验证后，建立一个 Session 信息，而且将 SessionID 存到 cookie，发送回浏览器；
3. 下次客户端再发起请求，自动带上 cookie 信息，服务端经过 cookie 获取 Session 信息进行校验；

弊端

• 只能在 web 场景下使用，若是是 APP 中，不能使用 cookie 的状况下就不能用了；
• 即便能在 web 场景下使用，也要考虑跨域问题，由于 cookie 不能跨域；
• cookie 存在 CSRF（跨站请求伪造）的风险；
• 若是是分布式服务，须要考虑 Session 同步问题；

Cookie-Session 改造版

因为传统的 Cookie-Session 认证存在诸多问题，能够把上面的方案改造一下。改动的地方以下：

• 不用 cookie 作客户端存储，改用其余方式，web 下使用 local storage，APP 中使用客户端数据库，这样就实现了跨域，而且避免了 CSRF ;
• 服务端也不存 Session 了，把 Session 信息拿出来存到 Redis 等内存数据库中，这样即提升了速度，又避免了 Session 同步问题；

通过改造以后变成了以下的认证过程：

1. 用户输入用户名、密码或者用短信验证码方式登陆系统；
2. 服务端通过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
3. 客户端拿到返回的 key，存储到 local storage 或本地数据库；
4. 下次客户端再次请求，把 key 值附加到 header 或者 请求体中；
5. 服务端根据获取的 key，到 Redis 中获取认证信息；

基于JWT的Token认证

上面的方案虽然通过了改版，但仍是须要客户端和服务器端维持一个状态信息，好比用 cookie 换 session ,或者用 key 换 Redis 的 value 信息，基于 JWT 的 Token 认证方案能够省去这个过程。

JSON Web Token（JWT）是一个很是轻巧的规范。这个规范容许咱们使用JWT在用户和服务器之间传递安全可靠的信息。

认证过程

1. 依然是用户登陆系统；
2. 服务端验证，将认证信息经过指定的算法（例如HS256）进行加密，例如对用户名和用户所属角色进行加密，加密私钥是保存在服务器端的，将加密后的结果发送给客户端，加密的字符串格式为三个"." 分隔的字符串 Token，分别对应头部、载荷与签名，头部和载荷均可以经过 base64 解码出来，签名部分不能够；
3. 客户端拿到返回的 Token，存储到 local storage 或本地数据库；
4. 下次客户端再次发起请求，将 Token 附加到 header 中；
5. 服务端获取 header 中的 Token ，经过相同的算法对 Token 中的用户名和所属角色进行相同的加密验证，若是验证结果相同，则说明这个请求是正常的，没有被篡改。这个过程能够彻底不涉及到查询 Redis 或其余存储；

优势

• 使用 json 做为数据传输，有普遍的通用型，而且体积小，便于传输；
• 不须要在服务器端保存相关信息；
• jwt 载荷部分能够存储业务相关的信息（非敏感的），例如用户信息、角色等；

总结

综上所述，JWT 能够做为首选的认证方案。固然，具体的状况具体分析，还要看是否是适合真实的应用场景。除了上述的这些，涉及到信息安全的，建议所有采用 https 方式部署，采用 https 方式，信息很难被嗅探破解，对应用的安全性很重要。

参考信息：

OAuth: http://www.ruanyifeng.com/blo...

JWT：https://jwt.io/introduction/ http://blog.leapoahead.com/20...

JWT Java 库: https://github.com/jwtk/jjwt

能够关注个人公众号