金融科技/银行应用程序的API授权技术

Question

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

从这个意义上说，应用程序和API将是公共，并且是可访问的，因此需要以各种可能的方式授权访问它。

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

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

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

我不喜欢的是：

每个应用程序实例都有相同的irrevocable

• it obfuscated

• all

• client_secret is

• 可以很容易地通过应用程序的源代码公开，甚至是obfuscated

• all，可能会收到来自未知源的请求--

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

这类应用还有哪些其他授权技术？著名的金融科技/银行公司走哪条授权之路？

Answer 1

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

像“注册”这样不需要身份验证的端点，不需要身份验证。您也可以将访问与身份验证无关，基于来自网络的流量等等。这通常是在基础设施中完成的，您不必为此编写代码。

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

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

我确实做了一个银行后端的工作，它通过一个应用程序和一个网络用户界面(和几个管理员-uis)访问。我们不关心用户在后端使用哪个ui，我们只对用户进行身份验证。不需要认证的东西(国家清单、地址/iban解析器等)没有一个是有用的。我甚至不知道入口是节流还是操作控制，这不是我们的工作。