【问题标题】:Securing an existing API with our own solution使用我们自己的解决方案保护现有 API
【发布时间】:2019-01-16 22:23:13
【问题描述】:

我必须设计一个与提供的 API 交互以交换数据和信息的移动应用程序,并且我已经阅读了有关 API 安全性、Oauth 2、令牌等的信息,但我仍然不清楚,以下是要点:

  • 第 3 方作为黑盒提供的 API,未实施安全措施, 因此您可以查询属于任何用户的数据。

  • 用户应该使用我们的应用程序,使用用户名/密码登录并只能访问他的数据。 (一定很 安全,因为如果安全被破坏,我们应该付出很多)

  • 解决方案需要实施和自托管,而不是来自第三方或云提供商。

API 调用示例:

....base url...../{subscriber-ID}/offers

上述调用为 ID 为 {subscriber-ID} 的订户获取合适的优惠,因此显然,在没有安全性的情况下,我可以查询任何订户的优惠,但我的目标是在用户/密码之间链接并仅查询数据与所需用户相关。

我读了很多,但我很困惑,因为我是 API 安全的新手。 那么我应该从哪里开始呢?就我而言,我如何从 Oauth 2 中受益?只需要路线图,而不是如何实施。

【问题讨论】:

    标签: api security oauth-2.0


    【解决方案1】:

    使用 Spring Security 的 oAuth2 是满足此要求的解决方案。

    oAuth2 中有 4 种授权类型,适用于不同的场景。

    1. 客户端凭据:消费者(应用程序)使用使用 apikey(或 clientId)创建的不记名令牌和仅密码调用后端。主要用于检索通用信息的匿名调用。

    2. 资源所有者密码凭证 (ROPC):消费者(应用程序)使用使用 apikey、secret、用户名和密码创建的不记名令牌进行调用。主要在您(您的授权服务器)已经知道用户(用户数据库在您自己的系统中处理)时使用。

    3. 授权码:消费者(应用程序)使用使用授权码创建的不记名令牌进行调用。授权码由第三方(实际上拥有/管理登录的用户数据)提供,并且创建的授权码链接到登录的用户。 Google 和 Facebook 登录各种网站就是一个典型的例子。 Facebook/Google 为这些网站提供了一个授权代码,然后他们用该代码交换令牌。

    4. 隐式授权:密码凭证和授权码的混合。您从第 3 方授权服务器获取不记名令牌,而不是授权码。

    我一直在寻找授权服务器的简单示例代码,但从未找到。所以,我尝试自己创建它,你可以在这里找到它:https://github.com/abbinv/oauth2Server。仅实现了 ROPC 和客户端凭据。

    这不是一个“漂亮”的代码。但我认为你会掌握基础知识。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2023-04-05
      • 2018-02-22
      • 2023-02-05
      • 2022-08-15
      • 1970-01-01
      • 2016-07-15
      • 1970-01-01
      • 2012-01-27
      相关资源
      最近更新 更多