我在dot net中开发了API。此API由不同的应用程序使用。我必须为此API使用的每个应用程序生成不同的密钥。任何人都可以分享他们的想法。这是我第一次做这样的任务。
我在dot net中开发了API。此API由不同的应用程序使用。我必须为此API使用的每个应用程序生成不同的密钥。
在创建API时，无论是否由一个或多个应用程序使用，您都需要处理访问API的事实，有时您还需要关心WHO是否正在访问它。
考虑到这一点，让我们清楚开发人员之间关于WHO的常见误解，以及访问API服务器的内容。
我不知道使用API的应用程序是移动应用程序还是基于Web的应用程序，但我将使用移动应用程序进行类比，而对于Web应用程序，WHO和WHAT之间的差异将没有任何区别。
为了更好地理解WHO和WHAT之间的差异，访问移动应用程序，让我们使用这张图片：
预期通信渠道代表移动应用程序按照您的预期使用，由合法用户使用，没有任何恶意，使用未经过篡改的移动应用程序版本，并直接与API服务器通信而不会受到中间人的攻击。
实际频道可能代表几种不同的场景，例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本，黑客使用正版移动应用程序，而中间人攻击它，以了解如何移动应用程序和API服务器之间的通信正在进行，以便能够自动攻击您的API。许多其他方案都是可能的，但我们不会在此列举每一个方案。
我希望到现在为止你可能已经知道为什么WHO和WHAT不一样，但如果不是，它会在一瞬间变得清晰。
WHO是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和识别，例如使用OpenID Connect或OAUTH2流程。
通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。 OAuth专门设计用于超文本传输协议（HTTP），实质上允许授权服务器在资源所有者的批准下向第三方客户端发出访问令牌。然后，第三方使用访问令牌访问资源服务器托管的受保护资源。
OpenID Connect 1.0是OAuth 2.0协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，以及以可互操作和类似REST的方式获取有关最终用户的基本配置文件信息。
虽然用户身份验证可能让API服务器知道WHO正在使用API，但它无法保证请求源自您期望的移动应用程序的原始版本。
现在我们需要一种方法来识别什么是调用API服务器，这里的事情变得比大多数开发人员想象的更棘手。什么是向API服务器发出请求的事情。它是真正的移动应用程序的真实实例，还是机器人，自动脚本或攻击手动使用API服务器，使用像Postman这样的工具？
为了您的惊喜，您可能最终发现它可能是使用重新打包版本的移动应用程序的合法用户之一，或者是尝试游戏化并利用应用程序提供的服务的自动脚本。
好吧，为了确定什么，开发人员倾向于使用API密钥，通常他们在他们的移动应用程序的代码中进行硬编码。一些开发人员在移动应用程序中更加努力地在运行时计算密钥，因此当代码中嵌入静态秘密时，它变为运行时机密，而不是前一种方法。
上面的文章是从我写的一篇文章中提取的，题为“你的移动应用程序需要什么样的API密钥？”，你可以阅读完整的here，这是关于API密钥的系列文章的第一篇文章。
任何人都可以分享他们的想法。
移动应用程序或Web应用程序应仅与您控制的API服务器通信，并且任何对第三方API服务的访问必须由您控制的同一API服务器完成。
通过这种方式，您可以将攻击面限制在一个地方，在那里您将使用尽可能多的防御层，因为您保护的是值得的。
对于服务于Web应用程序的API，您可以使用多个密集层，从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果您能够负担得起User Behavior Analytics（UBA）解决方案。
谷歌reCAPTCHA V3：
reCAPTCHA是一项免费服务，可以保护您的网站免受垃圾邮件和滥用。 reCAPTCHA使用先进的风险分析引擎和自适应挑战，以防止自动化软件在您的网站上进行滥用活动。这样做可以让您的有效用户轻松通过。
...帮助您在没有任何用户摩擦的情况下检测网站上的滥用流量。它会根据与您网站的互动返回分数，并为您提供更大的灵活性来采取适当的措施。
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这样的大数据平台正在增加UBA功能，允许他们分析数PB的数据来检测内部威胁和高级持续性威胁。
所有这些解决方案都基于否定识别模型工作，换句话说，他们尽力识别坏东西，而不是好东西，从而尽管使用了先进的技术，但它们很容易出现误报。其中一些，如机器学习和人工智能。
因此，您可能会发现自己不得不放松阻止访问API服务器的方式，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时他们正确地阻止未经授权的用户。
关于为移动应用程序提供服务的API，可以使用移动应用程序证明解决方案来使用正面识别模型，该解决方案向API服务器保证可以信任请求而不会出现误报。
移动应用证明服务的作用是在运行时保证您的移动应用未被篡改或未在根设备中运行，方法是在后台运行SDK，该SDK将与云中运行的服务进行通信以证明正在运行移动应用和设备的完整性。
在成功证明移动应用程序完整性时，会发布短时间JWT令牌，并使用只有API服务器和云中的移动App证明服务才知道的秘密进行签名。在移动应用证明失败的情况下，JWT令牌使用API服务器不知道的秘密进行签名。
现在，应用程序必须在每次API调用时发送请求标头中的JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时提供请求，并在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用证明服务使用的秘密，即使应用程序被篡改，在有根设备中运行或通过正在进行的连接进行通信，也无法在运行时对其进行反向工程。中间人攻击的目标。
移动应用证明服务已作为SAAS解决方案存在于Approov（我在这里工作），该解决方案为多个平台提供SDK，包括iOS，Android，React Native等。集成还需要对API服务器代码进行少量检查，以验证云服务发出的JWT令牌。此检查对于API服务器能够决定要提供哪些请求以及拒绝哪些请求是必要的。
我认为现在应该很清楚你需要为每个应用程序使用API密钥来识别WHAT，如果你关心WHO，你应该使用OAUTH解决方案，然后选择你想要的防御层。在API服务器上安装以确保您确实知道WHAT和WHO正在访问API服务器的确是您期望的。
最后，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的GDPR法规）选择用于保护API服务器的解决方案。
所以使用API键可能听起来像锁住你家的门并把钥匙留在垫子下面，但不使用它们喜欢让你的车停在车门关闭的地方，但钥匙在点火时。
这是我第一次做这样的任务。
所以我真的建议你阅读一些链接......
OWASP Top 10是一个用于Web应用程序安全性的强大感知文档。它代表了对Web应用程序最关键的安全风险的广泛共识。项目成员包括来自世界各地的各种安全专家，他们分享了他们的专业知识以生成此列表。
OWASP Mobile Security Project - Top 10 risks
OWASP移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供发展控制，以减少其影响或剥削的可能性。