网关统一鉴权+SSO 单点登录的架构中，网关是 SSO Client 吗？

[sola97]

目前项目的架构是
有一个登录服务，生成 token 写入 redis
然后有几个 web 应用，每个 web 应用都需要调用登录服务登录后，带上 token 调用其他服务
想要改造成 SSO 单点登录，实现网关鉴权+日志等功能

目前我找到的两篇文章有
微服务-API 网关-身份验证 多模块 web 系统登录设计

这种架构中如果认证服务器颁发 ticket 后，是网关来根据 ticket 登录，也就是 SSO Client?

[xiaoyanbot]

正常的 jwt token 不用写入 redis

只有 ban，或者用户主动注销的 jwt token 才写入一个 未过期的 token 禁止列表

[meshell]

网关鉴权是不是只能针对 url 鉴权？我现在系统里面如果弄成网关鉴权就只能针对 url 处理，不能根据业务来。

[ccde8259]

CAS 的 SSO 优势主要是基于 HTTP 协议完成单点登录，也就是即使你的 Web 应用是 polyglot 的场景也能完成鉴权。
一个简单的实现是，让你的 Web 应用如何成为 SSO Client 。缺陷就是各个 Web 应用这个场景下并不是共享 Session 的，因为 CAS 只负责鉴权。
实现共享 Session 就是让 Gateway 成为 SSO Client，由 Gateway 控制 Session 。

[securityCoding]

@meshell 理论上网关都是根据 url path 匹配路由规则 , 每条路由规则可以做各种定制化的配置

[xuanbg]

网关已经实现认证 /鉴权了，微服务都在网关后面了，还要什么 token 。

[THESDZ]

@xuanbg #5 是不用 token,但是要当前用户信息

[meshell]

@securityCoding 如果是这样的话，等于系统开始设计的时候 url 这些就要想好了。不然网关里面的规则经常改。 我们现在还是在不同的服务里面做鉴权这样就是每个服务都重复了三个文件这些文件有变动就是所有的服务又要 copy 一遍。

[norristong2]

- https://cdn.authing.co/authing-docs-v2/1.1.72/assets/img/app-device-logout-6.f739ed29.png
- https://docs.authing.cn/v2/concepts/single-sign-on-and-single-sign-out.html

可以参考这家公司的设计方案，“返回一个授权码 code ，再使用 code 在业务后端换取 Access token ，再用 Access token 获取用户信息。”