SAP-Gmail OAuth2集成Raw格式请求报Google API签名错误的解决问询

你观察到的“两种提交模式组装的HTTP报文实质完全一致”存在感知偏差，差异来自隐式编码规则：

• x-www-form-urlencoded提交时，客户端会自动对表单值做RFC标准转义，服务端接收后会执行对应的解码逻辑：将%2B还原为字符+，将裸写的+解码为空格。
• Raw格式提交时，客户端不会自动触发这套转义逻辑，你直接携带含裸+字符的JWT签名提交时，Google侧会按照Body的Content-Type对应的规则解码，把Body里所有裸写的+直接当成空格处理，导致签名串和本地生成的原始串不一致，触发java.security.SignatureException: Invalid signature for token报错。

• 在SAP侧构造请求Body的代码环节，主动对JWT assertion字段值做定向转义：将JWT全串中所有出现的+字符替换为%2B。这套转义完全匹配x-www-form-urlencoded的编码规则，Google侧解码Raw Body时会自动将%2B还原为原始的+字符，和正常表单提交的解析结果完全等价。
• 强制将Raw提交的请求头Content-Type设置为application/x-www-form-urlencoded; charset=UTF-8，不要使用SAP Raw模式默认的text/plain类型——如果Content-Type不对，Google侧会跳过表单格式的转义解析，直接逐字符读取Body内容，提前做的转义会被当成普通字符串处理失效。
• 本地校验环节，打印最终组装完成的Raw Body原文，逐字符比对JWT签名段的内容：确认原签名中所有+都被替换为%2B，没有出现漏替换、也没有重复替换为%252B的问题。

避坑提示：不要为了规避+字符修改本地JWT的签名生成流程，Google端的签名校验是基于服务账号公钥做完整签名串比对的，任何对签名内容的篡改都会直接触发校验失败，只需要在传输层做匹配服务端解码规则的转义即可。

内容的提问来源于stack exchange，提问作者SAP Test Diligent