什么是OAuth
OAuth是一个关于授权（authorization）的开放网络协议，在全世界得到广泛应用，目前的版本是2.0版。
OAuth是一种安全的授权框架，提供了一套详细的授权机制。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。它详细描述了系统中不同角色、用户、服务前端应用（比如API），以及客户端（比如网站或移动App）之间怎么实现相互认证。
Oauth2定义了一组相当复杂的规范。涉及到：Roles角色、Client Types客户端类型、Client Profile客户端描述、Authorization Grants认证授权、Endpoints终端等。
OAuth2.0中最经典最常用的一种授权模式：授权码模式。此模式和JWT标准特别像
关于OAuth更详尽的了解，请参考阮一峰老师的一篇文章：理解OAuth 2.0
什么是JWT
提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。
JWT是一种安全标准。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。
详解JWT
Json web token（JWT）是为了网络应用环境间传递声明而执行的一种基于JSON的开发标准（RFC 7519），该token被设计为紧凑且安全的，特别适用于分布式站点的单点登陆（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
基于session认证所显露的问题
1、Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大
2、扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性
3、CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击
JWT的构成
JWT是由三部分构成（用.分隔），将这三段信息文本用链接构成了JWT字符串。就像这样
xxxxx.yyyyy.zzzzz
第一部分：头部（header）
第二部分：载荷（payload，该token里携带的有效信息。比如用户id、名字、年龄等等）
第三部分：签名（signature）
header
JWT的头部承载的两部分信息：
{ 'typ':'JWT', //声明类型，这里是jwt 'alg':'HS256' //声明加密的算法，通常直接使用HMAC SHA256或RSA }
Header部分的JSON被Base64Url编码，形成JWT的第一部分。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
plyload
这里放声明内容，可以说就是存放沟通讯息的地方，在定义上有3种声明（Claims）：
Registered claims（注册声明）:
这些是一组预先定义的声明，它们不是强制性的，但推荐使用，以提供一组有用的，可互操作的声明。 其中一些是：iss（发行者），exp（到期时间），sub（主题），aud（受众）等。
Public claims（公开声明）:
这些可以由使用JWT的人员随意定义。 但为避免冲突，应在IANA JSON Web令牌注册表中定义它们，或将其定义为包含防冲突命名空间的URI。
Private claims（私有声明）:
这些是为了同意使用它们但是既没有登记，也没有公开声明的各方之间共享信息，而创建的定制声明。
示例（这里存放的即使一个用户的信息，没有到期时间、主题之类的声明）：
{ "sub": "1234567890", "name": "Demo", "admin": true }
Playload部分的JSON被Base64Url编码，形成JWT的第二部分。
请注意，对于已签名的令牌，此信息尽管受到篡改保护，但任何人都可以阅读。 除非加密，否则不要将秘密信息放在JWT的有效内容或标题元素中。第二部分不要放置敏感数据如银行卡帐号、身份证号等信息。一般存放用户ID、名字、是否管理员、拥有的权限等信息
Signature
第三部分signature用来验证发送请求者身份，由前两部分加密形成。
要创建签名部分，您必须采用编码标头，编码有效载荷，秘钥，标头中指定的算法并签名。
如果你想使用HMAC SHA256算法，签名将按照以下方式创建：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload) + "." + secret)
此secret存在于你的服务器端，打死都不要告诉任何人，否则就泄密了。
JWTs作为OAuth2.0关于Access_Token的具体解决方案， 为RFC 7519提出，但是后面又有个RFC 6750定义了Bearer Token，就是设置请求头:
Authorization: Bearer <token>
JWT常见问题
性能： 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
1.JWT 安全嗎?
Base64编码方式是可逆的，也就是透过编码后发放的Token内容是可以被解析的。一般而言，我们都不建议在有效载荷内放敏感讯息，比如使用者的密码。
2.JWT Payload 內容可以被伪造嗎？
JWT其中的一个组成内容为Signature，可以防止通过Base64可逆方法回推有效载荷内容并将其修改。因为Signature是经由Header跟Payload一起Base64组成的。
3.如果我的 Cookie 被窃取了，那不就表示第三方可以做 CSRF 攻击?
是的，Cookie丢失，就表示身份就可以被伪造。故官方建议的使用方式是存放在LocalStorage中，并放在请求头中发送。 但是放在LocalStorage中，退出浏览器后又得重新登录了，有利有弊吧
4.空间及长度问题？
JWT Token通常长度不会太小，特别是Stateless JWT Token，把所有的数据都编在Token里，很快的就会超过Cookie的大小（4K）或者是URL长度限制。
因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。（如果token是用cookie保存，CSRF还是需要考虑,一般建议使用1、在HTTP请求中以参数的形式加入一个服务器端产生的token。或者2.放入http请求头中也就是一次性给所有该类请求加上csrftoken这个HTTP头属性，并把token值放入其中）
建议：
1、不要存放敏感信息在Token里。
2、Payload中的exp时效不要设定太长。
3、开启Only Http预防XSS攻击。
4、在你的应用程序应用层中增加黑名单机制，必要的时候可以进行Block做阻挡（这是针对掉令牌被第三方使用窃取的手动防御）。
