现在微博网站很火，新浪微博、搜狐微博、腾讯微博、网易微博……无论是在电视上、还是公交车上、地铁上，真的是铺天盖地了，也因此这些公司的市值不断提升。为了吸引更多的应用，这些网站也纷纷开放API，以开放平台的方式供第三方应用开发或进驻微博广场。今天我们就来说一下这些开放API的授权问题。

作为开发人员，我们都知道开放API必然会有鉴权部分，要充分考虑到用户数据的安全性，因此，这些网站都有授权机制，常用的有如下两种。

一种是Basic Authentication，也称为普通鉴权或基本鉴权，是一种通过在HTTP头信息中加入用户名密码进行传输以确认用户身份的协议。当我们在开发应用时，会有一个界面用来要求用户输入用户名和密码，然后按RFC2617标准将用户名和密码用冒号连接起来并做Base64编码，每次进行HTTP请求时在header数据中加入：

Authorization: Basic 编码后的用户信息

即可。

这种方式简单易行，开发方便，但不足之处是安全性差。一是开发人员可以轻而易举的记录用户的用户名和密码信息，二是通过HTTP包可以很容易的进行Base64解码并形成用户信息的明文，因此，目前很多网站都不再提供对此种授权方式的支持。

另一种是OAuth，这是目前应用最多的一种鉴权方式，其目的就是针对普通鉴权的安全性提出的，一是不想在我们开发的应用程序中提供用户输入用户名密码的界面，从而防止开发人员对用户登录信息的记录，二是在通过授权后的HTTP通信中不再传输用户信息而是以数字签名和AccessToken取代，即使截到HTTP包，也无法还原出用户的登录信息。

只不过鱼与熊掌不可兼得，这种方式的初次用户授权过程很漫长，要想获取到AccessToken，需要经过好几个步骤，可以参考新浪给出的这张图。

或者参考OAuth协议简介的博文。

OAuth是目前用得最多的协议，但某些使用该协议的网站却没有重视该协议在实现中的细节，实现得不是很理想，导致安全信息的泄露。拿新浪微博的开放平台为例，假设我们已经在新浪微博开放平台上创建了应用，得到了新浪分配的AppKey和AppSecret，然后在Android手机上开发客户端程序，按照上述流程开发OAuth鉴权部分。

首先访问request_token获取RequestKey和RequestSecret，这步没有问题。

接下来，访问authorize获取用户授权确认，注意，这里显示出来的供用户确认的网页本意是不想在我们的应用程序中出现，直接利用外部浏览器进行，这样在整个用户输入登录信息的过程中对开发人员是不可见的。问题就出在这里。如果在我们自己的Android应用程序中内嵌浏览器WebView的话，尽管用户在授权页面上输入的用户名和密码不好获取，但是当用户点击授权按钮后的HTTP请求还是会传入到WebView对象的onPageStarted()中，受我们的应用程序控制。也就是说，用户填好登录信息并提交时，我们可以在onPageStarted()中得到如下的URL：

http://api.t.sina.com.cn/oauth/authorize?action=submit&oauth_token=xxx &display=null&oauth_callback=http%3A%2F%2Fxxx&from=&userId=xxx%40sina.com&passwd=123456

从这里我们看到了什么？没错，看到了用户登录的ID和密码，而且是明文的。

写到这里，我想可以结束本文了，总体上来说，对比这两种授权方式，显然还是OAuth更安全，但是希望网站方在提供用户授权的页面时，还是要仔细处理这些问题。要知道现在客户端开发是可以很容易的在自己的界面中内嵌浏览器并可以监控到用户在浏览器中的操作的。如果这样的程序分发出去，真的想获取用户的登录名和密码的话，对用户的信息安全还是很危险的。

用一句经典的话结尾吧：安全永远是相对的。

——欢迎转载，请注明出处 http://blog.csdn.net/caowenbin——