【问题标题】:Oauth2 grant for server-to-server communication用于服务器到服务器通信的 Oauth2 授权
【发布时间】:2015-03-06 11:00:36
【问题描述】:

我在一个微服务架构中工作,它有自己的 oauth2 提供程序以允许服务交互。

我需要开发一项服务,该服务被授予访问用户资源的权限,以便对用户帐户执行内部任务。由于需要访问用户资源的服务是内部服务,因此要求用户允许访问他们自己的资源不是一个可行的解决方案。

我担心选择正确的授权来执行此任务,因为client_credentials 似乎是正确的,它似乎也用于只允许只更新服务数据,而不是访问用户资源.我认为的另一个解决方案是在用户注册时自动提供授权码,就好像用户单击了“允许”按钮一样,然后使用该code 授权执行请求。这里的缺点是每次创建具有该需求的服务时我都必须创建新的授权码,但这似乎是一个更清晰的解决方案(因为用户 XXX 的授权码只允许访问用户 XXX 的资源)。

我也明白,实现是不同的,因为标准提供了很大的灵活性,但是 在您看来,哪一个是合适的解决方案?你会怎么处理?更清楚的说法是“统计服务”是允许访问所有用户的资源还是“统计服务”是所有用户都可以访问他们的资源?

【问题讨论】:

    标签: web-services oauth oauth-2.0 microservices


    【解决方案1】:

    正如您所说,这是一个内部用例,您可以控制受资源服务器、授权服务器和访问资源的客户端保护的资源,因此您可以选择使用 client_credentials 访问用户数据。

    它类似于(或实际上是)可用于操纵用户数据的“服务帐户”。如果该服务在您的控制之下并且您信任它,即您相信它不会将其凭据泄露给其他方并且不会滥用其权力,那就可以了。由于您还可以控制客户端,因此不会有问题。

    【讨论】:

    • 好吧,我的理解是对的。您知道识别内部、受信任的客户的一些常用方法吗?因为我们已经将 client_credentials 用于第 3 方。我知道它与 OP 没有严格的关系。
    • 当凭证被分发时,您(应该)知道您是将这些凭证交给内部客户还是外部客户;因此,您将它们放在后端存储中的不同存储桶中;您甚至可以使用 internal:<.id>external:<id> 等客户端标识符将它们保存在同一个存储桶中,但仍然能够区分
    猜你喜欢
    • 2015-03-31
    • 2015-01-21
    • 1970-01-01
    • 2020-06-23
    • 2015-05-22
    • 2019-10-27
    • 1970-01-01
    • 2019-10-08
    • 2017-11-15
    相关资源
    最近更新 更多