android开发之常用OAuth登录与分享详解

一、Android常用OAuth登录与分享详解

• OAuth2.0概述：
  OAuth2.0是一个关于授权(authorization)的开发网络标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如图片、视频、联系人列表)，而无需将用户名和密码提供给第三方应用。
  其中，能拿到Access Token是最最重要的，它是用户身份验证和授权的凭证。
• OAuth运行流程：
  
  Authorization Request:客户端(第三方应用)发起一次认证请求到资源拥有者(用户)
  Authorization Grant:对其请求进行授权
  Access Token:获取从授权服务器给的令牌
  Protected Resource:获取用户所保护的资源文件

• OAuth四种授权模式之授权码模式(authorization code)，功能最完整，流程最为严密的一种授权模式；特点就是：通过客户端的后台服务器与资源提供上的认证服务器进行的一个互动。
  授权码模式请求资源流程图:
  
  据图,我们可以看出:多了一种用户代理(理解为浏览器),那么接下来我们分析分析,授权码模式流程图:
  首先第三方应用发起认证请求,通过我们的用户代理转向授权服务器,它在请求的时候会携带认证信息(客户端的身份识别)和重定向URI,当然还会有一些其他的参数,这样一来授权服务器接收到认证请求之后,会去和资源拥有者进行互动(告诉资源拥有者是哪个第三方应用在认证请求资源,是否对此进行授权),如果用户选择了授权那么,收取服务器会返回一个临时授权码给用户代理,接着用户代理再把临时授权码给第三方应用,从而完成第三方应用的第一次请求认证授权,那么,接下来,第三方应用会发起第二次认证请求(会携带临时授权和重定向URI,这个uri要和第一次请求认证时的uri一致,不然就会请求认证失败),如果成功,那么授权服务器就会返回一个令牌给第三方应用,这样就完成了整个授权码模式的流程.
  *客户端发起的第一次请求：
  
  
  - 构建第一次请求：
  
  

  *客户端发起的第二次请求：(通过临时授权码去换取令牌的过程)

  
  - 构建第二次请求：本次请求将更加严格(Post+加密)
  

  *HTTP Basic Authentication -- 一种认证方式:

  
  那么,有没有办法在第一次请求认证的时候就携带这些数据呢,这样不就可以避免对话框的弹出呢?
  
  但这样的话,用户名和密码其实是挺容易泄露的!!
  接下来,如何通过代码来设置Authorization到请求头信息中去.
  
  接下来,我们一起看看,我们客户端第二次请求时返回的结果这里:
  

• OAuth四种授权模式之简化模式(implicit grant)
  
  简化模式，主要是用于手机、桌面客户端程序、浏览器插件。
  *客户端发起的请求所需的请求参数：
  
  - 构建请求：
  
  - 授权服务器返回的类型：
  

• OAuth四种授权模式之密码模式(resource owner password credentials)
  
  *客户端发起的请求所需的请求参数：
  
  - 请求详细信息：
  

• OAuth四种授权模式之客户端模式(client credentials)
  
  *客户端发起的请求所需的请求参数：
  
  - 请求详细信息：
  

到目前，为止四种模式基本概述完了，那么接下来总结一下：
1. 授权码模式：这是一种功能最完整，流程最严密的授权模式，第三方应用一共会发起两次认证请求；第一次是让用户选择是否对我们的客户端进行授权，从而拿到一个临时授权码，第二次请求是通过临时授权码来换取正式的令牌信息。
2. 简化模式：主要针对没有Server端的第三方应用，在这种模式中，客户端只需要发起一次请求就可以拿到令牌信息，但是这种模式获取令牌的方式和其他三种认证模式不一样，它的令牌信息是授权服务器通过请求第三方应用所传的重定向URI来传递的，放在了URI的哈希值部分并且需要客户端自己解析出令牌信息，并且在这种模式中是没有refereshtoken返回来的。
3. 密码模式：在这种模式下，用户会将自己在资源服务器上面的用户名和密码直接传递给第三方应用，从而第三方应用直接去我们的授权服务器获取令牌信息，这种模式最要是用于一些高信任度的第三方应用中。
4. 客户端模式：是最简单、直接、粗暴的获取令牌方式，它是第三方应用以自己的名义向我们的服务提供三级认证。

二、更新令牌

之间，我们讲授权模式时有提过令牌是有一个有效期限的，因此一旦有效期一过，我们的令牌就失效了，就需要我们重新获取令牌；重新获取令牌的时候会有两种方法：一种是重新再走一次以前的整个认证流程，但这个过程又得让用户再次手动授权；第二种是通过上一次授权的refereshtoken来刷新出一个新的令牌，因此叫做“更新令牌操作”，这种方式只需要重新发起一个请求即可。

• 更新令牌的请求参数：
  

三、问题集锦

在上面所讲当中，我们有两个遗留问题：
1. State的作用？

从上面的流程，我们可以看出，从授权服务器返回给第三方应用的url地址中单单仅携带着code(临时授权码)，是没有任何关于第三方应用想要的用户信息的，那么问题来了：如果这样时候我们有两个用户(UserA和UserB)请求过来，并同时通过了授权服务器授权，那么，第三方应用就同时拿到了两个包含临时授权码的URL，分别是授权码C与授权码D，它们的关系应该如图所示：

授权码C是属于UserA的，授权码D是属于UserB的；但由于第三方应用的Server端服务区分User和临时授权码之间的关系，那么，就会有可能出现这样的如图所示的情况：

授权码C给了UserB，授权码D给了UserA，这样的就会出现混乱，同时还会造成获取令牌时的错误，所以避免这种错误和不必要的混乱，我们的State就上场了。
2. 为什么需要临时授权这一过程？
a) 保证了redirect_url的安全性。
b) 如果不加临时授权码这一步，会加大我们认证的门槛。

四、申请百度开发者账号

1、登录百度开发者平台：developer.baidu.com，并注册登录。

2、创建百度工程：

1. 进入开发者服务管理：
   
2. 点击创建工程：
   
3. 会生成客户端的识别码和秘钥：
   

3、百度OAuth授权文档介绍
（http://developer.baidu.com/wiki/index.php?title=docs/oauth）

1. 点击其他API –> 用户基础信息API(查看API服务列表)
   
2. 百度支持的OAuth授权
   
   

3、具体讲解Authorization Code授权
（http://developer.baidu.com/wiki/index.php?title=docs/oauth/authorization）

快速回忆：Authorization Code授权流程

首先通过第三方应用客户端发起一个请求到授权服务器，而我们的授权服务器会对第三方客户端发起的请求进行简单认证之后，就会去询问我们的用户是否接受第三方应用的请求授权，如果用户同意了授权，那么授权服务器就会通过回调uri返回给我们的第三方应用客户端一个临时的授权码，通过临时的授权码去授权服务器换取正式的令牌（Access Token），这样的话就完成了整个认证的请求。当然，其中都会有用户代理作为中间件。

1. 获取Authorization Code
   
   
2. 通过Authorization Code获取Access Token
   
   

五、获取百度用户信息

（http://developer.baidu.com/wiki/index.php?title=docs/oauth/rest/file_data_apis_list）

那么，到目前为止，OAuth登录与分享就分析到了这里！！
如果大家觉得可以请给个好评，谢谢了！！