2 个回答
![肺少女 肺少女](https://www.80wz.com/zb_users/avatar/0.png)
还有一种比较简单的方案,如下图:
![](https://pic.80wz.com/upload/2024/04/202404101287_1428.png)
他的逻辑如下:
![](https://pic.80wz.com/upload/2024/04/202404101287_1428.png)
他的逻辑如下:
1、用户输入用户名/密码登陆 ServiceB 系统;
2、用户点击 ServiceB 系统中的某个按钮跳转到 ServiceA 系统,在跳转时需要带上 ServiceB 系统加密后的用户信息;
3、ServiceA 系统拿到 ServiceB 系统加密后的用户信息后进行验签和解密操作;
4、ServiceA 系统将用户信息保存到本地并生成 token 返回给 ServiceB 系统;
5、ServiceB 系统拿到 ServiceA 系统返回的 token 就可以访问 ServiceA 系统的资源信息了;
发布于:4个月前 (04-10) IP属地:四川省
![离不开天空的云 离不开天空的云](https://www.80wz.com/zb_users/avatar/0.png)
大众常用的方案如下图:
![](https://pic.80wz.com/upload/2024/04/202404102599_493.png)
具体的流程逻辑如下:
![](https://pic.80wz.com/upload/2024/04/202404102599_493.png)
具体的流程逻辑如下:
1、用户输入用户名/密码登陆 ServiceA 系统;
2、用户点击 ServiceA 系统中的某个按钮跳转到 ServiceB 系统,在跳转时需要带上 ServiceA 系统颁发的 ticket 票据;
3、ServiceB 系统拿 ServiceA 系统的 ticket 去获取 ServiceA 系统的用户信息;
4、ServiceA 系统会校验该 ticket 票据,然后将用户信息返回给 ServiceB 系统;
5、ServiceB 系统根据用户信息生成 token 并附带重定向地址返回给 ServiceA 系统;
6、ServiceA 系统就可以拿着获取的 token 去访问 ServiceB 系统的资源信息了。
发布于:4个月前 (04-10) IP属地:四川省
我来回答
您需要 登录 后回答此问题!