client_id 和 client_secret 通过 param vs in url 发送答案

【问题标题】：client_id and client_secret sent via param vs in urlclient_id 和 client_secret 通过 param vs in url 发送
【发布时间】：2018-05-19 15:07:14
【问题描述】：

在尝试访问某些受保护的端点时，我的 Oauth2 服务器 (Spring) 出现了一些问题。

如果我想获得一个令牌（通过 Zuul 网关），我会这样做：

http://localhost:4444/auth/oauth/token?client_id=gateway&client_secret=1234&grant_type=password&username=user&password=password

（假设上述客户端和用户正确存在，Content-Type 为 application/x-www-form-urlencoded）。

这个调用不起作用，但是，如果我这样做：

gateway:1234@localhost:4444/auth/oauth/token?grant_type=password&username=user&password=password

然后，它起作用了。

这是否被视为正常行为？据我所知，这应该有效。就像当我将它们作为参数发送时没有处理 id 和秘密但是当我修改 url 时，它被占用并且一切正常。我需要实现一些额外的东西吗？

澄清一下，当我像在第二个 url 中一样发送 client_id 和 client_secret 时，Oauth2 服务器可以工作，但如果我将它们作为参数（第一个 url）发送，则不会。

您可以在此处查看代码（OAuth2-service）：https://github.com/otamega93/CloudBasedUserRegistration2/tree/master/OAuth2-service

配置主要在 OAuth2Configuration、WebSecurityConfig 和 AuthServerApplication。我正在用 Postman 进行测试。当我直接访问 Oauth2 服务器时也会发生这种情况。

【问题讨论】：

我使用邮递员生成了一个Authorization 标头（我猜你有一个错字），现在确实可以工作了。你能向我解释一下吗？比如为什么需要这个，我得到的Authorization:Basic Z2F0ZXdheToxMjM0是什么意思，URL中的gateway:1234代表什么？文档被欣然接受。另外，您应该正确回答问题，以便我接受。谢谢！

标签： spring spring-security oauth oauth-2.0 spring-security-oauth2

【解决方案1】：

令牌端点 (oauth/token) 受到保护，请参阅TokenEndpoint：

客户端必须使用 Spring Security Authentication 进行身份验证才能访问此端点，并且客户端 ID 是从身份验证令牌中提取的。最好的安排方式（根据 OAuth2 规范）是使用标准 Spring Security 支持的 HTTP 基本身份验证。

看看OAuth 2 Developers Guide:

默认情况下，Spring OAuth 在 @Configuration 支持中使用客户端密码的 HTTP 基本身份验证为您保护令牌端点。这不是 XML 中的情况（因此应该明确保护它）。

客户端必须使用基本身份验证方案进行身份验证，因此客户端必须在请求中添加Authorization 标头，请参阅RFC 2617：

为了接收授权，客户端发送用户名和密码，在 base64 [7] 中，由单个冒号 (":") 字符分隔凭据中的编码字符串。
 basic-credentials = base64-user-pass
 base64-user-pass  = <base64 [4] encoding of user-pass,
                     except not limited to 76 char/line>
 user-pass   = userid ":" password
 userid      = *<TEXT excluding ":">
 password    = *TEXT
用户 ID 可能区分大小写。

如果用户代理希望发送用户 ID“Aladdin”和密码 “芝麻开门”，它将使用以下头字段：
 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

您的第一个请求不包含 Authorization 标头。

您的第二个请求包含一个带有“userinfo”子组件的 URL，请参阅RFC 3986：

userinfo 子组件可能包含一个用户名，并且，可选地，有关如何获得访问权限的特定于方案的信息资源。用户信息（如果存在）后跟将其与主机分隔开的商业符号 ("@")。

【讨论】：