你的问题

我在 dot net 中开发了 API。此 API 由不同的应用程序使用。我必须为此 API 使用的每个应用程序生成不同的密钥。

创建 API 时，无论是由一个或多个应用程序使用，您都需要处理访问 API 的对象是什么，有时您还需要关心访问 API的对象是谁。

考虑到这一点，让我们清除开发人员对WHO和WHAT访问 API 服务器的常见误解。

访问 API 服务器的 WHO 和 WHAT 之间的区别

我不知道使用 API 的应用程序是移动的还是基于 Web 的，但我将使用移动应用程序进行类比，对于 Web 应用程序来说，WHO和WHAT之间的区别不会有任何区别。

为了更好地理解WHO和WHAT访问移动应用程序之间的区别，让我们使用这张图片：

中间人攻击

Intended Communication Channel 表示移动应用程序正按您的预期被合法用户使用，没有任何恶意，使用未经篡改的移动应用程序版本，并直接与 API 服务器通信而不会受到中间人的攻击。

实际渠道可能代表几种不同的场景，例如怀有恶意的合法用户可能正在使用重新打包的移动应用程序版本，黑客使用移动应用程序的正版版本，而中间人攻击它，以了解如何移动应用程序和 API 服务器之间的通信正在完成，以便能够自动攻击您的 API。许多其他情况也是可能的，但我们不会在这里一一列举。

我希望现在你可能已经知道为什么WHO和WHAT不一样，但如果不是，一会儿就会清楚。

WHO是移动应用程序的用户，我们可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

认证

通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。OAuth 专为与超文本传输协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端。然后第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID 连接

OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。

虽然用户身份验证可以让 API 服务器知道谁在使用 API，但它不能保证请求来自您所期望的，即移动应用程序的原始版本。

现在我们需要一种方法来识别是什么在调用 API 服务器，而这里的事情变得比大多数开发人员想象的要复杂得多。什么是向 API 服务器发出请求的东西。它真的是移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动探索 API 服务器？

令您惊讶的是，您最终可能会发现它可能是使用重新打包的移动应用程序版本或试图游戏化并利用应用程序提供的服务的自动化脚本的合法用户之一。

好吧，为了识别WHAT，开发人员倾向于求助于 API 密钥，通常他们将其硬编码在他们的移动应用程序的代码中。一些开发人员加倍努力并在运行时在移动应用程序中计算密钥，因此它成为运行时机密，而不是前一种方法，即在代码中嵌入静态机密。

上面的文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？，您可以在此处完整阅读，这是有关 API 密钥的系列文章中的第一篇。

保卫 API 服务器

任何人都可以分享他们的想法。

移动应用程序或 Web 应用程序应仅与您控制的 API 服务器通信，并且对第三方 API 服务的任何访问都必须由您控制的同一 API 服务器完成。

通过这种方式，您可以将攻击面限制在一个地方，在那里您将使用尽可能多的防御层来保护您所保护的东西。

对于服务于 Web 应用程序的 API，您可以使用多个密集层，从reCaptcha V3开始，然后是Web 应用程序防火墙(WAF)，最后如果您负担得起的话，可以使用用户行为分析(UBA) 解决方案。

谷歌验证码 V3：

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与您的网站的交互返回一个分数，并为您提供更多的灵活性来采取适当的行动。

WAF - Web 应用程序防火墙：

Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全配置错误。

UBA - 用户行为分析：

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、有针对性的攻击和金融欺诈的网络安全流程。UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。Apache Hadoop 等大数据平台正在增加 UBA 功能，允许它们分析 PB 级的数据以检测内部威胁和高级持续性威胁。

所有这些解决方案都基于否定识别模型工作，换句话说，他们尽力通过识别什么是坏的而不是什么来区分好坏，因此尽管使用了先进的技术，但它们很容易出现误报其中一些，比如机器学习和人工智能。

因此，您可能会发现自己经常不得不放松如何阻止对 API 服务器的访问，以免影响好的用户。这也意味着该解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们是否正确阻止了未经授权的用户。

对于服务于移动应用程序的 API，可以通过使用移动应用程序证明解决方案来使用积极的识别模型，该解决方案向 API 服务器保证请求可以被信任，而不会出现误报。

移动应用认证

移动应用程序证明服务的作用是在运行时通过在后台运行 SDK 来保证您的移动应用程序没有被篡改或没有在有根设备中运行，该 SDK 将与在云中运行的服务进行通信以证明移动应用程序和设备的完整性正在运行。

成功证明移动应用程序完整性后，会发布一个短期 JWT 令牌，并使用只有云中的 API 服务器和移动应用程序证明服务知道的秘密进行签名。如果移动应用程序证明失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。

现在，应用程序必须在每个 API 调用中发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时服务请求，并在验证失败时拒绝它们。

一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改、在有根设备中运行或通过正中间人攻击的目标。

Mobile App Attestation 服务已经作为Approov（我在这里工作）的 SAAS 解决方案存在，它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行小检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求和拒绝哪些请求是必要的。

概括

我认为现在应该很清楚，您需要为每个应用程序使用 API 密钥来识别WHAT，如果您关心WHO您应该使用 OAUTH 解决方案，然后选择您想要的防御层放置在 API 服务器上，以确保您确实知道正在访问 API 服务器的WHAT和WHO确实是您所期望的。

最后，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择用于保护您的 API 服务器的解决方案。

因此，使用 API 密钥可能听起来像是锁住你家的门并将钥匙留在垫子下，但不使用它们就像让你的车停在门关闭的情况下，但钥匙在点火装置中。

加倍努力

这是我第一次做这样的任务。

所以我真的建议你阅读一些链接......

网络应用

OWASP Web 十大风险

OWASP Top 10 是一个强大的 Web 应用程序安全意识文档。它代表了对 Web 应用程序最关键的安全风险的广泛共识。项目成员包括来自世界各地的各种安全专家，他们分享了他们的专业知识来制作此列表。

移动应用

OWASP 移动安全项目 - 十大风险

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

api-key - 需要为不同的应用程序生成 API 密钥

问题描述

解决方案