常见的

单系统cookie登陆，session登陆，jwt(json web token)。

oauth2 登录

OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用，获取用户数据。学习文章

以一个例子来说，我住在一个大型小区，有门禁系统，每次进入我需要输入密码才能进入，小区有快递员，他需要通过门禁送快递，但我不能把密码告诉他，不然他就跟我有同个权限了，我想取笑他的权限还得改密码，改了后其他快递员又进入不了了。

所以有一套授权机制，小区门禁有个申请授权按钮，快递员只要一按下，我的手机就收到申请权限的短信，我点通过后，门禁显示一条临时密码(access_token)，这个临时密码只在短时间内有效，快递员通过这个access_token就能进入了。

再映射到互联网上，小区就是存储用户数据的网络服务，比如微信，然后快递员就是一些第三方应用，比如百度网盘。
我们登陆百度网盘的时候，会有微信登录的选项，当我们点击微信登录的选项后，其实就是门禁系统上的申请权限，
这时候手机跳到微信页面，我们点击确定登陆，相当于我们授权百度网盘进入小区，获取数据。

oauth就是一种授权机制，数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据，系统产生一个短期的token，用来代码密码，第三方应用可以通过这个token在短时间内访问系统。

使用密码的缺点：

• 安全性问题
• 无法记录授权后的行为
• 无法限制被授权第三方应用保存泄漏等
• 多个授权不便于管理

短期令牌的优点

• token是短期的，用户无法自己修改，可以背撤销，会立即失效。
• 权限范围管控，有些令牌只允许访问某些接口

oauth2办法令牌有四种方式

• 授权吗(authorization-code)
• 隐藏式
• 密码式
• 客户端凭证

不管用哪些种方式，第三方应用申请令牌之前，都需要到系统备案，说明自己身份，拿到客户端id(client ID)和客户端密钥(client sercret)，这是为了防止令牌被滥用。

授权码方式

这是最常用的流程，比如我们常用的微信登录。适用于有后端的web应用。
授权码通过前端传送，令牌存储在后端。
github登陆流程：

• A网站提供一个链接，点击后跳转到github授权，用户点击同意后，github会跳回原来的地址，带上了code（授权码），
• A拿到授权码后，给A的后端，A后端向github发器请求，等到了access_token，这时候就能通过access_token访问github拿到用户信息了。

这样登陆就算完成了。

隐藏式

有些web是纯前端，没有后端，这时候就可以用隐藏式了，oauth2允许直接向前端发令牌，这种方式没有授权码(code)的流程，所以称为(授权码)隐藏式

流程；
https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read

• A提供一个网站，跳到github，github授权通过，github跳回redirect_uri指定的地址，并且携带了token(access_token)，所以A网站就可以直接拿到了令牌
• A拿到令牌后直接请求github获取用户信息，这种较第一种方式就是令牌在前端暴露了，所以不安全，有效期一般很短。

密码式

如果你高度信任某个应用，oauth2允许用户把用户名和密码直接告诉应用，该应用使用你的密码申请令牌，称为密码式。
风险极大

凭证式

适用于没有前端的命令行应用，在命令行下请求令牌

更新令牌

令牌如果到期了，会让用户重新走上一遍流程，再申请一个令牌，体验不好，所以oauth2允许用户自动更新令牌。
github发令牌的时候，除了access_token，还会发放一个refresh_token，更新令牌。

demo nest实现github登录

前端实现：

提供网址点击跳转，授权后，会带上code重定向回来

拿到code之后，直接调用登陆接口，获取用户信息

后端实现：
假设我们已经有了code，封装请求方法(client_id和client_sercet需要去github网站备案获取)

通过code获取access_token和用户信息

写一个路由实现登陆逻辑。

单点登录

早期多系统登录解决方案：
单系统登录一般使用cookie，但是cookie有跨域限制，所以一般将所有子系统的域统一在一个顶级域名，比如xx.baidu.com，这样cookie就能在所有系统里面共享。
缺点：

• 应用群域名需要统一
• 应用群个系统使用的技术相同(web来说，cookie同名)
• cookie本身不安全

什么是单点登录(SSO)

在多系统中登录一个系统，在其他系统内无需再次登陆，即可访问。包括单点登录，单点注销。

单点登录原理：所有系统不再提供登录入口，创建一个新的系统（认证中心），专门用来进行登录授权管理，只有认证中心才能接受用户名和密码等信息，然后其他系统通过认证中心的间接授权来判断是否登录。

间接授权一般通过令牌实现，sso认证中心确认用户密码没问题后，保持登录状态。这时候再访问其他系统，认证中心可以颁发给子系统一个令牌，子系统通过这个令牌，访问认证中心，拿到用户信息和专属于该系统的cookie(xx.baidu.com)，后续子系统通过这个cookie访问认证中心判断cookie是否失效，或者获取信息等。

流程图

• 首先访问认证中心系统，输入用户密码，登录，获取cookie。
• 然后如果从认证中心去访问A系统，会携带认证中心分发的短token，A系统拿到短token后，访问认证中心，获取专属A系统的cookie和用户信息。将该cookie返回A系统前端，此后用户每次访问A系统，都会携带该cookie去认证中心访问判断cookie是否生效。
• 其次，如果不通过认证中心，直接访问B系统的话，此时拿不到短token，B系统会重定向到认证中心，比如认证中心.com/xxxxx?redicet_url=B系统.com/xxx，认证中心识别该访问后，判断该用户已登录，就继续重定向到B系统.com?token=xx，并分发一个短token，然后B系统此时拿到了短token，再重复跟A系统一样的操作即可。

总结

• oauth2登陆，一般是通过第三方验证，相当于拿到一个短期门票，可以去访问第三方的一些数据。具体操作先在第三方应用注册应用信息，然后登陆的时候跳转第三方应用授权页面，授权通过后，第三方应用返回个code，并且跳转回原系统，原系统拿到该code后去访问第三方应用，获取access_token和用户信息，这种一般是授权码登陆，其次还有隐藏式(适用于纯前端)，密码式，凭证式，用的较少。
• 单点登录，要求不同域名下的系统，一次登陆，全线通用，通用由独立的认证中心来记录登陆状态，分发短令牌和token，其他业务系统配合储存和认证分发的token。