Rest fintech/银行应用程序上可能的API授权技术

假设我们已经实现了提供金融/银行服务的RESTful API，并希望将其提供给内部开发团队，以实现本机移动客户端应用程序

从这个意义上讲，应用程序和API将是公开的，并且可以访问，因此需要以各种可能的方式对访问它的内容进行授权

想到的第一个解决方案是提供客户端id和客户端机密，并让开发人员使用授权http头对每个请求进行签名：

Authorization: APP client_id:base64(HMAC-SHA256(content, client_secret))

只要服务器“知道”客户端的秘密，API使用授权就会顺利运行

我不喜欢的是：

• 每个应用程序实例都有相同的客户端密码
• 客户的秘密是不可撤销的
• 它可以很容易地通过应用程序的源代码公开，即使是模糊的
• 总之，从未知来源获取请求的可能性

另一方面，我不想干扰用户体验，比如重定向和额外的登录请求，比如OAuth等等

---

这类应用还有哪些其他授权技术？著名的金融科技/银行公司遵循哪种授权路径？

不要对应用程序进行身份验证，而是对使用该应用程序的用户或实体进行身份验证

像“register”这样的端点不需要身份验证，也不需要身份验证。您也可以根据流量来自的网络等，独立于身份验证来限制访问。这通常是在基础设施中完成的，您不必为此编写代码

一般来说，从安全的角度来看，发布的客户端应该被视为用户控制的。也就是说，它们生成的数据也应被视为完全由用户控制，即使是经过签名、模糊处理或其他处理

到目前为止，您还没有从后端的角度提到任何用例，在后端，对客户端软件进行身份验证将以某种方式增加价值

---

我确实在一个银行后台工作，它是通过一个应用程序和一个web ui（以及几个管理ui）访问的。我们不关心用户在后端使用哪个ui，我们只验证了用户。不需要身份验证的东西（国家/地区列表、地址/iban解析器等）在没有身份验证的情况下是可用的。我甚至不知道访问是否在操作中受到限制或控制，这不是我们的工作。

我假设用户必须以某种方式向您（您的后端）验证自己。因此，如果用户这样做，为什么需要对客户端进行身份验证？我假设您在后端验证所有内容，并检查是否允许经过身份验证的用户执行客户端提交的操作。我不明白为什么客户很重要。我遗漏了什么吗？另外，与客户端应用程序一起分发的任何内容都应被视为有效的公共内容。@RobertBräutigam正确，用户身份验证已到位。我想确定客户是“它应该是什么”。我怎么能确定呢？对于未经用户身份验证的端点，比如注册，或者进一步向第三方提供API和节流等。假设您提供了一个与您所提到的API相同的API，open。每个请求你都要收费。然后呢？没关系。问题是是否有其他方法来实现客户端授权。是的，您可以对用户进行身份验证，以了解谁在请求，但请求的内容如何。特别是对于银行应用程序，我想应该有一个符合性认证方案。我无法想象我使用REST客户端应用程序或can I玩Revolute endpoints。我位于欧盟，为多个国家的多家金融机构工作，除了用户之外，我不知道有关验证应用程序的任何合规性问题。事实上，您可以使用curl、soapui等测试我们自己的API。如果您对每个请求收费，那么您通常必须知道您向谁收费，而不管他们使用什么来访问。也许我没抓住你的重点。