使用 cookie/会话进行移动应用程序身份验证？
我是否有任何理由不应该对本机移动应用程序（通常由浏览器使用）使用 cookie/会话来对我的服务器进行身份验证并进行后续 API 调用？
说明：移动客户端上事实上的身份验证方法似乎是基于令牌的系统，例如 OAuth/XAuth。为什么传统的浏览器方法不够用？
Is there any reason why I shouldn't use cookies/sessions for native mobile applications, usually used by browsers, to authenticate with my server and for subsequent API calls?
Clarification: It seems the de-facto method of authentication on mobile clients is token based systems like OAuth/XAuth. Why don't traditional browser methods suffice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于您的应用程序（更准确地说是您的威胁场景）。
一些最常见的威胁是
- 窃听（-> 应该加密）
- 中间人（-> 必须验证另一方）
- ...你的是什么？ （您的 cookie 存储有多安全……）
cookie 最初仅保存一个令牌，作为您有时已成功进行身份验证的证据。如果 cookie 的有效期足够长或传输未加密，那么很有可能有一天有人会发现...
此外，您必须考虑采取哪些额外的安全措施，首先是最重要的 SSL。
您的身份验证方法是什么（客户端需要什么凭据才能登录）？您是否可以使用基于 PPK 基础设施的身份验证，或者通信是“临时”的吗？
编辑
Wrt。 OpenAuth：据我了解该协议，其主要关注的是身份验证委托。您授权代理代表另一个身份执行某些非常具体的任务的场景。这样您就不会将您的凭据分散在整个网络上。如果您有 OpenAuth，客户端也可以直接使用该协议。那么为什么还要添加另一个呢？但 OpenAuth 明确指出，在直接客户端场景中，您会再次遇到安全问题，因为现在令牌在设备上可用，并且必须进行相应的保护（就像您必须对 cookie 所做的那样）。
This depends on your application (your threat scenario to be more exact).
Some of the most common threats are
- eavesdropping (-> should encrypt)
- man in the middle (-> must authenticate other party)
- ...what are yours? (how secure is your cookie store,....)
A cookie at first only holds a token as proof that sometime you have successfully made an authentication. If the cookie is valid long enough or transport not encrypted, there is a good chance that someone someday will find out...
In addition you must take into account what additional security measures are in place, at first and most important SSL.
What is your authentication method (what credential does a client need to logon)? Do you have the possibility to work with authentication based on PPK infrastructure or is the communication "ad-hoc"?
EDIT
Wrt. to OpenAuth: as far as i understood the protocol its main concern is authentication delegation. A scenario where you authorize an agent to do some very specific task on behalf of another identity. This way you dont scatter your credentials all over the web. If you have OpenAuth in place, a client can use the protocol directly, too. So why bother adding another. But OpenAuth explicitly states that with a direct client scenario you again run into security issues as now the token is available on the device and must be protected accordingly (as you must do with your cookie).