OpenID 重定向与承载答案

【问题标题】：OpenID redirect vs bearerOpenID 重定向与承载
【发布时间】：2020-05-26 08:44:48
【问题描述】：

我正在用 C++ 开发一个微服务（出于低延迟的原因），并且我开始深入研究 OpenID 和 Keycloak。用 C++ 开发意味着我几乎没有对 OpenID 的库支持，但我（希望）所有的低级细节都在工作（比如正确的 JWT 验证）。我必须完成所有的通信流程并重定向自己。

作为背景。请记住这一点，因为我需要了解和实现通常库会为开发人员隐藏的细节。

我的申请中有三方：

这三者之间的一般通信：Web 客户端 W 可以是前端 UI，也可以是仅将 API 用作服务的移动设备，而无需任何类型的前端。 W 连接到微服务 A 以操作和使用其中的数据。微服务 A 与微服务 B 交换数据，反之亦然。 W不需要知道B。

到目前为止，我想到了以下架构：

如果您认为这听起来不对，请提出建议。然而，我的实际问题是需要什么样的登录流程以及我可能会错过的步骤：

是否可以在微服务 A https://servicea.local/login 上有一个登录端点，它将 Web 客户端的请求重定向到 OpenID / Keycloak。例如。 Web 客户端向 OpenID 令牌请求端点 http://127.0.0.1:8080/auth/realms/somerealm/protocol/openid-connect/token 发送用户名、密码、客户端 ID 和授权类型？
客户端是否应该获取令牌并将其作为授权令牌添加到所有后续调用中？
微服务是否应该实现回调来获取授权信息？
是否应该更改客户端以服务通信的流程，以向服务提供访问代码，该服务与访问令牌交换？

【问题讨论】：

【解决方案1】：

我的目标是建立一个架构，其中您的 C++ API 的作用只是验证令牌和提供数据。

客户端是一个单独的解决方案，需要它自己的代码来登录 + 处理授权代码和获取令牌。这不应该涉及您的 API - 所以回答您的问题：

如今，所有登录都应该通过系统浏览器进行，无论您是否正在编写其中的任何一个。此客户端代码可能不是 C++，并且通常需要比构建 API 更多的工作：

如果对我的博客有帮助的话，我的博客上有很多关于这些流程的文章和代码示例。在下面的帖子中，请注意，在 Web 客户端完成所有登录处理后，直到第 13 步才调用 API。

【讨论】：

【解决方案2】：

身份验证（委托给 Keycloak）然后获取令牌应该由您的 UI 通过直接联系 keycloak 来完成，并且该令牌应该从 UI to A to B 传递

这里是 keycloak 提供的 OIDC 端点

【讨论】：