OAuth2如何获取SMART on FHIR启动上下文并返回patient参数

• Azure AD是通用OAuth2/OIDC身份提供商，原生不内置SMART on FHIR规范要求的launch上下文处理逻辑：不会自动解析请求里的launch参数、不会主动请求FHIR服务器查询launch对应的患者ID、也不会自动在token响应里追加patient字段，这些逻辑不属于OAuth2标准范畴，不是配置几个自定义作用域就能自动生效的。
• 你看到openid-configuration里仅返回4个标准OIDC作用域，是Azure AD的默认行为：它不会自动把你在「公开API」里配置的自定义作用域加到发现文档的scopes_supported字段中，这个字段默认只返回OIDC标准作用域，原生配置无法修改。
• 你之前的预期存在偏差：通用OAuth服务器没有主动调用FHIR服务器接口查询launch上下文的默认逻辑，这个能力是SMART on FHIR对授权服务器的额外要求，需要自行实现。

1. 在现有代理层实现完整SMART launch逻辑 #

你已经部署了前置代理处理authorize请求的scope格式转换，所有SMART专属逻辑都要在这层实现，不需要修改Azure AD本身的配置：

• 拦截所有发往/authorize端点的请求，校验请求中是否携带合法launch参数、是否申请了launch/patient作用域。
• 提取请求里的launch GUID值，由代理主动调用你FHIR服务器的内部接口，查询这个GUID绑定的患者ID，将「授权码/会话标识 -> 患者ID」的映射关系存在代理的缓存中。
• 完成scope格式转换（斜杠转横杠适配Azure AD要求）后，将请求转发给Azure AD走标准授权码流程。
• 拦截所有发往/token端点的请求，当客户端用合法授权码换取令牌时，先透传请求给Azure AD拿到标准token响应（包含id_token、access_token、expires_in等字段），再从缓存中取出该授权码对应的患者ID，追加patient字段到响应JSON中，再返回给客户端。

说明：你之前部署的FHIR日志测试端点没收到请求是正常现象，因为没有任何组件内置了调用该接口的逻辑，这个调用动作需要你在代理层编码实现，接口路径完全可以按你内部规则定义，不需要遵循通用约定。

2. 修复作用域识别问题 #

• 不需要纠结Azure AD原生返回的openid-configuration内容：在代理层拦截.well-known/openid-configuration请求，拿到Azure AD返回的原始配置后，手动将launch、launch/patient、patient/*.*等你需要支持的SMART作用域追加到scopes_supported数组中，再返回给SMART应用即可，应用做启动校验时就能正确识别支持的作用域。
• 补全scope格式的双向转换逻辑：除了入站请求把斜杠格式的SMART scope转成横杠格式发给Azure AD，还要在出站响应（比如token响应返回的scope字段、发现文档的scopes_supported字段）里把横杠格式的自定义scope转回SMART标准的斜杠格式，保证客户端拿到的是符合规范的内容。

3. 修正授权请求参数 #

你当前构造授权URL时使用的scope列表缺失核心作用域，需要把launch/patient加入scope：

_scopes = "launch launch/patient patient/*.* openid profile"

只有请求了launch/patient作用域，才符合SMART规范中返回患者上下文的要求。

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