我需要保护我的 rest api。它们会暴露给一些外部网站后端合作伙伴以及配套的移动应用程序。
我已经阅读了很多关于 api 密钥、jwt、oauth、openid 连接的资料，但我仍然对现在应该如何保护他的 api 感到困惑......
配套的移动应用程序应该是调用我的 api 的唯一外部应用程序。它应该为用户提供匿名访问以及经过身份验证的访问。当用户通过身份验证时，他可以对其数据进行更新访问。
所以有人告诉我，我的移动应用程序应该将 Oauth2 与 PKCE 一起使用：但据我了解，这只能用于保护来自移动应用程序的用户身份验证。
所以我的问题是：
【问题讨论】：
1。如何仅通过移动配套应用程序和外部网络服务器后端提供对我的 API 的公共访问？
简而言之：你不能。
您可以做的是使用一种模糊的序列化格式，将所有内容都封装在加密中，并将应用程序密钥隐藏在二进制代码的深处。但归根结底，只要攻击者有权访问您的应用程序可执行代码，就始终可以对其进行逆向工程，从而可以创建应用程序与服务器通信的忠实仿真。
2。如何处理匿名（未经身份验证的用户）消费api？
仅在用户身份验证后才允许访问 API。
然后如何验证自己的身份：为应用程序使用令牌，为用户使用令牌？
同样，如果用户有权访问应用程序可执行文件，则始终可以提取应用程序的“令牌”。
一般来说，您只能对网络上的参与者进行身份验证，而不是参与者正在使用的“设备”。
【讨论】：
在尝试解决您的问题之前，我想明确区分 WHO 和 WHAT 访问 API 服务器。
WHO 是移动应用的用户，您可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID 或 OAUTH2 流。
OAuth 2.0 是用于授权的行业标准协议。 OAuth 2.0 取代了 2006 年创建的原始 OAuth 协议所做的工作。OAuth 2.0 专注于客户端开发人员的简单性，同时为 Web 应用程序、桌面应用程序、移动电话和客厅设备提供特定的授权流程。此规范及其扩展正在IETF OAuth Working Group 内开发。
OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。 OpenID Connect 执行许多与 OpenID 2.0 相同的任务，但以 API 友好的方式执行，并且可用于本机和移动应用程序。 OpenID Connect 定义了健壮签名和加密的可选机制。虽然 OAuth 1.0a 和 OpenID 2.0 的集成需要扩展，但在 OpenID Connect 中，OAuth 2.0 功能与协议本身集成。
现在您需要一种方法来识别 什么 正在调用您的 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的东西，它真的是您真正的移动应用程序，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
为了识别什么，开发人员倾向于求助于 API 密钥，通常他们将其硬编码在他们的移动应用程序的代码中，有些人会加倍努力并在运行时计算它移动应用程序因此成为动态秘密，而不是前一种方法，即嵌入在代码中的静态秘密。
- 如何仅通过移动配套应用程序和外部网络服务器后端提供对我的 API 的公共访问？
在这种情况下 WHAT 不在客户端，因此您可以使用证书 在 Webserver 后端和 API 服务器之间固定，以保证 API 服务器可以相信传入的请求来自受信任的来源。
固定是将主机与其预期的 X509 证书或公钥相关联的过程。一旦知道或看到主机的证书或公钥，证书或公钥就与主机相关联或“固定”到主机。如果可以接受多个证书或公钥，则程序会保存一个 pinset（取自 Jon Larimer 和 Kenny Root Google I/O talk）。在这种情况下，所宣传的身份必须与 pinset 中的元素之一匹配。
在这种情况下，移动应用程序在客户端运行，因此需要一个秘密 识别 什么 正在访问 API 服务器，您可以在 this series 了解更多关于移动 API 安全技术的文章如何使用 API 密钥、用户访问令牌、HMAC 和证书固定来保护 API以及如何绕过它们。
事实上，在客户端运行的任何东西都可以被逆向工程 攻击者很容易在他控制的设备上进行攻击。他将使用Frida 或xPosed 等自省框架在运行时拦截移动应用程序的运行代码，或使用MiTM Proxy 等代理工具来监视移动应用程序与API 服务器之间的通信。通常，他们对移动应用进行逆向工程的第一步是使用Mobile Security Framework 对移动应用的二进制文件进行逆向工程，以提取所有静态机密并识别攻击向量。
Mobile Security Framework 是一种自动化的一体化移动应用程序 (Android/iOS/Windows) 渗透测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
Xposed 是一个模块框架，可以在不触及任何 APK 的情况下改变系统和应用的行为。这很好，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码没有太大更改）。它也很容易撤消。
一个交互式的支持 TLS 的拦截 HTTP 代理，供渗透测试人员和软件开发人员使用。
那么现在怎么办...我是否注定无法保护我的 API 服务器不被滥用？？？没有安静所以...希望仍然存在！！！
要解决 什么 访问您的移动应用程序的问题，您需要使用我上面提到的关于移动 API 安全技术的系列文章中提到的一个或所有解决方案，并接受它们可以只会使对您的 API 服务器的未经授权的访问更难绕过，但并非不可能。
您可以使用 WAF 或 UBA 解决方案来尝试识别和阻止对您的 API 的滥用，但是 这种方法会导致误报，因此需要一些宽松的规则和常量 监控以确保真正的用户不会被阻止使用 API。
WAF - Web Application Firewall:
Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。
UBA - User Behavior Analytics:
Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常。 UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。 Apache Hadoop 等大数据平台通过分析 PB 级数据以检测内部威胁和高级持续性威胁，正在增加 UBA 功能。
使用移动应用证明解决方案可以采用更好的解决方案，该解决方案将使 API 服务器知道只接收来自真正移动应用的请求。
使用移动应用证明解决方案将使 API 服务器能够了解发送请求的内容，从而允许仅响应来自真正移动应用的请求，同时拒绝来自不安全来源的所有其他请求。
移动应用证明服务的作用是在运行时通过在后台运行 SDK 来保证您的移动应用没有被篡改或没有在根设备中运行，该 SDK 将与在云中运行的服务进行通信以证明移动应用程序和正在运行的设备的完整性。
成功证明移动应用程序完整性后，会发出一个短期 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用证明失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每个 API 调用中发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时服务请求，并在验证失败时拒绝它们。
一旦移动应用不知道移动应用证明服务使用的秘密，即使应用被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程正在成为中间人攻击的目标。
因此，此解决方案适用于没有误报的正检测模型，因此不会阻止合法用户，同时阻止坏人。
Mobile App Attestation 服务已经作为 SAAS 解决方案存在于Approov（我在这里工作），它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行小检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求和拒绝哪些请求是必要的。
- 如何处理匿名（未经身份验证的用户）使用 api？
因此，您似乎只关心 什么 正在访问您的 API，因此您 需要从我在问题 1 中提到的解决方案中决定要使用哪些解决方案。
- 然后如何验证自己：为应用程序使用令牌，为用户使用令牌？
是的，您应该始终知道 什么 和 谁 正在访问您的 API 服务器。所以 对于 WHO 用户，我建议使用 OAUTH2 或 OpenID Connect，并且 对于 WHAT、移动应用程序和网络服务器，您只需从我的解决方案中选择您想要使用的解决方案 问题 1 中提到。
最终，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择用于保护您的 API 服务器的解决方案。
【讨论】：