HTTP认证与饼干

看来，基于Cookie的身份验证是明确的选择今天需要登录凭据的Web服务。HTTP认证与饼干

可是你知道，如果你正在开发一个Web服务，其中客户端是不是浏览器，而是通过HTTP你可以使用HTTP认证或cookie认证访问资源，客户端软件（如移动应用）？

HTTP验证：

Web服务器处理身份验证，因此，如果需要
自动应用到非代码资源（例如JPG，XML等）（端Q容易更改的Web应用程序平台：是有没有办法与基于cookie的身份验证来做到这一点）
更难整合与服务器授权（的.htaccess/.htpasswd则）

cookie认证数据库存储的凭据：？

（代码资源可以有不同的反应基于证书）

控制会话过期（通过cookie的到期日）

细粒度访问控制
在用户登录体验完全控制

其他什么我要离开的考虑？任何其他优点/缺点？

Some helpful discussion is here

来源

2011-02-09 jpeskin

如果有兴趣在这两种类型的身份验证之间进行安全性阅读此：http://stackoverflow.com/questions/5052607/cookies-vs-basic-auth/5052622#5052622 – 2011-04-29 15:47:53

随着HTTP认证，代码资源可以有不同的反应基于谁提出请求的用户。用户的名字通常通过HTTP头传递给代码。

随着HTTP认证，您仍然可以使用会话和有他们带来同样的好处。事实上，会话窃取是不是太大的问题了，因为你可以测试存储在会话的用户是否是通过HTTP认证进行了认证一样。出于同样的原因，会话标识符不必是无法猜测的，因为它们需要使用基于Cookie的身份验证。

来源

2011-02-09 18:25:37 Oswald

好点。但是，你说“会话窃取”不是问题。你是指嗅探HTTP数据包并复制会话cookie？看起来，HTTP身份验证同样容易受到攻击，因为用户：pass在[容易解码的Base64]（http://en.wikipedia.org/wiki/Basic_access_authentication）中传输。如果通过HTTP传输，窃取HTTP身份验证凭证只会稍微困难一点。或者我不理解你的观点？ – jpeskin 2011-02-09 18:46:17

那么，当客户端是移动应用或东西是不是一个普通的浏览器，服务器应用程序仍然需要某种形式的会话跟踪的。执行会话跟踪的最简单方法是使用某种“cookie”，标准HTTP cookie或自定义会话ID。所以，即使没有使用标准的cookie机制，会话标识符实际上也是一个“cookie”。我总是将会话标识符分配给客户端会话，所以我倾向于选择Cookie身份验证。

来源

2011-02-09 18:19:35 Alex

HTTP基本身份验证是一场噩梦当密码被泄露，因为没有办法去改变它，而不首先改变所有legitmate客户。您也无法强制单个用户被取消身份验证，并且传输身份验证凭据的机制不安全（除非您将其封装在https中）

真的，您最好的选择是使用基于cookie的系统，控制个人认证会话

来源

2013-03-16 02:10:59 smeenz

HTTP认证与饼干

回答

相关问题