Background:
这实际上是一个一般的最佳实践问题,但有关具体情况的一些背景可能会有所帮助:
我们正在为iPhone开发一个“连接”应用程序 . 它将通过REST服务与后端应用程序通信 . 为了在每次启动应用程序时不必提示用户输入用户名和密码,我们将公开一个“登录”服务,该服务在初始启动时验证其用户名和密码,并返回可用于将来Web的身份验证令牌服务请求真实数据 . 令牌可能有一个到期时间,之后我们会要求他们使用他们的用户名/密码重新进行身份验证 .
The Question:
生成此类令牌以用于身份验证的最佳做法是什么?
例如,我们可以......
-
哈希(SHA-256等)随机字符串并将其存储在给定用户的数据库中以及到期日期 . 在后续请求中对令牌进行简单查找以确保其匹配 .
-
使用密钥加密用户ID和一些其他信息(时间戳等) . 在后续请求中解密令牌以确保它是由我们发布的 .
这感觉它必须是一个解决的问题 .
7 回答
基于这个问题的其他答案的反馈,额外的研究和离线讨论,这是我们最终做的...
很快就指出,当选中“记住我”复选框时,此处的交互模型与ASP.NET中的表单身份验证使用的模型基本完全相同 . 它不是发出HTTP请求的Web浏览器 . 我们的“票证”与表单身份验证设置的cookie等效 . 表单身份验证默认情况下使用“使用密钥加密某些数据”方法 .
在我们的登录Web服务中,我们使用此代码创建票证:
然后,我们为WCF服务提供了一个操作行为属性,该属性添加了一个IParameterInspector,用于检查请求的HTTP头中的有效票证 . 开发人员将此操作行为属性放在需要身份验证的操作上 . 以下是该代码解析故障单的方式:
构建自己的身份验证系统始终是“最糟糕的做法” . 这是专门从事认证系统的专业人士最好的事情 .
如果您倾向于构建自己的“登录服务即将到期的票证”架构而不是重新使用现有架构,那么至少要熟悉驱动类似系统设计的问题(如Kerberos)可能是个好主意 . . 这里有一个温和的介绍:
http://web.mit.edu/kerberos/dialogue.html
考虑过去20年在Kerberos(和类似系统)中发现的安全漏洞并确保不复制它们也是一个好主意 . Kerberos由安全专家构建并经过数十年的仔细审查,并且仍然存在严重的算法缺陷,如下所示:
http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt
从他们的错误中学习比你自己的错误要好得多 .
Amazon.com使用HMAC SHA-1 message token来验证和授权请求 . 他们将此用于相当大的商业服务,因此我可能会相信他们的工程决策 . 谷歌发布的OpenSocial API有点类似 . 基于Google和Amazon.com使用类似且公开发布的方法来保护Web请求,我怀疑这些可能是很好的方法 .
您提供的两个答案中的任何一个都足够了 . 你可能会找到那些为你做这个的框架,但事实是它并不难 Build . (我所工作过的每一家公司都已经推出了自己的公司 . )数据库存储令牌与加密数据“cookies”的选择是一个架构决策 - 你想在每个页面视图上进行数据库查找,还是你愿意?用cookie解密来咀嚼CPU?在大多数应用程序中,使用加密的cookie可以大规模地提升性能(如果这是一个问题) . 否则,这只是一个品味问题 .
由于您使用的是WCF,因此如果使用CFNetwork,您可以使用多种选项 - 例如NTLM或摘要式身份验证:
http://developer.apple.com/documentation/Networking/Conceptual/CFNetwork/Concepts/Concepts.html#//apple_ref/doc/uid/TP30001132-CH4-SW7
我知道这不能解答您的具体问题,但我也遇到过这个问题(iPhone - Tomcat),并决定尽可能在Web服务器上使用身份验证服务 . 没有重大的惩罚在大多数情况下,包括每个请求的认证信息 . 一个快速的谷歌出现了很多关于WCF和RESTful服务的博客文章(以及关于StackOverflow的一些相关问题) .
希望这可以帮助!
你应该实现:
OAuth2隐式授权 - 适用于第三方应用http://tools.ietf.org/html/rfc6749#section-1.3.2
OAuth2资源所有者密码凭据 - 适用于您自己的移动应用http://tools.ietf.org/html/rfc6749#section-1.3.3
这正是您正在寻找的来自OAuth2的工作流程 . 不要重新发明轮子 .
这听起来像是具有较长过期时间的会话标识符 . Web应用程序中使用的相同原则可适用于此处 .
不是编码信息,而是从非常大的空间(128位)中随机选择会话标识符 . 服务器保存将会话标识符与用户相关联的记录以及诸如到期时间之类的其他所需信息 . 客户端通过每个请求在安全通道上呈现会话标识符 .
安全性依赖于会话标识符的不可预测性 . 使用加密RNG从非常大的空间生成它们 .