用于保护 REST API 的 OAuth2 流程答案

【问题标题】：OAuth2 flow for securing a REST API用于保护 REST API 的 OAuth2 流程
【发布时间】：2021-01-24 05:44:56
【问题描述】：

我有用于多个应用程序（网页和 REST API）的身份验证和授权的 Keycloak。据我了解，使用 OAuth2 authentication_code 授权类型时网页的流程如下：

在此流程中，在第二步（红色部分）中，资源所有者登录，因为她/他被重定向到 Keycloak 的登录页面。这个流程对我来说很清楚并且运行良好。

但是，使用 REST API，我不知道验证和授权用户（资源所有者）的过程是什么，因为没有浏览器将他重定向到 Keycloak 的登录页面。因此，我尝试使用 password 授权类型并且它有效，但后来我意识到这种授权类型已被弃用。所以我再次尝试使用authorization_code 授权类型，但无法使其工作。我正在尝试使用以下请求获取令牌：

网址： http://localhost:8080/auth/realms/somerealm/protocol/openid-connect/token

主体：

username: someuser
passwoord: somepassword
grant_type: authorization_code
client_id: someclient
secret: somesecret

问题是我收到以下回复：

{
    "error": "invalid_request",
    "error_description": "Missing parameter: code"
}

我知道我的请求有问题（以及我对 OAuth2 的理解），但我阅读了很多内容，但无法发现它是什么。

【问题讨论】：

标签： oauth-2.0 openid-connect

【解决方案1】：

API（后端）通常不需要任何登录流程。它只需要验证令牌，然后执行请求的操作或拒绝它（响应代码 401 - 身份验证问题 / 403 - 授权问题）。它不会重定向到身份验证服务器。

使用 API 的客户端必须在 API 请求之前获取令牌。它可以由前端完成（例如带有The Authorization Code Flow + PKCE 的 SPA），然后前端维护状态（令牌刷新、来自 API 的错误代码......）。

如果您没有任何前端，那么如何获取令牌的过程必须是 API 规范的一部分。例如参见 swagger 文档：https://swagger.io/docs/specification/authentication/oauth2/

Client credentials flow 应该使用machine to machine 身份验证，所以如果您需要知道用户身份，这不是一个解决方案。

【讨论】：

client_credentials flow 是 OAuth2 组推荐替换password。仅供参考。不再只是机器对机器。
@Evert 你有任何链接/文档吗？为每个用户的客户端凭据流配备一个专用客户端听起来不是一个好主意。
这在 oauth2 邮件列表中被广泛讨论。我没有与讨论的直接链接。这可能需要一些狩猎。不过，“专用客户端”是一个实现细节，OAuth2 服务器可以将client_credentials 映射到其他一些功能，而不需要看起来像“客户端”的东西。 oauth2 组更重要的一点是，完全摆脱这一点，尝试只使用authorization_code。

【解决方案2】：

使用authorization_code 授权类型，您拥有以某种方式生成浏览器。

password 很遗憾已被弃用，但建议现在在这些情况下使用client_credentials。我希望这个决定在 OAuth 2.1 发布之前得到扭转。

【讨论】：

对于客户端凭据授权类型，我必须为每个用户创建一个客户端才能识别它们？
@Jucaalpa 这是 OAuth2 推荐的替代 password。 keycloak 可能会让这变得困难。使用password 确实没有真正的缺点，所以我建议继续使用它，直到client_credentials 更有用为止。