【问题标题】:REST API multi-tenant securityREST API 多租户安全性
【发布时间】:2019-06-05 15:59:29
【问题描述】:

我对多租户环境中的 RESTful API 和安全性有疑问。

假设你有一个端点:api/branches/:branchId/accounts/:accountId

身份验证通过Bearer Tokens (oauth2) 完成。每个令牌包括一组与调用用户相关联的声明。令牌中包含branchId 声明,每个用户都属于一个分支。

安全限制如下:

  1. GET 请求的 branchId 应该与存储在令牌声明中的那个相匹配。
  2. accountId 应该是branchId 标识的分支内的有效帐户。

问题是:以下哪个解决方案是正确的?

  1. 维护端点:api/branches/:branchId/accounts/:accountId。并进行必要的安全检查。
  2. 将endpoint改为:api/accounts/:accountId,从token中获取branchId,然后做剩下的安全检查。

该应用程序是多租户的。每个分支都是一个租户,每个用户只能访问与其单个分支相关的信息。 谢谢!

【问题讨论】:

  • +1,好问题!也很想知道答案
  • @DevarshDesai 我需要对此采取行动,所以我在下面评论了我的行动方案。请告诉我你的想法。

标签: api security rest oauth-2.0


【解决方案1】:

我需要快速做出决定,所以我将使用解决方案 1。如果有人反对或赞成,请加入讨论。

赞成的论点:

  1. 我完全同意这个答案:https://stackoverflow.com/a/13764490/2795999,使用完整的 URL 可以让您更有效地决定连接哪个数据存储,并相应地分配负载。
  2. 此外,您可以轻松实现缓存和日志记录,因为完整的 url 具有足够的描述性。
  3. 安全性和 API 的独立性。今天我使用的是 OAuth2,但也许明天我可以发送请求签名,并且因为 URL 包含满足请求的所有信息,所以它可以工作。

反对意见:

  1. 信息冗余:branchId 在 URL 上并在令牌上加密。
  2. 实施起来需要更多努力。

【讨论】:

  • 嗨,乔,希望你度过了愉快的一周!我同意你和马克对另一个 S.O 答案的回答;我认为拥有这个描述性 URL 确实对缓存有好处(无论您服务的用户数量如何,它都可以带来巨大的收益);至于信息冗余;也许这对你有利(作为检查请求是否正确的两种不同方式的一种方法),但总而言之,你似乎有一个很棒的 AP​​I 设计。请让我知道您在实施过程中面临哪些障碍以及您从中学到了什么!感谢您的时间! :0)
  • @DevarshDesai 感谢您的反馈,已经实施了解决方案 1)让我们看看它是如何进行的。当然,我可以发布一些更新!最好的。
猜你喜欢
  • 1970-01-01
  • 2020-11-17
  • 2015-09-08
  • 1970-01-01
  • 2014-04-08
  • 1970-01-01
  • 2014-04-23
  • 2012-06-16
  • 2021-02-24
相关资源
最近更新 更多