我必须开发移动应用程序的后端（IOS迅速）。我开始使用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（仅我的应用程序会使用它）的基本过程，我应该实现哪些安全措施以及如何为我的应用程序创建帐户。谢谢：）
答案 0 :(得分：0)
不知道有关创建供私人使用的api的基本过程（只有我的应用会使用它）
让我在这里告诉你一个残酷的事实...
无论API是否没有公共可访问的文档，或者是否受到任何类型的秘密或身份验证机制的保护，从Internet访问一次都不再是私有的。
因此，您可能很难找到和访问它，但要将其真正锁定到您的移动应用程序中将很难。
WHO 是移动应用程序的用户，您可以通过多种方式（例如使用OpenID或OAUTH2流）来进行身份验证，授权和标识。
现在，您需要一种方法来识别正在调用API服务器的什么，这比大多数开发人员想象的要棘手得多。 什么是向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密钥，用户访问令牌，HMAC和TLS固定来保护API以及如何绕过它们。
但是我担心我的api的访问权限：我应该如何授予对我的api的访问权限？我听说过一些有关Oauth密钥和护照的事情。
对于我的应用程序，我想：
-用户可以创建一个帐户（我想是JWT的） -用户可以在创建我的帐户后浏览我的应用并开始使用它。
...以及如何为我的应用程序创建帐户。
Laravel Passport是一台OAUTH2服务器，因此是用于用户创建和标识的一个很好的解决方案，从而解决了 WHO 正在使用您的移动应用程序和API服务器的问题。
我应该实现哪些安全性
要解决什么正在访问您的移动应用程序的问题，您需要使用我上面提到的有关移动API安全技术的系列文章中提到的一个或所有解决方案，并接受它们可以只会使未经授权访问您的API服务器更加困难，但这并非不可能。
通过使用移动应用程序证明解决方案，可以采用更好的解决方案，该解决方案将使API服务器能够知道仅接收到来自真正移动应用程序的请求。
使用移动应用证明解决方案，使API服务器能够知道发送的请求，从而使其仅响应来自真实移动应用的请求。
移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或未在有根设备中运行证明移动应用程序和设备正在运行的完整性。
在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败，则会使用API服务器不知道的秘密对JWT令牌进行签名。
现在，应用程序必须随每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的机密，即使在应用程序被篡改，在有根设备上运行或通过连接进行通信时，也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。
移动应用证明服务已经作为Approov的SAAS解决方案存在（我在这里工作），该服务为多个平台（包括iOS，Android，React Native等）提供SDK。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。