基于SSO实现多应用同账号登录方案咨询

1. 已通过Fetch DB验证用户，是否仍需使用Open Id Connect？ #

需要。OAuth2本质是授权协议，核心解决第三方应用获取主应用资源权限的问题，但没有标准化的身份认证流程和用户信息传递机制。OpenID Connect（OIDC）是基于OAuth2扩展的身份认证协议，能解决以下关键痛点：

• 标准化身份断言：通过ID Token向Portal安全传递用户身份信息（如用户ID、基础属性），避免Portal直接依赖Fetch DB结构，降低系统耦合。
• 统一会话管理：OIDC提供标准化的会话同步、全局登出机制，比如用户在Fetch登出后，Portal能同步失效会话，这是直接连DB验证无法实现的。
• 降低安全风险：若让Portal直接访问Fetch DB，一旦DB结构变更或出现漏洞，会直接影响Portal的可用性和安全性；用OIDC的话，Portal仅需与授权服务器交互，无需触碰核心用户数据库。

即便能直接通过DB验证用户，OIDC也能让SSO流程更标准、安全、可维护，而非依赖自定义验证逻辑。

2. 是否需将身份模块从Fetch剥离为独立AuthenticationService服务于双应用？ #

分场景判断：

• 无需立即剥离：如果当前只有Fetch和Portal两个应用，且Fetch的身份模块（登录、令牌签发等）与业务逻辑耦合度低、维护成本可控，完全可以让Fetch直接作为OAuth2/OIDC的授权服务器，为Portal提供身份认证服务。这种方式快速落地，无需额外开发独立服务。
• 建议剥离：如果未来有更多应用需要接入SSO，或Fetch的身份模块与医疗业务逻辑深度绑定、维护时易互相影响，或需要独立扩容身份服务（比如大促时Portal登录请求突增，不想影响Fetch的医疗业务），那剥离成独立的AuthenticationService更合适。独立服务可专注于身份认证逻辑，解耦业务，便于复用和扩展。

总结：当前阶段可先基于Fetch做授权服务器，后续根据业务发展再考虑拆分。

3. 是否有其他可行的替代方案？ #

除OAuth2/OIDC外，还有几种方案可选，各有优劣：

• 同域Cookie共享SSO：若Fetch和Portal属于同一父域（如fetch.yourdomain.com和portal.yourdomain.com），可在Fetch设置父域会话Cookie，Portal读取该Cookie后，通过FetchGateway验证Cookie有效性。优点是实现简单、用户无感知；缺点仅支持同域场景，存在CSRF攻击风险，跨域时无法使用。
• SAML协议：企业级SSO标准协议，适合跨域场景，能提供复杂的身份断言和权限控制。但配置繁琐、协议较重，对于小型电商站Portal来说，学习和维护成本较高。
• 自定义令牌验证机制：Portal登录时调用Fetch的验证接口，Fetch返回签名后的自定义令牌（如JWT），Portal存储令牌，后续请求携带令牌由FetchGateway验证有效性。优点是灵活、可按需定制；缺点是需自行实现令牌的签发、验证、过期、刷新等逻辑，还要处理签名、加密等安全细节，稳定性和安全性不如标准协议。

内容的提问来源于stack exchange，提问作者Abhijith Nayak