📚 课程目录第4章患者身份认证与授权集成

4. 患者身份认证与授权集成

线上诊疗系统面对的患者身份问题，比普通互联网应用复杂得多。普通应用只需确认“你是账号本人”，而线上诊疗必须同时回答三个问题：你是谁（身份真实性）、你是不是参保人（医保资格）、你能访问哪些数据（授权范围）。这三者分别由实名认证、医保电子凭证、OAuth2.0/OpenID Connect 授权体系承担，并通过多因子认证把它们串成一条可信链路。

一、身份可信的三层结构

患者身份认证在工程上通常分为三层。第一层是账号层，解决“登录凭证是否正确”，常用手机号+短信验证码或密码；第二层是实名层，解决“这个账号背后是不是真实自然人”，通过姓名+身份证号二要素、或姓名+身份证号+人脸三要素核验；第三层是医保层，解决“该自然人是否具备医保结算资格”，通过医保电子凭证完成参保人身份确认与授权。

三层不是替代关系，而是叠加关系。只做账号层，无法防止冒用他人身份挂号；只做实名层，无法确认医保结算资格；只做医保层，又缺少系统内的稳定账号绑定。因此线上诊疗系统一般要求：账号登录 + 实名核验 + 医保电子凭证授权三者同时成立，才允许进入问诊与开方环节。

二、多因子认证的组合策略

多因子认证（MFA）的核心是让攻击者无法仅凭单一泄露信息完成登录。因子分为三类：知识因子（密码、PIN）、持有因子（手机、U盾、动态令牌）、生物因子（人脸、指纹）。线上诊疗中常见的组合是“密码/短信验证码（知识+持有）+ 人脸识别（生物）”。

实际工程中需要区分登录态认证与敏感操作再认证。登录时可用短信验证码+密码；但涉及查看检验报告、开具处方、医保结算等敏感操作时，应触发二次认证，例如人脸核验或医保电子凭证扫码。这样既保证体验，又满足《个人信息保护法》与医疗数据最小必要原则。

建议将认证强度与操作风险分级绑定：低风险（浏览科室、查看公告）仅需登录态；中风险（预约挂号、查看报告）需实名态；高风险（在线开方、医保结算、处方流转）需人脸或医保凭证再认证。

三、OAuth2.0 与 OpenID Connect 的分工

OAuth2.0 解决的是授权问题：患者允许第三方应用（如医院小程序）在限定范围内访问其在资源服务器（如医保平台、健康档案系统）上的数据，而不必把密码交给第三方。OpenID Connect（OIDC）在 OAuth2.0 之上增加了一层身份认证，通过 ID Token（JWT 格式）返回“谁在什么时候完成了认证”。

在线上诊疗集成中，典型角色映射如下：患者是 Resource Owner，医院小程序是 Client，医院统一认证中心是 Authorization Server，电子病历/医保系统是 Resource Server。推荐使用授权码模式 + PKCE，避免在移动端或前端暴露 client_secret。授权码流程的关键参数包括 client_id、redirect_uri、scope、state、code_challenge、code_challenge_method=S256。

GET /authorize?
  response_type=code
  &client_id=clinic-miniapp
  &redirect_uri=https%3A%2F%2Fclinic.example.com%2Fcallback
  &scope=openid%20profile%20medical_record.read
  &state=xyz123
  &code_challenge=QYPAZ5NU8yvtlQ9erXrUYRDSOWAQYweHy
  &code_challenge_method=S256

回调后，客户端用 code + code_verifier 换取 token。返回的 ID Token 中应校验 iss、aud、exp、nonce，并验证签名。Access Token 用于访问资源接口，scope 决定可访问范围。若需要长期访问，使用 Refresh Token，但必须绑定设备指纹并设置较短有效期。

四、实名认证与医保电子凭证的集成

实名认证通常调用公安或第三方核验接口，输入姓名、身份证号，可选人脸活体检测。返回结果需记录核验流水号、时间、结果码，作为合规审计依据。核验通过后，系统将账号与实名信息绑定，并标记 realname_status=verified。

医保电子凭证集成一般通过国家医保服务平台或地方医保接口完成。患者在小程序内授权后，系统获得医保电子凭证的授权码，再换取参保人信息与结算资格。关键字段包括：参保地、人员编号、参保状态、险种类型。只有参保状态为“正常参保”时，才允许走医保结算流程。

五、关键实现细节与安全边界

第一，state 与 nonce 必须校验。state 防止 CSRF，nonce 防止 ID Token 重放。两者都应使用密码学随机数，并在服务端会话中保存比对。

第二，redirect_uri 必须白名单精确匹配，禁止通配符，防止授权码被劫持到攻击者域名。

第三，Token 存储与传输。Access Token 应短有效期（如 15 分钟），Refresh Token 绑定设备并支持吊销。前端不落地 Refresh Token，由后端 BFF 层保管。

第四，实名与医保信息的脱敏。日志中身份证号只保留前 6 后 4，医保人员编号加密存储，展示时脱敏。

常见错误：把医保电子凭证授权码当作长期身份凭证反复使用；或在客户端直接校验 ID Token 而不验签。前者会导致授权码过期后流程中断，后者会让攻击者伪造身份。正确做法是每次结算前重新获取授权码，ID Token 必须在服务端验签并校验 aud 与 iss。

六、异常处理与降级策略

实名核验接口超时或返回“核验不一致”时，不应直接放行，也不应简单拒绝。建议策略：核验不一致时提示患者核对姓名与身份证号，允许重试 3 次；接口超时时进入人工审核队列，同时限制其只能浏览，不能开方与结算。医保凭证授权失败时，可降级为自费流程，但需明确告知患者并记录降级原因。

所有认证与授权事件都应写入审计日志，字段至少包括：患者 ID、事件类型（登录/实名/授权/再认证）、结果码、时间戳、IP、设备指纹、流水号。审计日志保留期限应满足医疗行业监管要求，一般不少于 3 年。

综上，患者身份认证与授权集成的本质，是把“账号—实名—医保”三层可信关系，通过 OAuth2.0/OIDC 标准协议与多因子认证策略，安全地映射到线上诊疗的每一个敏感操作上。工程实现中既要保证协议参数正确、Token 校验完整，也要设计好异常降级与审计留痕，才能在安全与体验之间取得平衡。