我正在为我们的 Web 应用程序开发 HTTP API。最初，API 的主要使用者将是我们正在开发的 iPhone 应用程序，但我在设计它时考虑到了 future 的用途(例如其他平台的移动应用程序)。我正在尝试确定对用户进行身份验证的最佳方式，以便他们可以从 iPhone 访问他们的帐户。我有一个我认为效果很好的设计，但我不是安全专家，所以我认为最好在这里寻求反馈。
用户身份验证的设计有 3 个主要目标:
- 良好的用户体验:我们希望允许用户输入一次凭据，并无限期地保持登录状态，直到他们明确注销为止。据我所知，如果不是因为 iPhone 应用程序的体验非常糟糕(即它在 Safari 中启动登录表单，然后告诉用户在身份验证成功时返回到应用程序)，我会考虑 OAuth。 .
- 无需使用应用程序存储用户信用:我一直讨厌将用户密码以纯文本形式或对称加密方式存储在任何地方，因此我不希望应用程序必须存储密码才能将其传递给 API 以供将来的 API 请求使用。
- 安全性:我们绝对不需要银行应用程序的高度安全性，但我显然希望它是安全的。
总体而言，该 API 受 REST 启发(即将 URL 视为资源，并在语义上使用 HTTP 方法和状态代码)。对 API 的每个请求都必须包含两个自定义 HTTP header :一个 API key (对于每个客户端应用程序来说是唯一的)和一个唯一的设备 ID。 API 要求所有请求都使用 HTTPS 发出，以便 header 和正文被加密。
当前策略:
我的计划是在我的数据库中有一个api_sessions 表。它对 API key 和唯一设备 ID 具有唯一约束(以便设备只能通过给定应用程序登录到单个用户帐户)以及用户表的外键。
API 将有一个登录端点，它接收用户名/密码，如果它们与帐户匹配，则让用户登录，为给定的 API key 和设备 ID 创建 api_sessions 记录。 future 的 API 请求将使用 API key 和设备 ID 查找 api_session，如果找到记录，则将该请求视为在 api_session 记录引用的用户帐户下登录。
还有一个注销 API 端点，用于从 api_sessions 表中删除记录。
有人发现其中有任何明显的安全漏洞吗？
最佳答案
我同意 oAuth 的评论 - 你当然可以让 oAuth 在 iPhone 上很好地工作 - 用户体验完全取决于你。有一些机制(jQuery)可以从 oAuth 中提取 PIN 并使用它(无需用户在应用程序中重新输入 PIN)。这将用户体验降低到
1) 显示网页(嵌入式控件中) 2)用户输入用户名和密码并按下按钮 3) 自动解析oAuth响应页面。
这个 Twitter oAuth 实现就是这样做的 http://github.com/bengottlieb/Twitter-OAuth-iPhone使用预先存在的 oAuth 库。
但是，回到你原来的问题。看起来不错。您唯一没有提及的事项是，您需要在网络应用程序上提供一种机制，以允许用户注销/取消授权设备 session (以防他们丢失设备)。
关于iphone - 在 iPhone 应用程序中验证用户身份，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2841152/