授权码模式、Token登录认证

一、授权码

1.1 授权码模式是功能最全、最安全的，其授权过程(如获取微信用户信息)：

用户登陆第三方应用，第三方应用需要获取该用户微信的个人资料
第三方把用户链接到微信的授权页面，用户点击授权,此时微信可以确切地知道用户是同意授权了，而不是由第三方应用伪造的同意动作
用户在微信的授权页面点击授权后，微信转跳回第三方应用页面并返回授权码，这个转跳回的页面是事先微信和第三方应用商量好的
第三方应用拿到授权码后(并不是token)，可以去微信请求token，微信检查授权码是否正确，返回token
第三方应用拿到token后去微信请求用户个人资料，微信根据该token可以读出授权范围，并进行相应的授权后返回个人资料

1.2 授权码模式为什么安全

用户的点击同意动作在微信端页面，更可控，而不是在第三方应用。
授权码模式最后返回的token一定是返回给第三方应用的服务器，有些简单的客户只有前端静态页面而没有服务器，则只能通过:"简化模式"在web页面进行授权、获取token等一系列动作。

二、Token登录认证

2.1 基于Cookie/Session的认证方案

1、Cookie

Cookie的工作原理

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是。cookie指的就是在浏览器里面存储的一种数据，仅仅是浏览器实现的一种数据存储功能。cookie的保存时间，可以自己在程序中设置。如果没有设置保存时间，应该是一关闭浏览器，cookie就自动消失。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

注意：Cookie功能需要浏览器的支持。如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。不同的浏览器采用不同的方式保存Cookie。IE浏览器会以文本文件形式保存，一个文本文件保存一个Cookie。

Cookie的不可跨域名性

Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。

2、Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。

session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。对于浏览器客户端，大家都默认采用 cookie 的方式，保存这个“身份标识”。

服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安。

可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

注意：Session的使用比Cookie方便，但是过多的Session存储在服务器内存中，会对服务器造成压力。

3、 Cookie与Session的区别与联系

1、cookie数据存放在客户的浏览器上，session数据放在服务器上；
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行 COOKIE欺骗，考虑到安全应当使用session；
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE；
4、单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能超过3K；

Cookie和Session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的，上面我讲到服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie，因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用。

2.2 基于Token的认证方案

在大多数使用web API的互联网公司中，tokens是多用下处理人认证的最佳方式。以下几点特性支持程序使用Token的身份验证：

无状态、可扩展
支持移动设备
跨程序调用
安全

1、Token的起源

基于服务器的验证

HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

基于服务器的验证方式出现的弊端
（1）Session：每次认证用户发起请求时，服务器需要创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
（2）可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。（问题最突出）
（3）CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
（4）CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

2、基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器中。这种概念解决了在服务端存储信息时的许多问题。NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

3、基于Token的身份验证的过程

（1）用户通过用户名和密码发送请求。
（2）服务器端程序验证。
（3）服务器端程序返回一个带签名的token 给客户端。
（4）客户端储存token,并且每次访问API都携带Token到服务器端的。
（5）服务端验证token，校验成功则返回请求数据，校验失败则返回错误码。

4、Token的优势

无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。tokens自己hold住了用户的验证信息。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。
可扩展性
Tokens能够创建与其它程序共享权限的程序。
多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

5、关于有效期的设置

这里需要说明两个例子
一个例子是登录密码，一般要求定期改变密码，以防止泄漏，所以密码是有有效期的；
另一个例子是安全证书。SSL 安全证书都有有效期，目的是为了解决吊销的问题。
所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token 都需要设有效期。

有效期多长合适？
需要根据系统的安全需要，尽可能的短，但也不能太短。
如果用户在正常操作的过程中，Token 过期失效了，要求用户重新登录……用户体验不好
一种方案，使用 Refresh Token，它可以避免频繁的读写操作。
这种方案中，服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新Token 继续使用。这种方案中，服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。
时序图表示
使用Token和Refresh Token 的时序图
（1）登录

（2）业务请求

（3）Token过期，刷新Token

Refresh Token过期时，用户需要重新登陆。