一次一密临时票据：医疗跨系统SSO的安全设计方案

在医疗信息化建设中跨系统集成例如 HIS/EMR 嵌入移动护理系统的体温单、评估单等页面是一个极具代表性的业务场景。然而如何安全、优雅、轻量化地实现系统间的单点登录与数据隔离往往是研发过程中的难点。本文将结合具体项目实践探讨一种基于“一次性临时票据Short-lived Single-use Ticket”的跨系统安全集成设计方案。1. 痛点明文凭证 URL 拼接的“硬伤”在许多传统的系统集成设计中最简单粗暴的做法是直接在 Iframe 嵌入链接中拼接明文的用户名与密码// ❌ 不推荐的安全隐患设计consttargetUrl${url}common/login?usercspsd123hiId3bingquId101componentsSchemaDemovisitnoP00182readonly1;这种方案虽然能够快速跑通业务但在生产环境中会带来一系列重大安全漏洞敏感凭证泄露明文密码psd123暴露在 URL 中会永久驻留在浏览器的历史记录、代理网关如 Nginx日志、以及 HTTP 请求的Referer头中。纵向/横向越权URL 篡改恶意用户或患者可以直接通过修改 URL 中的visitno住院号或readonly0权限绕过鉴权直接查看或篡改其他患者的医疗敏感数据。缺乏精细化审计使用公用的弱口令账户在日志和审计中无法溯源到底是第三方系统的哪位医护人员进行了访问和操作。2. 核心设计基于 Redis 的“用后即焚”票据机制为了从根本上消除上述风险我们引入了动态临时票据Ticket机制。其核心理念是“一次一密限时失效用后即焚”。2.1 架构设计与时序图整个单点登录过程由第三方系统HIS/EMR后端、移动护理后端NIS Server、**浏览器Iframe和移动护理前端NIS Client**协同完成移动护理前端 (React App)浏览器 (Iframe)移动护理服务端 (NIS API)第三方系统 (HIS/EMR 服务端)移动护理前端 (React App)浏览器 (Iframe)移动护理服务端 (NIS API)第三方系统 (HIS/EMR 服务端)步骤 1后台会话初始化与票据生成服务端双向鉴权 (AppKey/Secret 校验)步骤 2前端安全加载与会话建立步骤 3票据校验与“用后即焚”alt[Ticket 存在且未失效][Ticket 不存在或已失效]步骤 4直连重定向POST /api/auth/getShareTicket(携带当前操作人、患者ID、目标组件、权限等)1生成随机 Ticket UUID缓存至 Redis (TTL 60s)2返回票据 ticket3渲染 Iframe传入 ticketcommon/login?ssoTicketUUID4加载登录承载页5POST /api/auth/loginByTicket (验证票据)6从 Redis 读取 ticket 数据7立即从 Redis 删除该 Ticket8为操作用户生成本地 Session/JWT 登录态9返回登录成功 原始加密透传参数10返回 401 认证失败11路由跳转至目标组件页面/inpNurse/SchemaDemo?visitnoP00182readonly1123. 前后端代码改造指南3.1 后端改造票据的生命周期管理后端需实现两个核心接口。接口一票据初始化生成 (getShareTicket)该接口仅允许两端服务端通信HIS 后台 - NIS 后台需要对 HIS 的 AppKey 和 Signature 进行严苛校验。// 模拟 Java Spring Boot 控制器伪代码PostMapping(/api/auth/getShareTicket)publicResponseEntity?getShareTicket(RequestBodyShareTicketRequestrequest,RequestHeader(Authorization)StringauthHeader){// 1. 签名与安全校验if(!authService.verifyThirdPartySignature(authHeader,request)){returnResponseEntity.status(HttpStatus.UNAUTHORIZED).body(Invalid signature);}// 2. 生成 32 位随机 UUID 票据StringticketUUID.randomUUID().toString().replace(-,);// 3. 将集成的业务上下文参数存入 Redis设置 60 秒有效期StringredisKeynis:share_ticket:ticket;redisTemplate.opsForValue().set(redisKey,request,60,TimeUnit.SECONDS);// 4. 返回票据给 HISreturnResponseEntity.ok(newShareTicketResponse(ticket));}接口二票据换取 Token (loginByTicket)该接口由浏览器端Iframe 内的移动护理前端发起验证票据有效性并在成功后立即作废票据。PostMapping(/api/auth/loginByTicket)publicResponseEntity?loginByTicket(RequestBodyMapString,Stringbody){Stringticketbody.get(ticket);StringredisKeynis:share_ticket:ticket;// 1. 从 Redis 读取ShareTicketRequestticketContext(ShareTicketRequest)redisTemplate.opsForValue().get(redisKey);if(ticketContextnull){returnResponseEntity.status(HttpStatus.UNAUTHORIZED).body(票据无效或已失效);}// 2. 关键“用后即焚”防止重放攻击redisTemplate.delete(redisKey);// 3. 登录授权逻辑免密为指定用户生成 Session 或 JWT 令牌UserSessionsessionauthService.createSessionForUser(ticketContext.getUser());// 4. 返回登录凭证及原先保存在票据中的业务参数MapString,ObjectresultnewHashMap();result.put(userMessage,session);result.put(params,ticketContext);// 透传业务参数visitno, components 等returnResponseEntity.ok(result);}3.2 前端改造React 单点登录分发器在移动护理的前端入口登录组件如login/index.jsx中当路由匹配到ssoTicket时自动拦截并执行单点认证逻辑// login/index.jsx 周期改造componentDidMount(){constparamsgetUrlOptions();// 检测到第三方单点登录票据if(paramsparams[ssoTicket]){this.props.loginByTicket({ticket:params[ssoTicket]}).then(res{if(!res){this.props.history.push(/common/userNull);return;}const{userMessage,params:ssoParams}res;// 1. 本地存储会话避免对标准主应用缓存产生污染建议存入集成专用 KeylocalStorage.setItem(userMessage360,JSON.stringify(userMessage));localStorage.removeItem(psw);// 2. 并行拉取字典和病区数据this.props.getAllDicAndDepart({inHospitalStatus:0}).then(dicRes{if(dicRes){Dictionary.setAllDic(dicRes.dictionaryResponse);Dictionary.setNurseList(dicRes.nurseDepartResponses);Dictionary.setDepart(dicRes.departResponse);}// 3. 构建附加透传参数letextraUrlStr;for(letkeyinssoParams){if(![user,hiId,bingquId,components,visitno,readonly].includes(key)){extraUrlStr${key}${ssoParams[key]};}}// 4. 动态路由分发const{components,bingquId,visitno,readonly}ssoParams;constbasePath/inpNurse/${components};if(visitno){// 公共评估单组件特殊路径处理if(components.indexOf()-1||components.indexOf(*)-1){letmenucomponents.split(-);this.props.history.push(/inpNurse/${menu[0]}?components${menu[1]}bingquId${bingquId}visitno${visitno}readonly${readonly}${extraUrlStr});}else{this.props.history.push(${basePath}?components${components}bingquId${bingquId}visitno${visitno}readonly${readonly}${extraUrlStr});}}else{this.props.history.push(${basePath}?bingquId${bingquId}readonly${readonly}${extraUrlStr});}});}).catch(err{console.error(SSO Ticket Auth Error:,err);this.props.history.push(/common/userNull);});}}3.3 内部多 Iframe 渲染的联动优化在多组件嵌套预览页面如nursingPreview/index.jsx中原本菜单切换会高频加载/common/login?usercspsd123...去反复做自动登录。在方案一落地后由于主 Iframe 已经被注入了userMessage360缓存子级多组件 iframe 无需再次走任何登录接口。可以直接修改为直接的组件路由访问- // 改造前 (含有明文 user psd) - const targetUrl ${url}common/login?usercspsd123hiId3bingquId${params.bingquId}componentsSchemaDemovisitno${params.visitno}readonly1source1irtCode${item.irtCode}; // 改造后 (同域直连业务路由完全不携带登录凭证浏览器共享 Cookie/Storage 登录态) const targetUrl ${url}inpNurse/SchemaDemo?componentsSchemaDemobingquId${params.bingquId}visitno${params.visitno}readonly1source1irtCode${item.irtCode};4. 方案的安全性深度剖析通过上述改造后该方案具备了以下几项极强的安全保障攻击类型传统明文方案临时票据方案 (Ticket)防护原理说明URL 参数篡改❌ 容易✅ 免疫即使攻击者在 iframe url 中篡改参数由于后端校验只认可 Redis 里票据绑定的初始值篡改亦无效。重放/暴力破解❌ 极易破解✅ 免疫票据由 Redis 托管并实施了Read Delete机制。即使票据在网络传输中被拦截由于它已经被消费一次并被物理删除第二次再提交已失效。持久泄露❌ 长期暴露在网络日志中✅ 免疫只有 60 秒有效期即便历史日志记录了 Ticket UUID过时后也是一串无用的随机数。5. 总结在医疗、金融等对安全性要求极高的行业中明文或静态口令的传输是红线。本文提供的基于临时票据的单点登录方案既保证了第三方系统无需感知复杂的 OAuth2 全套认证协议又实现了“用后即焚”的安全防御为跨系统应用集成提供了一种优雅、安全的工业级标准解决方案。