正在做一个企业内部单点登录平台，也就是 idaas
本来以为后端 api 给我获取到的 token 等授权信息
前端自己存起来就可以了
但后端这次方案使用了 Response 带 cookie ，前端调用 api 后直接作为只读 cookie 存在了前端
然后产生了 302 跳转登录页
我之前没这么做过，想咨询各位彦祖，哪种方案算是最佳实践
前端为 react 单页应用
后端应该是 springboot
多谢
本来以为后端 api 给我获取到的 token 等授权信息
前端自己存起来就可以了
但后端这次方案使用了 Response 带 cookie ，前端调用 api 后直接作为只读 cookie 存在了前端
然后产生了 302 跳转登录页
我之前没这么做过，想咨询各位彦祖，哪种方案算是最佳实践
前端为 react 单页应用
后端应该是 springboot
多谢
 |
1
c3de3f21 23 天前
如果是携带 cookie 不用前端做事的情况下
抓一个时间点，初次访问页面时尝试请求 user ，请求到 user 继续下面的流程 请求不到 user 和后端协商，是你跳登录还是后端跳登录 登录时候肯定携带了你的页面 url 走的，登录完了跳回来还是走 /user 请求 然后正常流程设置系统信息，用户信息菜单权限等等 |
 |
3
Oktfolio 23 天前
对于不同类型的应用实现不同的逻辑，如果是 SPA 就接口 401 的时候前端跳转，如果是传统网页就后端跳转。当然，也不一定要根据类型，反正做成可配置的就好。
|
|
4
Oktfolio 23 天前
SPA 做前端跳转，是因为前端跳转可以带上自己需要的参数，这样登录后就可以根据参数跳转回之前的页面了
|
 |
5
LittleFox 23 天前
如果前后端同源的话会自动处理 cookie 吧？不同源可能需要手动处理一下，感觉前后端不同源还是用 token 或者 jwt 舒服一点
|
 |
7
cus 23 天前 via iPhone
oauth2 bff 方案咯，公开的 client 被 SPA 用现在也被视为有风险的。没有不同源场景，逻辑是你不和 idaas 一个源，你和 bff 才是一个源。https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
|
 |
8
mmmNover 23 天前
cookie 把，operas/cas 项目的标准方案
|
 |
13
meshell 22 天前
@wangyzj oauth2 不需要考虑同源这种，我们的系统都是 oauth2 的单点登录，前端也是 spa 。我们是采用后端控制的跳转加 cookie 的，spring 原生支持这套体系。
|
 |
14
skallz 22 天前
除了久远之前的系统，好像现在都不会第一时间考虑 cookie 了，很多平台对 cookie 还会做限制，到时候如果需要接入某个对 cookie 限制的平台还得重构，更何况 cookie 在现在除了自动携带也没任何好处了 QAQ （一般都是只拿 cookie 做中间存储跨站点传值而已）
|
 |
16
mmdsun 21 天前 via iPhone
网关+BFF spring boot 官网有个例子。
就应该使用 cookie ，没问题 Oauth2 返回的 accessToken 就不应该直接给前端的。后端网关统一处理，使用 TokenRelayFilter 来处理。 如果不想用 cookie 可以放请求头里面参考： https://docs.spring.io/spring-session/reference/guides/java-rest.html Oauth2 BFF 参考： https://github.com/spring-projects/spring-authorization-server/tree/main/samples#spa-single-page-application-sample |
 |
17
clarkethan 20 天前
我也喜欢用 cookie ，HttpOnly + Secure + SameSite=Lax/Strict ，规避一些安全风险，比如 xss ，除非实际场景中有特殊要求，否则我会优先走 cookie
如果是多个不同的服务，建议用统一网关去处理，而不是浏览器去直接请求多个不同的域 |
Select Language