6. Privacy Considerations (隐私考虑)

由于JWT访问令牌通过值携带信息, 现在客户端甚至最终用户都可以直接查看未加密令牌的令牌声明集合内部.

客户端禁止 (MUST NOT) 检查访问令牌的内容: 授权服务器和资源服务器可能随时决定更改令牌格式 (例如, 通过从此配置文件切换到不透明令牌 (Opaque Token)); 因此, 客户端中任何依赖于读取访问令牌内容的能力的逻辑都将无法恢复地中断. OAuth 2.0框架假定客户端将访问令牌视为不透明的. 授权服务器的管理员还应该考虑到访问令牌的内容对客户端可见. 每当客户端访问访问令牌内容对给定场景存在隐私问题时, 授权服务器需要采取明确的步骤来防止它们.

在JWT访问令牌对最终用户可访问的场景中, 应该评估是否可以在不违反隐私的情况下访问信息 (例如, 最终用户是否只是访问自己的个人信息), 或者是否必须采取措施来强制保密.

防止向客户端和最终用户泄露信息的可能措施包括: 加密访问令牌、加密敏感声明、省略敏感声明或不使用此配置文件, 以及回退到不透明访问令牌.

在任何场景中, JWT访问令牌的内容最终都将可供资源服务器访问. 重要的是评估资源服务器是否获得了访问以声明形式接收的任何内容的适当权利, 例如, 通过某种形式的用户同意、与运营授权服务器的组织的政策和协议等. 例如, 用户可能不希望同意向给定资源服务器授予关于第2节 (及其子节) 中枚举的任何非必需声明的信息.

此配置文件要求每个JWT访问令牌中存在 "sub" 声明, 使资源服务器能够依赖该信息将传入请求与为经过身份验证的主体 (Principal) 本地存储的数据相关联. 尽管在许多场景中设计上可能需要关联请求的能力, 但在某些场景中, 授权服务器可能希望防止关联. 授权服务器应该根据隐私影响评估来填充 "sub" 声明. 例如, 如果解决方案需要防止跟踪跨多个资源服务器的主体活动, 授权服务器应该确保用于不同资源服务器的JWT访问令牌具有不同的 "sub" 值, 在资源服务器串通的情况下无法关联. 类似地, 如果解决方案需要防止资源服务器在资源本身内关联主体的活动, 授权服务器应该为签发的每个JWT访问令牌分配不同的 "sub" 值. 反过来, 客户端应该为对资源服务器的每次调用获取新的JWT访问令牌, 以确保资源服务器在每次调用时接收不同的 "sub" 和 "jti" 值, 从而防止不同请求之间的关联.