在回答您的问题之前，我认为重要的是，首先我们要澄清开发人员之间的一个常见误解，即WHO and WHAT正在访问 API。
与您的 API 服务器通信的人与物之间的区别
为了更好地理解之间的差异WHO和WHAT正在访问您的移动应用程序，让我们使用这张图片：
预期通信通道代表您的移动设备按您的预期使用，由合法用户使用，没有任何恶意，使用您的移动应用程序的未篡改版本，并直接与您的 API 服务器通信，而不会受到中间人攻击。
实际渠道可能代表几种不同的场景，例如具有恶意意图的合法用户可能正在使用您的移动应用程序的重新打包版本，黑客使用您的移动应用程序的正版，而中间人对其进行攻击以了解通信方式移动应用程序和 API 服务器之间的交互正在完成，以便能够自动攻击您的 API。许多其他场景也是可能的，但我们不会在这里一一列举。
我希望现在你可能已经知道为什么WHO和WHAT不一样，但如果不一样，一会儿就会清楚。
The WHO是移动应用程序的用户，我们可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
OAUTH https://en.wikipedia.org/wiki/OAuth
一般来说，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而无需共享其凭据的流程。 OAuth 专为与超文本传输协议 (HTTP) 配合使用而设计，本质上允许授权服务器在资源所有者的批准下向第三方客户端颁发访问令牌。然后，第三方使用访问令牌来访问资源服务器托管的受保护资源。
OpenID 连接 https://openid.net/connect/
OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。
虽然用户身份验证可能会让您的 API 服务器知道WHO正在使用 API，它不能保证请求源自WHAT您期望的，您的移动应用程序。
现在我们需要一种方法来识别WHAT正在调用您的 API 服务器，这里事情变得比大多数开发人员想象的更加棘手。这WHAT是向 API 服务器发出请求的东西。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动侵入您的 API 服务器？
令您惊讶的是，您最终可能会发现，它可能是您的合法用户之一，使用您的移动应用程序的重新打包版本或尝试游戏化并利用您的服务的自动化脚本。
那么，要识别WHAT，开发人员倾向于使用 API 密钥，通常他们将其硬编码在移动应用程序的代码中。一些开发人员付出了额外的努力，在移动应用程序的运行时计算密钥，因此它成为运行时秘密，而不是当静态秘密嵌入到代码中时的前一种方法。
以上内容摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？，并且您可以完整阅读here https://blog.approov.io/why-does-your-mobile-app-need-an-api-key，这是有关 API 密钥的系列文章中的第一篇文章。
你的问题
我已经为登录的用户设置了身份验证，只能访问 API，但是，如何防止他们从任何地方登录？
If by logging in from anywhere你的意思是任何物理位置，那么你可以使用@hanshenrik建议的IP地址阻止，但如果你的意思是阻止其他应用程序的日志记录，那不是你为其颁发API密钥的应用程序，那么你有一个非常你手中的难题需要解决，这就引出了你的第一个问题：
我已经设置了一个带有身份验证的 API，但我只想允许某些应用程序和网站访问它。我该怎么办？
这将取决于是否WHAT访问 API 的是 Web 或移动应用程序。
Web应用程序
在网络应用程序中，我们只需要使用浏览器开发工具检查源代码，或者右键单击查看页面源代码并搜索 API 密钥，然后在任何工具中使用它，例如 Postman 或我们想要的任何类型的自动化，只需复制我们在浏览器的网络选项卡中看到的调用即可。
对于为 Web 应用程序提供服务的 API，您可以使用多层密集层，从验证码 V3 https://www.google.com/recaptcha/intro/v3.html， 其次是网络应用防火墙 https://en.wikipedia.org/wiki/Web_application_firewall（WAF）最后，如果你能负担得起用户行为分析 https://en.wikipedia.org/wiki/User_behavior_analytics（UBA）解决方案。
Google 验证码 V3 https://www.google.com/recaptcha/intro/v3.html:
reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用行为的侵害。 reCAPTCHA 使用先进的风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它可以做到这一点，同时让您的有效用户轻松通过。
...帮助您检测网站上的滥用流量，而不会造成任何用户摩擦。它会根据与您网站的交互返回一个分数，并为您提供更大的灵活性来采取适当的操作。
WAF - Web应用程序防火墙 https://en.wikipedia.org/wiki/Web_application_firewall:
Web 应用程序防火墙（或 WAF）过滤、监视和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙则充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全缺陷的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。
UBA-用户行为分析 https://en.wikipedia.org/wiki/User_behavior_analytics:
Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常，即表明潜在威胁的异常。 UBA 不跟踪设备或安全事件，而是跟踪系统的用户。 Apache Hadoop 等大数据平台正在增强 UBA 功能，允许它们分析 PB 级数据以检测内部威胁和高级持续威胁。
所有这些解决方案都基于负面识别模型，换句话说，它们尽力通过识别来区分好坏WHAT是坏的，不是WHAT是好的，因此尽管其中一些使用了机器学习和人工智能等先进技术，但它们很容易出现误报。
因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着该解决方案需要持续监控，以验证误报不会阻止合法用户，同时正确阻止未经授权的用户。
移动应用程序
来自您对评论的回复：
那么移动应用程序呢？
有些人可能认为，一旦移动应用程序以二进制格式发布，其 API 密钥就会安全，但事实证明并非如此，从二进制文件中提取它有时几乎与从 Web 应用程序中提取它一样简单。
通过大量的开源工具，例如移动安全框架 (MobSF)、Frida、XPosed、MitmProxy 等，可以轻松对移动应用程序进行逆向工程，但正如您在本文 https://blog.approov.io/how-to-extract-an-api-key-from-a-mobile-app-with-static-binary-analysis，可以使用 MobSF 或使用strings安装在普通 Linux 发行版中的实用程序。
移动安全框架 https://github.com/MobSF/Mobile-Security-Framework-MobSF
移动安全框架是一种自动化、一体式移动应用程序 (Android/iOS/Windows) 笔测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。
Frida https://www.frida.re/
将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。
xPosed https://repo.xposed.info/module/de.robv.android.xposed.installer
Xpose 是一个模块框架，可以在不接触任何 APK 的情况下更改系统和应用程序的行为。这很好，因为这意味着模块可以适用于不同的版本，甚至无需任何更改的 ROM（只要原始代码没有更改太多）。它也很容易撤消。
中间人代理 https://github.com/mitmproxy/mitmproxy/
为渗透测试人员和软件开发人员提供的交互式、支持 TLS 的拦截 HTTP 代理。
对于为移动应用程序提供服务的 API，可以通过使用移动应用程序证明解决方案来使用积极的识别模型，该解决方案向 API 服务器保证WHAT使请求可以被信任，而不存在误报的可能性。
移动应用程序认证
移动应用程序证明服务的作用是在运行时保证您的移动应用程序未被篡改或未在获得 root 权限的设备中运行，方法是在后台运行 SDK，该 SDK 将与云中运行的服务进行通信以证明您的移动应用程序的安全性。移动应用程序和设备运行的完整性。
成功证明移动应用程序完整性后，会发出一个短暂的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用程序认证失败，JWT 令牌将使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每次 API 调用时发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时才服务请求，并在验证失败时拒绝请求。
一旦移动应用程序不知道移动应用程序证明服务使用的秘密，就不可能在运行时对其进行逆向工程，即使应用程序被篡改、在 root 设备中运行或通过正在使用的连接进行通信也是如此。中间人攻击的目标。
移动应用程序认证服务已作为 SAAS 解决方案存在，位于Approov https://www.approov.io/approov-in-detail.html（我在这里工作）为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务颁发的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求以及拒绝哪些请求是必要的。
结论
最后，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择用于保护 API 服务器的解决方案。
因此，使用 API 密钥可能听起来像是锁上家门并将钥匙留在垫子下，但不使用它们就像将车停在门关闭的情况下，但将钥匙放在点火开关中。
