如何使用认证服务返回的SessionId调用同服务器另一端口的Web Service

两个服务部署在同一台服务器仅端口不同，可根据你的业务场景选择以下几种传递认证信息的方案：

1. 请求头传递（最推荐） #

符合API设计规范，安全性更高，适合前后端分离、纯接口调用等绝大多数场景

• 从第一个认证服务拿到SessionId和用户名后，在发起对第二个服务的请求时，在HTTP头中加入自定义认证字段，通用做法是使用Authorization头传递SessionId，可选新增自定义头X-Username传递用户名
• curl调用示例：

curl -H "Authorization: Bearer 你获取到的SessionId" -H "X-Username: 认证接口返回的用户名" http://服务器地址:第二个服务端口/目标接口路径

• 优势：认证信息不会出现在URL、服务端访问日志、浏览器历史记录中，也不需要处理Cookie跨端口适配问题

2. Cookie传递（适合有浏览器参与的前后端交互场景） #

• 第一个认证服务返回SessionId时，设置Cookie的domain为当前服务器的根域名/IP，path设为/，HTTPS场景下可将SameSite设为None，确保不同端口的服务都能读取到该Cookie
• 浏览器发起对第二个服务的请求时会自动携带Cookie中的认证信息，无需手动传递；如果是无浏览器的纯接口调用，手动在请求头加Cookie: SessionId=xxx; username=xxx即可

3. 请求参数传递（仅建议测试场景使用） #

• 直接把SessionId和用户名作为GET或者POST参数传递给第二个服务，GET请求示例：http://服务器地址:第二个服务端口/目标接口路径?sessionId=xxx&username=xxx
• 劣势：认证信息会明文出现在各类日志中，生产环境使用存在信息泄露风险

通用注意事项 #

• 两个服务需要提前约定SessionId校验规则：第二个服务拿到SessionId后可直接访问公共存储（Redis、数据库等）校验有效性，也可以调用第一个认证服务的内置校验接口确认合法性
• 生产环境建议给SessionId设置合理的过期时间，避免认证信息长期有效带来的安全隐患

内容的提问来源于stack exchange，提问作者Alexandros Angelopoulos