在发送HTTPS请求时，从安全性的角度来看，标头和邮件正文之间有什么区别吗？还有一个更容易泄漏或拦截吗？如果是这样，为什么？
我已经阅读了GET与POST的比较，以及各种身份验证和加密方案之间的比较，但与Header与application / x-www-form-urlencoded Post正文无关。我承认我只花了大约20分钟的时间进行了谷歌搜索和搜索，因此如果以前已经解决过这个问题，我们深表歉意。
虽然我认为这对所有HTTPS流量都是通用的，但我是在OpenId Connect上下文中询问的。我正在使用授权码授予类型和Spring Security OAuth客户端库。
OIDC规定客户端和授权服务器在将一次性代码交换为持久性ID令牌时可以选择发送凭证的方法。引用openid.net openid-connect-core section 9. Client Authentication：
本节定义了一组客户端身份验证方法，它们是 在使用时由客户端用于向授权服务器进行身份验证 令牌端点。在客户注册期间，RP（客户）可以 注册客户端身份验证方法。如果未注册任何方法， 默认方法是client_secret_basic。
这些客户端身份验证方法为：
client_secret_basic
已收到client_secret值的客户端 来自授权服务器的授权 符合OAuth 2.0 [RFC6749]第2.3.1节的服务器，使用 HTTP基本身份验证方案。
请注意，这是Authorization: Basic <value>标头。我与之集成的提供程序通过OpenId client_id和client_secret与冒号并以Base64编码的方式进行连接来支持此操作。
client_secret_post
客户 已从授权服务器接收到client_secret值， 根据本节与授权服务器进行身份验证 OAuth 2.0 [RFC6749]的2.3.1（在请求正文中包含客户端凭据）。
我无法找到任何特定于OpenId Connect的东西来表达这两种方法之间的偏好。
我正在与允许使用任何一种方法的OIDC提供程序集成，但是您必须选择并且所有从属资源服务器都必须符合单个选择。标题和帖子正文均以纯文本形式发送。 （请注意，此提供程序既不支持作为敏感机密的HMAC SHA编码版本的client_secret_jwt方法，也不支持作为公私签名的private_key_jwt方法，这两种方法显然比本质上更安全纯文本值，但尚不清楚这是否对TLS / SSL加密的通信增加了实际的安全性。）
答案 0 :(得分：2)
OAuth 2.0首选HTTP Basic身份验证，而states对此有以下建议：
建议不要使用两个参数在请求正文中包含客户端凭据，并且应仅限于无法直接利用HTTP基本身份验证方案（或其他基于密码的HTTP身份验证方案）的客户端。
您可以放心地认为这也可以转换为OIDC。
答案 1 :(得分：1)
虽然Pieter指出了规范，但我也对最佳实践有一个想法。
鉴于帖子正文可以包含任何信息，因此无法使用浏览器，代理实现或API来尊重正文中嵌入的机密。相比之下，Authorization标头由RFC7235定义和维护，这是一个标准。
“授权”标头字段允许用户代理进行身份验证 本身带有原始服务器-通常（但不一定）在 收到401（未经授权）响应。其值包括 包含用户身份验证信息的凭据 所请求资源领域的代理。
有关代理的更多信息，
转发请求的代理不得修改任何授权字段 在该请求中。有关和的详细信息，请参见[RFC7234]的3.2节。 与处理授权字段有关的要求 HTTP缓存。
因此，成为许多各方公认的标头应该使其成为传输凭据的最安全的方法。希望这种想法可以帮助其他人做出设计决定。