写在最前面：

大家好，我是小....小白不黑，现在的app以及任何一个系统，都离不开登录。其中最常见的估计就是密码登录，二维码登录，第三方账号登录以及单点登录了。

现在，让我们来捋一捋，这些登录的背后，究竟是什么设计的。全篇无图，请谨慎阅读........

一：密码登录

密码认证是最简单的用户认证方案。用户输入密钥，后台查库校验密码，通过则放行，否则则提示“账号或用户名错误”......

对于密码认证，后台通常会结合登录token，来优化登录逻辑：

1、用户输入密码，后台查库校验通过

2、后台缓存token,并返回token给前端

3、前端拿到该token，每次请求后台都以header的形式传递到后台

4、后台通过过滤器/拦截器拿到该token，比对一致则放行

此外，密码为了安全，一般是加密入库保存，而非明文保存。

二：二维码登录

在诸如微信，淘宝等系统，都支持手机扫码登录，那么，二维码认证的背后，又是怎样不为人知的流程呢？其实二维码登录的流程也并不复杂，且听我娓娓道来。

1、浏览器请求二维码，服务器返回二维码及uuid，并缓存uuid。

2、浏览器以此uuid为参数，不断轮询服务器，检查响应结果。

3、手机端扫描二维码，携带手机已登录的token，请求服务器。服务器接收到请求后，先把用户信息关联上uuid（昵称，头像等，此时浏览器还不断在轮询，这样浏览器就能马上解析到用户昵称及头像）

4、服务器响应，要求手机端确认登录。

5、手机端确认登录后，服务端将userId与uuid关联上（redis：key=uuid,value=userid即可）

6、浏览器轮询的时候，服务器通过uuid发现userId已经确认登录，则拿userId查表，拿到用户名密码等信息，生成一个登录token，返回给浏览器。

7、至此，浏览器就借助手机登录状态完成了登录。

但是，当相关系统逐渐多了起来，当用户每次进入一个系统都需要输入一次用户名及密码，一千匹草泥马瞬间奔跑.........因此，也就有了单点登录的方案设计。

三：单点登录

最简单的单点登录设计，其实就是每一个子系统都集成同一个统一认证服务，通过统一认证服务，共享登录状态。

举个例子：

在子系统A中，校验用户名及密码合法后，请求统一认证服务，返回一个凭据token，之后调用任意一个系统，都携带此token。而这里的密码认证，与前面写的大差不差。每一个子系统则通过认证拦截器，携带token调用外部统一认证服务进行认证即可。当然，为了性能，各子系统也会缓存该凭据token，避免每次都需要调用统一认证服务进行身份校验。

对于第三方统一认证服务来说，获取凭据的接口，使用数字签名来鉴别调用者的合法性即可。

数字签名小tips:

非对称加密可以用来加解密以及加签与验签。

加解密的目的是保证数据能秘密传输到目的地，如https协议。前期加密通信，客户端需要拿到服务端的公钥信息，拿此公钥进行加密。而服务端则拿公钥匹配的私钥对数据进行解密。

数字签名的目的是能够标识发送方的身份。因此，发送方需要拿自己的私钥加签，而接收方则可以拿公钥进行验签，保证发送方是一个可信的合法源。

四：使用第三方账号登录：OAuth2.0（客户端模式）

在很多app软件或者网址中，我们都可以看到，可以使用第三方账号进行登录。比如qq浏览器，gittee等，都可以用微信账号进行登录。

首先了解一下什么是Auth2.0:

OAuth是一项协议，它为用户资源的授权提供了一个安全、开放而简易的标准，OAuth的授权不会使第三方触及到用户的账号信息（比如密码），因此OAuth是相对安全的。也就是说，借助OAuth,第三方可以不涉及用户某个平台的账号密码等，也能直接拿到用户在该平台的一些信息。交互流程如下：

1、gittee事先向微信统一认证服务中心申请appId（公钥）与appSecret（私钥），用作签名。并提前注册好回调地址

2、用户使用微信账号登录gitte时，gitte将请求转向微信统一认证服务中心，并携带appId以及数字签名证明自己的身份。

3、微信认证服务中心先是校验该用户有没有登录过（如何判断？?）

4、如果未登录，则转向微信的登录页面，反之则前往微信用户授权页面，请求微信用户授权

5、用户点击授权，则认证中心会返回授权码，并前往gitee的回调地址（gitte自己的地址）

6、gittee拿该授权码，前往微信认证中心兑换长期票据（Access Token）

7、gittee获取到长期票据，相当于用户的登录token，也就是gittee获取了访问该用户在微信平台相关数据的权限

整个流程下来，gittee就借助第三方平台的认证功能，完成了用户在Agittee的认证。

来到这里，不知道大家是否会有一个疑问：

为什么认证服务器在用户授权后，返回授权码，而不是直接返回长期票据？

如果直接在重定向的URL中返回长期票据，如果被中间人攻击，长期票据就会泄露。

如果返回授权码，如果中间人拿到授权码，还得需要appId,appSecret才可以兑换长期票据。

但是如果兑换长期票据的时候，发生中间人攻击，那就gg了。只能通过Https等措施巩固安全。

那么来到这里，大家可能又会产生另外一个疑问：

资源服务器怎么验证长期token的有效性？长期token又不是他颁发的？

答案就是：机机鉴权。

认证服务器（认证中心）已经拿了自己的私钥进行加签，并且提前给了一个公钥给资源服务器（微信），资源服务器可以通过公钥进行验签，验证token是否有效。

而认证中心，只需要签发appId与appSecret并提供获取临时票据接口及兑换长期票据接口即可。而签发appId与appSecret，实际就是为了实现机机鉴权（云服务鉴权大多使用此方式做机机认证，如华为云的IAM），临时票据及长期票据，则是为了实现用户授权。

tips小课堂之华为云统一认证服务的机机认证说明：

IAM服务将ak/sk分发给不同的平台，如APIG网关，apig拿sk加签，并请求IAM，然后IAM拿ak验签。验证通过后再返回登录token。apig的下游服务，如果需要iam认证，直接拿apig返回的token调用iam就可以了。跟单点登录的设计是一样的，都是用第三方认证平台来做认证管理，第三方认证平台只需要分发ak/sk给接入了该认证平台的其他第三方平台就可以了。

好了，我是小白不黑，今天的登录就到此为止啦~下期再见！

 ​​​​