【发布时间】:2023-03-11 21:30:01
【问题描述】:
我正在为我们的 Web 应用程序开发一个 HTTP api。最初,API 的主要使用者将是我们正在开发的 iPhone 应用程序,但我在设计它时考虑到了未来的用途(例如用于其他平台的移动应用程序)。我正在尝试确定对用户进行身份验证的最佳方式,以便他们可以从 iPhone 访问他们的帐户。我有一个我认为效果很好的设计,但我不是安全专家,所以我认为在这里寻求反馈会很好。
用户身份验证的设计有 3 个主要目标:
- 良好的用户体验:我们希望允许用户输入他们的凭据一次,并无限期地保持登录状态,直到他们明确退出。如果不是因为 iPhone 应用程序的体验非常糟糕,我会考虑 OAuth,据我所知(即它在 Safari 中启动登录表单,然后告诉用户在身份验证成功时返回应用程序) .
- 无需在应用中存储用户凭据:我一直讨厌将用户密码以纯文本或对称加密的形式存储在任何地方的想法,因此我不希望应用必须存储将其传递给 API 以供未来 API 请求使用的密码。
- 安全性:我们绝对不需要银行应用程序的高度安全性,但我显然希望它是安全的。
总体而言,API 受 REST 启发(即将 URL 视为资源,并在语义上使用 HTTP 方法和状态码)。对 API 的每个请求都必须包含两个自定义 HTTP 标头:一个 API 密钥(每个客户端应用程序唯一)和一个唯一设备 ID。 API 要求使用 HTTPS 发出所有请求,以便对标头和正文进行加密。
当前策略:
我的计划是在我的数据库中有一个 api_sessions 表。它对 API 密钥和唯一设备 ID 具有唯一约束(以便设备只能通过给定应用程序登录到单个用户帐户)以及 users 表的外键。
API 将有一个 login 端点,该端点接收用户名/密码,如果它们与帐户匹配,则将用户登录,为给定的 API 密钥和设备 ID 创建一个 api_sessions 记录。未来的 API 请求将使用 API 密钥和设备 ID 查找 api_session,如果找到记录,则将请求视为在 api_session 记录引用的用户帐户下登录。
还有一个 logout API 端点,它会从 api_sessions 表中删除记录。
有没有人看到任何明显的安全漏洞?
【问题讨论】:
-
听起来你在重新发明 Oauth...
-
好吧,如果不是因为它在 iPhone 上的用户体验很糟糕,我会考虑使用 Oauth。
标签: iphone api authentication