B.S*_*uel 1 security api ios laravel passport.js
我必须开发移动应用程序的后端（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 的基本过程（只有我的应用程序会使用它）我应该实现哪些安全内容以及为我的应用程序创建帐户将如何工作。谢谢 ：）
不知道创建供私人使用的 api 的基本过程（只有我的应用程序会使用它）
在这里我要告诉你一个残酷的事实...
无论 API 是否没有公开可访问的文档，或者是否受到任何类型的秘密或身份验证机制的保护，一旦可以从互联网访问就不再是私有的。
因此，您可以使其难以查找和访问，但要真正将其锁定到您的移动应用程序，您将很难做到这一点。
WHO是移动应用程序的用户，您可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID 或 OAUTH2 流程。
现在您需要一种方法来识别什么在调用您的 API 服务器，而事情变得比大多数开发人员想象的更加棘手。向 API 服务器发出请求的是什么？它真的是您真正的移动应用程序还是机器人、自动化脚本或攻击者使用 Postman 等工具手动探测您的 API 服务器？
很好地确定开发人员倾向于诉诸什么API密钥，他们通常将其硬编码在移动应用程序的代码中，有些人会加倍努力，在移动应用程序的运行时计算它，从而成为动态秘密反对前一种方法，即嵌入代码中的静态秘密。
事实是，攻击者可以在他控制的设备上轻松对客户端中运行的任何内容进行逆向工程。他将使用Frida或xPosed等内省框架在运行时拦截移动应用程序的运行代码，或者使用MiTM Proxy等代理工具来监视移动应用程序和 API 服务器之间的通信。通常，他们对移动应用程序进行逆向工程的第一步是使用移动安全框架对移动应用程序的二进制文件进行逆向工程，以提取所有静态秘密并识别攻击向量。
移动安全框架是一种自动化、一体式移动应用程序 (Android/iOS/Windows) 笔测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。
将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。
Xpose 是一个模块框架，可以在不接触任何 APK 的情况下更改系统和应用程序的行为。这很好，因为这意味着模块可以适用于不同的版本，甚至无需任何更改的 ROM（只要原始代码没有更改太多）。它也很容易撤消。
为渗透测试人员和软件开发人员提供的交互式、支持 TLS 的拦截 HTTP 代理。
那么现在怎么办...我注定无法保护我的 API 服务器不被滥用吗？？？没有安静所以...希望仍然存在！
因此，任何在客户端运行并需要一些秘密才能访问 API 的内容都可能以不同的方式被滥用，您可以在有关移动 API 安全技术的本系列文章中了解更多信息。本文将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS Pinning 来保护 API 以及如何绕过它们。
但我担心对我的 api 的访问：我应该如何授予对我的 api 的访问权限？我听说过一些关于 Oauth 密钥和护照的事情。
对于我的应用程序，我想：
-用户可以创建一个帐户（我猜是使用 JWT） -用户可以在我的应用程序中导航并在创建帐户后开始使用它。
...以及我的应用程序的帐户创建将如何进行。
Laravel Passport 是一个 OAUTH2 服务器，因此是用于用户创建和识别的良好解决方案，从而解决谁在使用您的移动应用程序和 API 服务器的问题。
我应该实施哪些安全措施
要解决什么是访问您的移动应用程序的问题，您需要使用我上面提到的有关移动 API 安全技术的系列文章中提到的一个或所有解决方案，并接受它们只会使对您的 API 服务器的未经授权的访问变得更加困难绕过但并非不可能。
可以通过使用移动应用程序证明解决方案来采用更好的解决方案，该解决方案将使 API 服务器知道仅接收来自真实移动应用程序的请求。
使用移动应用程序证明解决方案使 API 服务器能够了解发送请求的内容，从而使其能够仅响应来自真正移动应用程序的请求。
移动应用程序证明服务的作用是在运行时保证您的移动应用程序未被篡改或未在获得 root 权限的设备中运行，方法是在后台运行 SDK，该 SDK 将与云中运行的服务通信以证明您的移动应用程序的安全性。运行的移动应用程序和设备的完整性。
成功证明移动应用程序完整性后，会发出一个短暂的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用程序认证失败，JWT 令牌将使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每次 API 调用时发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时才服务请求，并在验证失败时拒绝请求。
一旦移动应用程序不知道移动应用程序证明服务使用的秘密，就不可能在运行时对其进行逆向工程，即使应用程序被篡改、在 root 设备中运行或通过正在使用的连接进行通信也是如此。中间人攻击的目标。
移动应用程序认证服务已经作为 Approov（我在这里工作）的 SAAS 解决方案存在，它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务颁发的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求以及拒绝哪些请求是必要的。