我读过有关HTTP基本身份验证,HMAC,oAuth2的内容.
1)基本身份验证需要SSL,并且它要求您在每次api呼叫时发送用户名：密码.
>但这并不能阻止其他人使用其他应用程序的API,假设他们将登录凭据发布到端点？
2)我理解HMAC方法以及客户端和方法.服务器都知道Public&私钥.私钥与请求和其他数据一起被加密.公钥在标头中发送.当服务器收到请求时,它会检测标头中的公钥并将其与DB中的私钥相关联.然后重新计算哈希并检查它是否匹配.所以,我有以下问题：
>如果不通过网络发送私钥,新注册用户如何获得存储在IOS应用程序中的私钥？
>这是否更适合使用您的应用程序的应用程序？我通常在像Instagram& ;;这样的API仪表板中看到这一点. Facebook在哪里给你一个app密钥,对吧？
3)oAuth2 – 对我而言,这似乎更像是允许人们使用其他API登录我的应用程序.例如,允许用户使用FB登录我的应用程序并允许我的API使用Facebook数据？我此刻并不是真的需要这样做.
>我误解了这个吗？
听起来我需要通过向我的IOS APP授予一个私钥来将类似于HMAC方法的内容合并到我的IOS APP代码中.当从ios app中运行请求时,我传递带有私钥和其他数据的哈希,然后当在服务器上收到请求时,我通过重新计算哈希来检测请求是否来自应用程序内的用户.我不知道这是否安全&我会认为不是吗？
我缺少什么知识？我现在很困惑,写这个问题是一个很大的斗争.一旦事情变得更加清晰,我会立即修改它.
解决方法
你没错,这并不能阻止未经批准的客户.
2.
这实际上并不是一种防止未经批准的客户端的方法,它更多的是验证消息是否未通过网络进行篡改.
3.
您正确理解oAuth,它是关于验证客户端以特定方式使用API以及限制权限.
实际上不可能锁定您的API,因此只有特定的客户才能使用它,因为无法验证客户端到底是谁.此外,在客户端完成的任何形式的身份验证或验证最终都可以进行逆向工程,然后可以作为“已批准”的客户端发送到服务器.
这样的事情可以使用令牌完成.服务器向客户端发送令牌,客户端对令牌执行一些已知的操作,例如salting和hashing,使用已知的salt和hash操作,然后返回令牌以证明客户端是真实的.
问题是,如果有人对您的客户进行逆向工程,他们可以确定该操作是什么,然后创建自己的客户端,以相同的方式进行身份验证.任何形式的客户端身份验证都不是真正的安全性,也不可信任.
另一种方法是打破,如果有人可以MiTM您的请求.请求可以在到达服务器之前被捕获和修改,并且除了使用SSL之外,实际上没有任何方法可以防止这种情况发生,这可以通过SSLStrip之类的东西来解决.
任何阻止未经批准的客户的尝试基本上都是security through obscurity,因为没有一种可证明安全的方法来做你所要求的.
保护API的最佳方法不是限制哪些客户端可以访问它,而是通过使其安全.最佳实践包括强制SSL,仅发送一次密码,然后使用令牌进行身份验证等.