单点登录和第三方登录

最近做了一些登录相关的工作，顺便看了下常见的登录方案，这里主要从后端的角度梳理一些技术细节。

文章目录

单点登录
第三方登录

单点登录

单点登录(Single Sign On)，简称SSO，是目前比较流行的一种解决方案，其表现为对一组相互信任的应用，用户只需要登录其中一个应用，就可以访问所有相互信任的应用，登出依然。

最常见的就是淘宝和天猫，当登录其中之一后，另外一个天然的共享登录态。

单点登录实现需要依赖独立部署的认证服务来实现。

我们假设有A和B两个相互信任的应用，共同接入了独立部署的认证中心sso(接入采用的是OAuth，在第三方登录中会详细地说明，这里可以不用纠结具体的接入细节)，以此为例来详细描述单点登录过程，流程图如下。

初始状态为A、B应用均未登陆，此时向A应用(域名a.com)发送请求，cookie为空，验证未通过，重定向至sso。
说明: 正常重定向是302，这里我们返回的是401，然后带了location，需要前端处理一些逻辑，至于原因不是很清楚。
请求只sso后会返回登录界面，可以是账号密码登录，也可以是二维码登录。
用户进行登录操作后并验证成功后会在 sso.com下种下cookie，然后带着sso颁发的ticket重定向至a.com的。
A服务拿到ticket后向sso发起请求，验证ticket有效后返回用户的信息，A服务在a.com种下cookie。
至此，整个登陆过程结束。后续A服务拿到cookie后要向sso发送请求进行验证，因为只有这样，所有的应用才能共享登录态及登出态。

A应用登录后，我们再看B应用是如何共享登录态的。 6. 浏览器向B应用发送请求，此时b.com下没有cookie，验证失败，重定向至sso。 7. sso.com下带有A应用登录时种下的cookie，sso使用此cookie验证通过，跳过了用户登录。 8. 后续过程和上面一样，会在b.com下种下cookie。

第三方登录

目前第三方登录采用的都是OAuth2.0标准，其是一种可以在第三方应用在不知晓用户认证信息(用户名密码等)的情况下获取登录态以及用户信息的方法。
下面以lark的OAuth为例说明第三方登录过程(授权码模式)。
可以看到整个过程和上面利用sso登录的过程基本一样，因为我们说过一般接入sso服务都是用的OAuth。然后和上面的区别是：

lark下不会有cookie，同时接入lark的应用不会共享登录态。
a.com的cookie由应用自身管理，不需要每次请求lark进行验证。