我必须开发移动应用程序的后端（IOS swift）。我开始用 laravel 创建 api。 但我担心对我的 api 的访问：我应该如何访问我的 api ？我听说过一些关于 Oauth 密钥和护照的东西。
对于我的应用，我想：
-user can create an account (i guess it's with JWT)
-user can navigate in my app and start to use it after they create their account.
我不知道创建私有 API 的基本流程（只有我的应用程序会使用它）我应该实施哪些安全措施以及如何为我的应用程序创建帐户。谢谢 :)
【问题讨论】：
标签： ios laravel api security passport.js
想知道创建一个私人使用的 api 的基本过程（只有我的应用程序会使用它）
让我在这里告诉你一个残酷的事实......
无论 API 是否没有可公开访问的文档，或者是否受到任何类型的机密或身份验证机制的保护，一旦可从 Internet 访问就不再是私有的了。
因此，您可以使其难以查找和访问，但要将其真正锁定到您的移动应用程序中，您将很难做到。
WHO 是移动应用程序的用户，您可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID 或 OAUTH2 流。
现在您需要一种方法来识别 什么 正在调用您的 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的东西，它真的是您真正的移动应用程序，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
为了识别什么，开发人员倾向于求助于 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 的东西都可能以不同的方式被滥用，您可以在 this series 了解更多关于移动 API 安全技术的文章。本文将教您如何使用 API Keys、用户访问令牌、HMAC 和 TLS Pinning 来保护 API 以及如何绕过它们。
但我担心对我的 api 的访问：我应该如何授予对我的 api 的访问权限？我听说过一些关于 Oauth 密钥和护照的东西。
对于我的应用，我想：
-user 可以创建一个帐户（我猜是 JWT 的） - 用户可以在我的应用中导航并在创建帐户后开始使用它。
...以及如何为我的应用创建帐户。
Laravel Passport 是一个 OAUTH2 服务器，因此是用于创建和识别用户的良好解决方案，从而解决 谁 正在使用您的移动应用程序和 API 服务器的问题。
我应该实施哪些安全措施
要解决 什么 访问您的移动应用程序的问题，您需要使用我上面提到的关于移动 API 安全技术的系列文章中提到的一个或所有解决方案，并接受它们可以只会使对您的 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 服务器能够决定服务哪些请求和拒绝哪些请求是必要的。
【讨论】：