Azure Fluid Relay如何对应用终端用户进行身份验证与授权？

核心身份验证机制 #

Azure Fluid Relay（以下简称AFR）采用和应用用户体系解耦的令牌校验机制，不会要求你把自有应用的用户数据同步到Azure侧，所有身份校验逻辑基于你自行签发的合法令牌完成，核心流程如下：

• 首先你需要从Azure Portal获取AFR实例的租户ID、存储密钥（主/副密钥均可）、服务端点三个核心凭证，用于后续令牌的签发和校验
• 你的应用后端完成自有用户的身份校验后，按照AFR规定的格式生成JWT，用拿到的存储密钥完成签名
• 前端Fluid客户端发起容器创建、连接、读写等操作时，需要在请求头携带这张签发好的JWT
• AFR服务端收到请求后，会用对应实例的存储密钥校验JWT的合法性，验证通过后才会允许执行对应操作

JWT编码与验证规则 #

AFR使用标准HS256算法的JWT，遵循标准的header.payload.signature三层结构，各部分的要求和校验逻辑如下：

JWT Header要求 #

固定为以下内容，不支持其他签名算法：

{
  "alg": "HS256",
  "typ": "JWT"
}

JWT Payload必填字段 #

• documentId：当前操作的Fluid容器唯一ID，如果要签发全容器可用的租户管理令牌，该字段填*即可
• tenantId：你从Azure Portal获取的AFR实例租户ID
• scopes：数组类型，指定令牌的操作权限，可选值包括doc:read（只读）、doc:write（读写）、summary:write（快照生成权限）、tenant:admin（租户管理权限）
• iat：令牌签发时间的Unix时间戳（单位为秒）
• exp：令牌过期时间的Unix时间戳（单位为秒），最长有效期不能超过1小时，超出的令牌会被AFR直接判定为无效
• user：可选但推荐填写的对象字段，存储当前操作用户的身份信息（如应用内用户ID、用户名），该字段内容会在协作场景下透传给同容器的其他客户端，用于标识操作人

签名与校验逻辑 #

签名环节必须在应用后端完成，禁止把AFR存储密钥下发到前端，否则会存在令牌伪造、数据泄露的风险

• 签名密钥直接使用AFR实例提供的主密钥或者副密钥即可，两个密钥权限完全一致，你可以使用副密钥完成密钥轮换，不需要停服
• AFR服务端收到JWT后，首先会用实例存储密钥重新计算签名，和JWT携带的签名做比对，不一致直接返回401未授权
• 签名校验通过后，会依次验证有效期、租户ID、容器ID、操作权限是否匹配，全部校验通过才会允许执行请求

内容的提问来源于stack exchange，提问作者Marilee Turscak - MSFT