OAuth 2将服务器-服务器API调用的授权与身份验证分开。
上下文
我试图为我们公司的产品设计一种访问控制解决方案，该解决方案具有以下三个属性：
- 客户可以带来他们自己的身份(从他们的IdP解决方案)，也就是我们可以联合他们的身份。这给了他们对访问的完全控制，并减轻了我们对用户的管理(这对我们的服务台来说是一个很大的工作量！)
- 我们可以集中控制客户可以使用的产品，也就是我们管理的授权。这让我们安心，我们不会冒着欺诈性使用产品的风险，并将目前处于孤立和昂贵炉管中的运行工作流集中起来。
- 我们将我们的产品与个别客户身份协议的变幻莫测隔离开来，也就是我们通过某种形式的枢纽或网关来操作，这些枢纽或网关在特定客户行为和我们的内部产品之间进行转换。这确保了所有产品都能很好地支持客户，并且只需要与网关团队进行交互，而我们的产品团队也只需要与网关团队和单个协议实现交互。
我目前的想法是在网关服务中支持OpenID连接(OIDC) / OAuth 2协议，客户IdP端点和网关之间的信任关系是通过销售/操作工作流创建的，网关和内部产品之间的信任关系是我们内部开发工作的一部分。
然后消息流变成：
- 客户从他们的IdP获得身份令牌(取决于他们如何获得)。
- 客户向我们的网关服务提供身份令牌，接收产品的访问令牌，假设它们是授权的。
- 客户提供对产品的访问令牌以获得服务。
注:这是一种与Gov.UK验证身份解决方案类似的设计，只是使用了SAML断言和由国内流离失所者和RPs组成的SAML联合会，以及我们熟悉的有关国内流离失所者之一的内容。
我还期望在稍后阶段(例如: SAML断言-> OIDC令牌)支持协议/令牌转换，或者支持具有专有身份提供机制的客户，并集成我们自己的IdP (AzureAD)以供工作人员访问。
，那么问题是什么？
当没有最终用户OAuth时，OIDC /OIDC 2似乎没有在两个系统(实际上是安全边界)之间清晰地分离身份验证和访问授权的现有流，并且在有用户的情况下它也不是设计的一部分(所有图都有一个单独的授权服务器执行这两个任务)。
我们的大多数客户将从后端调用我们的服务，没有终端用户或浏览器，因此我们不能使用支持id_tokens (或auth代码)的交互式OIDC流，只剩下client_credentials流，这只涉及访问令牌。
我是不是搞错了( OIDC/OAuth是错误的方法)？
我们是否应该将访问令牌从客户转换到网关中的其他访问令牌(因为它们不能创建id_tokens)？
我知道令牌交换(https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14)的标准草案，这有帮助吗？
回答 1
Stack Overflow用户
发布于 2020-08-22 13:59:43
我会考虑JWT和/或SAML断言授予类型。这些设计用于使用已执行用户身份验证的受信任的第三方身份提供程序发出的令牌从您的OAuth服务器获取访问令牌。这将导致如下所示的体系结构：
(4) Look up prod-
ucts +------------+
+----------->+ |
| | API/DB of |
| | products |
+----------------+ +--------------+---+ | |
| Some | | | | |
| Trusted | (3)JWT or SAML grant | Your OAuth | +---+--------+
| IDP <--+ +--------------------->+ server | |
| | | | +----------------+ <------------+
+---+------------+ | | | +--------+------+--+ (5) Allowed products
| | (1) | | (7) Access token ^ |
| OIDC, SAML | | scoped for your APIs | | (6) Burn allowed products into
| or|other | | +<-----+ access token as claims
JWT or SAML | | |
(2) token intended+----+----------+-+ | +------------------+ +----------------+
for your OAuth| +<--+ | | | +<-----+
| server | Some | | | | | |
+----------> Client +------------------->+ Your gateway +------------->+ Your APIs | ^ (11) Fine grained
| | (8) Attempt to | | (10) Attempt| | | authorization using
| | access your APIs | | to access | +------+ claims in access
+-----------------+ with your access +--+-----^---------+ APIs with +----------------+ token
token as proof of | | access token
authentication | | that's been authorized to
+-->--+ an extent
(9) Course grained
authorization using
scope, URL & HTTP method在步骤9到第10步之间，如果您不使用幻象令牌，我可能会将访问令牌转换为分裂令牌法。这将防止客户在您的访问令牌中看到只需要您自己的内部API知道的内容。
https://stackoverflow.com/questions/51619159
复制相似问题
腾讯云开发者
