方案设计

项目简介

sso + oauth（单点登录和开放授权）

知识点

并不是所有系统支持cookie机制，所以需要使用token机制。

方案设计

SSO系统生成一个token，并将用户信息存到Redis中，并设置过期时间，其他系统请求SSO系统进行登录，得到SSO返回的token，写到Cookie中，每次请求时，Cookie都会带上，拦截器得到token，判断是否已经登录

未授权时支持302跳转和401响应

前后端分离方式，这种方式下业务方调用后端的接口时不希望得到302跳转，而是得到一个未授权的结果，在以下两个条件之一满足时：

1. ContentType为application/json或application/xml

2. 请求携带Header，x-requested-with:XMLHttpRequest

非cookie形式认证

同样在前后端分离场景中，当业务方调用后端接口时不方便传递cookie时（例如涉及到跨域cookie种植的问题），可以使用在请求头添加“access-token”和"client-id"的方式向后端请求接口，该方式等同于携带${clientId}_ssoid(即access-token)的cookie

POST /index.html (or /api/getdata) HTTP/1.1 //适用普通请求和ajax请求
access-token:${ssoid} //放置在Header里，其中ssoid由应用鉴权方负责获取
client-id:$(clientId) //颁发对应ssoid的clientId

前后端分离项目

由于cookie存在跨域问题，前后端域名不同的时候，需要由前端来完成种cookie的操作

JWT

会话session

使用全局会话和局部会话，集群存在session共享问题，同时服务端消耗过大。

Oauth2.0

基于oauth协议登录，每次访问向sso-server验证token

优化点

1. Nginx的rewrite解决方案

2. 当用户长时间不登录，cookie过期，如何使用refresh token 来重新刷新 access token

OAuth2.0授权与单点登录的区别

根据OAuth2.0授权与单点登录的概念，我们可以得知二者至少存在以下几点区别：

• 从信任角度来看。OAuth2.0授权服务端和第三方客户端不属于一个互相信任的应用群（通常都不是同一个公司提供的服务），第三方客户端的用户不属于OAuth2.0授权服务端的官方用户；而单点登录的服务端和接入的客户端都在一个互相信任的应用群（通常是同一个公司提供的服务），各个子系统的用户属于单点登录服务端的官方用户。

• 从资源角度来看。OAuth2.0授权主要是让用户自行决定——“我”在OAuth2.0服务提供方的个人资源是否允许第三方应用访问；而单点登录的资源都在客户端这边，单点登录的服务端主要用于登录，以及管理用户在各个子系统的权限信息。

• 从流程角度来看。OAuth2.0授权的时候，第三方客户端需要拿预先“商量”好的密码去获取Access Token；而单点登录则不需要。

参考资料：

1. https://juejin.im/post/5cdd42f9518825693f1ebf8d

2. http://www.ruanyifeng.com/blog/2019/04/github-oauth.html

3. https://www.zhihu.com/topic/19730683/hot