转：Basic and Digest Access Authentication (rfc2617) 及HttpClient实现

转：http://www.cnblogs.com/jcli/archive/2012/12/11/2812459.html

 

介绍Basic和Digest

http协议并没有定义相关的安全认证方面的标准，所以就有了Basic and Digest Access Authentication的定义来补充，它的目的就是补充一套基于http服务端的认证机制，保护相关的资源避免被非法用户访问,如果你要访问被保护的资源，则必需要提供合法的用户名和密码。

和https有什么关联？

basic & digest auth 和 https 没有任何关系。前者是为用户认证机制，后者是信息通道加密措施。

basic 和 digest有什么区别？

digest是basic的升级版，更加安全。因为basic是明文传输密码信息，而digest是加密后传输。

digest就是绝对安全的吗？

首先，这个世界上没有绝对的东西。digest默认用MD5（其它算法也可以）对密码进行加密，虽然相比basic认证的明文传输更安全，但是加密算法本身的安全性也值得怀疑(md5是可以反推出原文的)。再者，digest只是对认证信息的加密，后续的内容传输安全性得不到保障。所以https机制的作用就显现出来。

通过上面的相关信息，我们可以得到一个清晰的结论：如果你想加强自己的认证信息的保护，有两种选择，一是基于digest认证；别一种是在https通道上进行basic认证。

basic和digest认证流程

 

 

1，客户端请求受保护的资源
2，服务器检测到没有授权，则生成一个challenge返回给客户端
3，客户端根据challenge和相关信息计算出digest
4，附带3计算出的信息再次请求1中的资源
5，服务端根据已知的用户密码信息计算出digest并与4中请求的digest比较验证
6，服务端验证通过后返回资源给合法用户

Basic和Digest的认证都是按照上面的流程来，唯一不同的是3和5中计算digest的算法不同：Basic是将密码直接base64编码(明文),而Digest是用MD5进行加密后传输。

下面假设我们现在要请求：http://localhost:8080/index.html 这个路径，而它需要认证后才能访问。

Basic的流程如下：

1. 在浏览器请求：http://localhost:8080/index.html
2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头，格式如下：WWW-Authenticate    Basic realm="Admin All"
3. 浏览器用：base64(username:password) 编码后的信息添加到请求头中再次请求1中的资源，如果用户名是tomcat,密码是tomcat,则base64(tomcat:tomcat)为（dG9tY2F0OnRvbWNhdA==）。所以头信息为：Authorization    Basic dG9tY2F0OnRvbWNhdA==
4. 用3中计算的请求头信息再次请求1中的资源
5. 服务器用3中相同的算法(base64)验证用户密码合法性
6. 返回index.html的资源

Digest的流程和上面一样，只是challenge和digest的生成算法不同

1. 在浏览器请求：http://localhost:8080/index.html
2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头，格式如下：WWW-Authenticate    Digest realm="Admin All", qop="auth", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", opaque="EE9C283E89AFB63E7FF6E2C04C524807"
3. 浏 览器用MD5编码后的信息添加到请求头中再次请求1中的资源，如果用户名是tomcat,密码是tomcat,则生成的头信息:Authorization    Digest username="tomcat", realm="Admin All", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", uri="/web/index.html", response="8d30e6438636fe21c6045246dd034372", opaque="EE9C283E89AFB63E7FF6E2C04C524807", qop=auth, nc=00000001, cnonce="9201a828891792b9"
4. 用3中计算的请求头信息再次请求1中的资源
5. 服务器用3中相同的算法(base64)验证用户密码合法性
6. 返回index.html的资源

这里我们只是讨论流程，具体的challenge和digest的生成算法请参考：RFC2617

HttpClient的实现

示例代码:

HttpHost targetHost = new HttpHost("localhost", 8080);

		DefaultHttpClient client = new DefaultHttpClient();

		HttpContext context = new BasicHttpContext();
		context.setAttribute(ClientContext.CREDS_PROVIDER,
				new BasicCredentialsProvider());
		CredentialsProvider provider = (CredentialsProvider) context
				.getAttribute(ClientContext.CREDS_PROVIDER);
		provider.setCredentials(new AuthScope(targetHost.getHostName(),
				targetHost.getPort()), new UsernamePasswordCredentials("tomcat", "admin"));

		HttpGet get = new HttpGet("http://localhost:8080/web/Hello");
		HttpResponse response = client.execute(get, context);
		System.out.println(response.getStatusLine());
		HttpEntity entity = response.getEntity();
		String s = EntityUtils.toString(entity);
		System.out.println(s);

 

主要类结构图：

 

 

Auth流程图：