引述：
相信很多朋友和我一样对于现在的登录认证机制都有了一定的认识，并且已经在实施了.我目前接触到的安全认证是基于Spring Security Oauth2.0。
Oauth2.0的介绍网上有很多的文章，相信有的小伙伴已经看过了，甚至连源码都了解过了``。我今天说的是在Oauth之上的Token和JWT目前的主流认证模式中，都是用户输入用户名和密码进行登录：
{ loginName: "xxx", password: "xxxxxxx" }
类似这样的机制，在我经历过的登录验证中，我们的处理办法是用户登录在本地用户接口认证成功后调用Oauth认证服务器去进行二次验证并携带基本的client_id和grant_type等必要信息
这是Oauth的一种授权模式，这样的流程在成功之后我们可以拿到一个基本的token（基于JWT编码的）
类似这样的返回机制：
{ access_token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsibWFydmVsLW9wZW4tYXBpIiwibWFydmVsLXZpZGVvLW1vbml0b3IiLCJtYXJ2ZWwtc3ViaXRlbS1zZXJ2ZXIiLCJtYXJ2ZWwtZ3VpZC1zZXJ2ZXIiLCJtYXJ2ZWwtaHItc2VydmVyIiwibWFydmVsLXByb2plY3Qtc2VydmVyIiwibWFydmVsLWF1dGgtc2VydmVyIiwibWFydmVsLXNjcmVlbi1zZXJ2ZXIiLCJtYXJ2ZWwtY29zdC1wYXJlbnQiLCJtYXJ2ZWwtc3VwZXJ2aXNpb24taW5zcGVjdGlvbiIsIm1hcnZlbC1taWRkbGUtc2VydmVyIiwibWFydmVsLXR1bm5lbC1wcm9ncmVzcyIsIm1hcnZlbC1lbmdpbmVlcmluZy1zZXJ2ZXIiLCJtYXJ2ZWwtbWVzc2FnZS1zZXJ2ZXIiXSwiZXhwIjoxNjI3NTc0MTA4LCJ1c2VyX25hbWUiOiJhZG1pbiIsImp0aSI6ImFjODg1ZDJiLWRhMTItNGI3Ni1hZjJjLWEzOWFhYjFlNWQ5ZCIsImNsaWVudF9pZCI6Im1pZGRsZSIsInNjb3BlIjpbInJlYWQiLCJ3cml0ZSJdfQ.aYhu0-J6XzNOzNRNdP5yJJqSXIsgZFABxyLZt2VBNjc" expires_in: 26780 jti: "ac885d2b-da12-4b76-af2c-a39aab1e5d9d" refresh_token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsibWFydmVsLW9wZW4tYXBpIiwibWFydmVsLXZpZGVvLW1vbml0b3IiLCJtYXJ2ZWwtc3ViaXRlbS1zZXJ2ZXIiLCJtYXJ2ZWwtZ3VpZC1zZXJ2ZXIiLCJtYXJ2ZWwtaHItc2VydmVyIiwibWFydmVsLXByb2plY3Qtc2VydmVyIiwibWFydmVsLWF1dGgtc2VydmVyIiwibWFydmVsLXNjcmVlbi1zZXJ2ZXIiLCJtYXJ2ZWwtY29zdC1wYXJlbnQiLCJtYXJ2ZWwtc3VwZXJ2aXNpb24taW5zcGVjdGlvbiIsIm1hcnZlbC1taWRkbGUtc2VydmVyIiwibWFydmVsLXR1bm5lbC1wcm9ncmVzcyIsIm1hcnZlbC1lbmdpbmVlcmluZy1zZXJ2ZXIiLCJtYXJ2ZWwtbWVzc2FnZS1zZXJ2ZXIiXSwidXNlcl9uYW1lIjoiYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiYXRpIjoiYWM4ODVkMmItZGExMi00Yjc2LWFmMmMtYTM5YWFiMWU1ZDlkIiwiZXhwIjoxNjI5MTY2MTA4LCJqdGkiOiI1YzM1MjQ4OS03ZWEzLTRmMDgtOWExMy03Y2M2MDI2ODhjMDgiLCJjbGllbnRfaWQiOiJtaWRkbGUifQ.uGaynDuGOe8Mh4dOxKAjeUwT_sh1I81_E-UY0UtSGlY" scope: "read write" token_type: "bearer" }
这是一个标准的JWT返回格式的授权Token，
在拿到token后可以放到jwt.io中去解析他的token值
{ "aud": [ "marvel-open-api", "marvel-video-monitor", "marvel-subitem-server", "marvel-guid-server", "marvel-hr-server", "marvel-project-server", "marvel-auth-server", "marvel-screen-server", "marvel-cost-parent", "marvel-supervision-inspection", "marvel-middle-server", "marvel-tunnel-progress", "marvel-engineering-server", "marvel-message-server" ], "exp": 1627574108, "user_name": "admin", "jti": "ac885d2b-da12-4b76-af2c-a39aab1e5d9d", "client_id": "middle", "scope": [ "read", "write" ] }
这是我们解析后得到的值
上面的aud是后端的微服务，每个服务都有各自唯一标识，通过Oauth认证服务器颁发，有了该标识代表用户请求具体服务时经过网关转发后不会抛出401。
这是我目前的使用Jwt的主要流程，但是很多人估计和我一样完全对于JWT很陌生，只知道他用来编码封装token的，对于他没有去了解，那么我们一起来看看
JWT描述：
1、JWT简介：
JSON Web Token（JWT）是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519)，它定义了一种紧凑（Compact）且自包含（Self-contained）的方式，用于在各方之间以JSON对象安全传输信息。 这些信息可以通过数字签名进行验证和信任。 可以使用秘密（使用HMAC算法）或使用RSA的公钥/私钥对对JWT进行签名。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。是目前最流行的跨域认证解决方案。
Compact（紧凑）： 由于它们尺寸较小，JWT可以通过URL，POST参数或HTTP标头内发送。 另外，尺寸越小意味着传输速度越快。
Self-contained（自包含）: 有效载荷（Playload）包含有关用户的所有必需信息，避免了多次查询数据库。
一个签名的JWT被称为JWS (JSON Web签名)。 事实上，JWT本身并不存在——它必须是JWS或JWE (JSON Web加密)。 它就像一个抽象类——JWS和JWE是具体的实现。
感兴趣的深入JWS和JWE的可以阅读此文章：https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
2、JWT应用场景：
Authentication（鉴权）： 这是使用JWT最常见的情况。 一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。 单点登录是当今广泛使用JWT的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。
分布式站点的单点登录（SSO）
Information Exchange（信息交换）： JSON Web Tokens是在各方之间安全传输信息的好方式。 因为JWT可以签名：例如使用公钥/私钥对，所以可以确定发件人是他们自称的人。 此外，由于使用标头和有效载荷计算签名，因此您还可以验证内容是否未被篡改。
3、JWT组成：
jwt有3个组成部分，每部分通过点号来分割 header.payload.signature
头部（header) 是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子
载荷（payload) 是一个 JSON 对象，用来存放实际需要传递的数据
签证（signature) 对header和payload使用密钥进行签名，防止数据篡改。
① 头部header
Jwt的头部是一个JSON,然后使用Base64URL编码，承载两部分信息：
声明类型typ，表示这个令牌（token）的类型（type），JWT令牌统一写为JWT
声明加密的算法alg，通常直接使用HMACSHA256，就是HS256了，也可以使用RSA,支持很多算法(HS256、HS384、HS512、RS256、RS384、RS512、ES256、ES384、ES512、PS256、PS384)
var header = Base64URL({ "alg": "HS256", "typ": "JWT"})
Base64URL：Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。
② 载荷payload
payload也是一个JSON字符串，是承载消息具体内容的地方，也需要使用Base64URL编码，payload中可以包含预定义的7个可用，它们不是强制性的，但推荐使用，也可以添加任意自定义的key
iss(issuer): jwt签发者
sub(subject): jwt所面向的用户
aud(audience): 接收jwt的一方, 受众
exp(expiration time): jwt的过期时间，这个过期时间必须要大于签发时间
nbf(Not Before): 生效时间，定义在什么时间之前.
iat(Issued At): jwt的签发时间
jti(JWT ID): jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
// 该token签发给1234567890，姓名为John Doe(自定义的字段)，签发时间为1516239022
var payload = Base64URL( {"sub": "1234567890", "name": "John Doe", "iat": 1516239022})
注意，JWT中payload是不加密的，只是Base64URL编码一下，任何人拿到都可以进行解码，所以不要把敏感信息放到里面。
③ signature
Signature 部分是对前两部分的签名，防止数据篡改。
注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
4、JWT特点：
因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
它不需要在服务端保存会话信息, 所以它易于应用的扩展
JWT 的几个特点
（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
（2）JWT 不加密的情况下，不能将敏感数据(如密码)写入 JWT，除非对payload进行加密。保护好secret私钥，该私钥非常重要。
（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
（4）JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
5、JWT优点：
体积小，因而传输速度更快
多样化的传输方式，可以通过URL传输、POST传输、请求头Header传输（常用）
简单方便，服务端拿到jwt后无需再次查询数据库校验token可用性，也无需进行redis缓存校验
在分布式系统中，很好地解决了单点登录问题
很方便的解决了跨域授权问题，因为跨域无法共享cookie
6、JWT缺点：
因为JWT是无状态的，因此服务端无法控制已经生成的Token失效，是不可控的，这一点对于是否使用jwt是需要重点考量的
获取到jwt也就拥有了登录权限，因此jwt是不可泄露的，网站最好使用https，防止中间攻击偷取jwt
在退出登录 / 修改密码时怎样实现JWT Token失效https://segmentfault.com/q/1010000010043871
7、JWT安全性：
JWT被确实存在被窃取的问题，但是如果能得到别人的token，其实也就相当于能窃取别人的密码，这其实已经不是JWT安全性的问题。网络是存在多种不安全性的，对于传统的session登录的方式，如果别人能窃取登录后的sessionID，也就能模拟登录状态，这和JWT是类似的。为了安全，https加密非常有必要，对于JWT有效时间最好设置短一点。
8、JWT常见问题：
① JWT 安全吗?
Base64编码方式是可逆的，也就是透过编码后发放的Token内容是可以被解析的。一般而言，不建议在有效载荷内放敏感信息，比如使用者的密码。
② JWT Payload 內容可以被伪造吗？
JWT其中的一个组成内容为Signature，可以防止通过Base64可逆方法回推有效载荷内容并将其修改。因为Signature是经由Header跟Payload一起Base64组成的。
③ 如果我的 Cookie 被窃取了，那不就表示第三方可以做 CSRF 攻击?
是的，Cookie丢失，就表示身份就可以被伪造。故官方建议的使用方式是存放在LocalStorage中，并放在请求头中发送。
④ 空间及长度问题？
JWT Token通常长度不会太小，特别是Stateless JWT Token，把所有的数据都编在Token里，很快的就会超过Cookie的大小（4K）或者是URL长度限制。
⑤ Token失效问题？
无状态JWT令牌（Stateless JWT Token）发放出去之后，不能通过服务器端让令牌失效，必须等到过期时间过才会失去效用。
假设在这之间Token被拦截，或者有权限管理身份的差异造成授权Scope修改，都不能阻止发出去的Token失效并要求使用者重新请求新的Token。
9、JWT使用建议：
Payload中的exp时效不要设定太长。
开启Only Http预防XSS攻击。
如果担心重播攻击（replay attacks ）可以增加jti（JWT ID），exp（有效时间） Claim。
在你的应用程序应用层中增加黑名单机制，必要的时候可以进行Block做阻挡（这是针对掉令牌被第三方使用窃取的手动防御）。
10、JWT与OAuth的区别
OAuth2是一种授权框架 ，JWT是一种认证协议 -无论使用哪种方式切记用HTTPS来保证数据的安全性 -OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)，而JWT是用在前后端分离, 需要简单的对后台API进行保护时使用。
总结
其实JWT并不在加密保护数据，而是为了认证来源。
JWT不保证数据不泄露，因为JWT的设计目的就不是数据加密和保护。
Angular 的文档中也对于JWT有非常深入的讲解，感兴趣的同学可以去深入了解，地址在下方。
本文引用地址：
JWT文档：https://jwt.io/introduction/
JWT描述：https://www.cnblogs.com/cndarren/p/11518443.html
Angular文档对于JWT了解：https://blog.angular-university.io/angular-jwt/
一文说清楚JWT，JWS，JWE：https://www.jianshu.com/p/50ade6f2e4fd
知乎一文说清楚JWT：https://zhuanlan.zhihu.com/p/86937325
JWS和JWE深入：
https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3，
https://darutk.medium.com/understanding-id-token-5f83f50fa02e