登录鉴权、JWT、单点登录

登陆鉴权

1.一般来说开放平台不会需要⽤户必须登陆,但是如果需要的话,我们需要对⽤户的登陆信息进⾏校验,那么如何校验⽤户的登陆信
息呢,类似于淘宝的登陆系统并不是简单的只给淘宝⽤的,阿⾥巴巴旗下的绝⼤部分功能都可以使⽤这⼀个帐号登陆,如果我们给每
个系统都写⼀套登陆系统的话,代码是⼀样的出现功能重写,那么我们想办法只写⼀个登陆系统,然后进⾏统⼀的验证,只需要在任意
其他系统中对登陆返回的数据进⾏校验即可,我们称之为单点登录

2.单点登录实现的⽅式有很多,其本质就是数据的共享,之前⼤部分的⽅式都是将帐号系统独⽴出来,⽤户访问授权系统登陆,登陆系统
会返回⼀个验证信息给⽤户, ⽤户访问A功能的时候将验证信息带过去,A服务器在内部验证,如果⽆法验证就会在内部请求授权服务
器进⾏验证,成功后在A保存⼀份,并让⽤户继续访问,下次的话就可以直接内部验证了,这时候如果⽤户要访问B地址按照i相同的流
程再来⼀次, 这样我们在授权系统进⾏⼀次登陆后就可以i在多个系统实现登陆

3.在开放平台中,登陆授权并不属于其中的⼀部分,登陆系统⼀般已经有⼈写好了,我们只需要按照他们定义的规范使⽤数据就是了,其
实就是登陆系统返回的数据我们保存起来,下次按照服务器的要求通过对应的⽅式传递过去,⽐如cookie, headler,请求参数等⽅式

JWT

在上⾯的⽅式中,授权系统会做很多操作,包括登陆,校验等,所以需要的资源⽐较多,可能会出现系统瓶颈的问题,现在⼀般流⾏简化的验证
⽅式, 还是上⾯的那个功能,如果我们的AB服务⾃⼰知道如何校验的话,就不需要去授权系统进⾏请求校验了,⽽是⾃⼰直接校验就可以
了,但是呢如果校验的安全级别不够的话⽐较容易被⼈伪造信息,这⾥就可以使⽤我们上⾯的签名的⽅式来提⾼安全度,那可不可以这样
呢,我们的授权系统将授权信息签名后发给客户,客户下次带着数据过来,我们进⾏签名校验就可以了,如果可以,说明没有问题,这种技术我
们称之为令牌Token

JSON Web Token（JWT）是⼀个⾮常轻巧的规范。这个规范允许我们使⽤JWT在⽤户和服务器之间传递安全可靠的信息。
⼀个JWT实际上就是⼀个字符串，它由三部分组成，头部、载荷与签名。
头部（Header）
头部⽤于描述关于该JWT的最基本的信息，例如其类型以及签名所⽤的算法等。这也可以被表示成⼀个JSON对象。
{“typ”:“JWT”,“alg”:“HS256”}
在头部指明了签名算法是HS256算法。 我们进⾏BASE64编码http://base64.xpcha.com/，编码后的字符串如下：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

载荷（playload）
载荷就是存放有效信息的地⽅。这个名字像是特指⻜机上承载的货品，这些有效信息包含三个部分
（1）标准中注册的声明（建议但不强制使⽤）

	iss: jwt签发者
	sub: jwt所⾯向的⽤户
	aud: 接收jwt的⼀⽅
	exp: jwt的过期时间，这个过期时间必须要⼤于签发时间
	nbf: 定义在什么时间之前，该jwt都是不可⽤的.
	iat: jwt的签发时间
	jti: jwt的唯⼀身份标识，主要⽤来作为⼀次性token。

（2）公共的声明
公共的声明可以添加任何的信息，⼀般添加⽤户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端
可解密.
（3）私有的声明
私有声明是提供者和消费者所共同定义的声明，⼀般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为
明⽂信息。
这个指的就是⾃定义的claim。⽐如前⾯那个结构举例中的admin和name都属于⾃定的claim。这些claim跟JWT标准规定的claim区别在
于：JWT规定的claim，JWT的接收⽅在拿到JWT之后，都知道怎么对这些标准的claim进⾏验证(还不知道是否能够验证)；⽽private
claims不会验证，除⾮明确告诉接收⽅要对这些claim进⾏验证以及规则才⾏。
定义⼀个payload:

{"sub":"1234567890","name":"John Doe","admin":true}

然后将其进⾏base64加密，得到Jwt的第⼆部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

签证（signature）
jwt的第三部分是⼀个签证信息，这个签证信息由三部分组成：
header (base64后的)
payload (base64后的)
secret
这个部分需要base64加密后的header和base64加密后的payload使⽤.连接组成的字符串，然后通过header中声明的加密⽅式进⾏加盐
secret组合加密，然后就构成了jwt的第三部分。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95
OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意：secret是保存在服务器端的，jwt的签发⽣成也是在服务器端的，secret就是⽤来进⾏jwt的签发和jwt的验证，所以，它就是你服
务端的私钥，在任何场景都不应该流露出去。⼀旦客户端得知这个secret, 那就意味着客户端是可以⾃我签发jwt了。