我使用自定义基本身份验证在我的 RESTFUL WCF服务中设置安全性（因此取消激活iis基本身份验证，完全不使用Windows帐户登录;我的服务由iis托管）使用以下内容链接。
我了解消费者必须实现客户端以在请求标头中传递凭据。
它是基于64位的编码，我们可以看到在调试时传递给firebug网络选项卡的凭据（它始终是相同的字符串编码＆lt; =＆gt;相同的凭证.......）
因此，为了实施安全性，我将添加SSL来加密网址：
https://myrestfulserviceurl.com/Method
现在消费者问我为什么不在网址请求中输入登录名和密码，即
https：// myrestfulserviceurl.com/Method?login=XXX&password=YYY （也结合SSL）
因此，更改需要在我的操作合同中添加登录名和密码作为参数，并在我的方法“方法”中调用一个验证方法..等等
我的问题是：
自定义基本身份验证（请求标头中的凭据）＆amp;之间的差异（两者都是使用ssl）只需在param的URL中传递凭据？
我的意思是：我只是问自己为什么要费心去实施Basic Authentification。在URL或标题中传递凭证看起来类似：它在请求中传递内容。但就安全性而言，它看起来是一样的吗？
除了基于64位的编码外，基本身份验证看起来并不安全。
如果我错了，请纠正我。
我正在寻找实施Custom Basic Authentification的原因。
任何想法/建议？ 感谢
答案 0 :(得分：0)
想到的主要区别在于数据的可见程度以及可能保留的时间。
例如，假设SSL在您的应用程序服务器上终止，则get参数中的值可能会自动记录到您的文件系统中（例如，在请求日志中）。在那里有用户名和密码是不理想的，因为它使它们更容易被泄露。
如果SSL在负载均衡器或某个类似的代理上终止，那么用户名和密码可以保存在您可能没有考虑的服务器上的请求日志中，并且可能对其控制较少。
相比之下，身份验证标头更不可能记录到您不期望的地方。
答案 1 :(得分：0)
我自己想过这个并决定反对它，因为我希望Restful URL只关注操作并保持安全性，例如我可能想在不同的应用程序上重复使用相同的代码。
此外我不确定，但我认为可能存在关于重放攻击的安全隐含，如果有人获得了链接，那么他们可以在任何http客户端执行它。如果您在http标头中使用了authroisation属性，则可以通过对其进行过期来避免这种情况。另外我认为最好从html页面体中隐藏这些信息。
写这篇http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/的老兄，摘自他的“Pro ASP.NET web Security”一书。提供了一个相当不错的创建令牌的示例，然后您可以在http标头“授权”中使用它，例如：授权：基本d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk