Google Open API授权认证体系
Google Open API授权认证体系
终端用户在使用第三方软件访问用户受保护的资源时，都需要终端用户授权给第三方软件。如用户在使用第三方软件需要访问或者操作用户在Google上注册的服务（Gmail服务，Calendar服务等）时，就需要用户将相关资源的权限授权给该软件。Google除了提供了很多个性化的服务外，同时提供了一套完整的服务授权体系。Google的服务认证体系包含了多种认证授权的方式，如AuthSub授权认证服务、OAUTH授权认证服务与ClientLogin授权认证服务等。软件开发商可以根据自己软件的特点来选择合适的认证方式。本文将简要的介绍这三种认证服务。
一、Google授权认证体系
Google的服务认证体系包含了多种认证授权的方式，到目前为止，Google提供了以下四种授权认证方式：AuthSub授权认证服务、OAUTH授权认证服务、ClientLogin授权认证服务与Gadgets授权认证服务等。如下图所示：
软件开发商可以根据自己软件的类型来选择合适的认证方式。如果你的软件是单机版的应用（如单机版的桌面应用）时，你应该选择ClientLogin授权认证服务；如果你的软件是基于BS多用户使用的WEB应用时，你可以考虑选择AuthSub授权认证服务或者OAUTH授权认证服务；如果你的应用是小工具（小工具是简单的HTML和JavaScript应用程序，可以嵌入到网页中或其他应用程序中，比如为iGoogle或者Open Social容器开发的小工具）类型的软件时，就应该是用Gadgets授权认证服务。
在对Google Open API授权认证体系有了基本了解后，我们就逐一认识下每种授权认证方式的业务流程。
二、Google ClientLogin授权认证
当你开发的程序是单机版、需终端用户安装的桌面程序时，就要采用ClientLogin的授权认证方式。由ClientLogin的意思，我们基本上就知道该授权认证服务是基于终端用户的帐号信息（即用户名与密码）进行登录校验来进行授权的。
Google ClientLogin授权认证的服务地址是：
https://www.google.com/accounts/ClientLogin 第三方软件拿着用户提供的Google帐号
信息请求该服务地址进行检验，校验通过后，Google服务将Auth Token返回给第三方软件
，这样以后第三方软件就可以拿着这个Auth Token访问该用户在Google上注册的服务资源
。由于第三方软件是单用户使用的，本地安装的软件，所以用户的帐号信息不会泄漏，因
而是安全的。ClientLogin授权认证服务的具体步骤如下图所示：
1．终端用户使用第三方软件操作自己在Google注册的某项服务之前，就会使用自己的帐号去请求Google ClientLogin服务地址。请求只能使用HTTP POST，默认的Content-Type是application/x-www-form-urlencoded类型的。请求需要的参数如下表所示，参数应放在POST请求的包体中。
| 参数 |
描述 |
| accountType |
账户类型：GOOGLE 、HOSTED、HOSTED_OR_GOOGLE |
| |
注册邮箱 |
| Passwd |
注册密码 |
| service |
需授权访问的服务名，服务名格式可以以如下形式提供： companyName-applicationName-versionID |
| source |
申请授权的第三方应用名 |
| logintoken |
可选，验证码的token |
| logincaptcha |
可选，验证码 |
2．Google ClientLogin服务将校验用户的帐号信息，校验通过将为第三方软件颁发Auth Token并放置在响应的包体中。若检验失败将返回403HTTP状态码。
3．第三方软件解析Google ClientLogin服务的响应包体，并解析出Auth token的值。以后只需要带上该token就可以访问用户授权的服务资源。
4．Google服务将响应第三方软件的请求并处理之。
三、Google OAUTH授权认证
当你开发的程序是基于BS的多用户使用的WEB应用时，就可以使用AuthSub授权认证服务或者OAUTH授权认证服务，我们先介绍Google的OAUTH授权认证服务。OAUTH是一种规范，前一篇文章已经对OAUTH规范进行过介绍。既然OAUTH是一种规范，Google OAUTH也应该遵循该规范，所以在此不再对OAUTH展开讨论，只会简单介绍下Google OAUTH服务。
先介绍Google OAUTH三个服务的URL
·请求未授权的Request Token服务地址：
https://www.google.com/accounts/OAuthGetRequestToken
·请求授权的Request Token服务地址：
https://www.google.com/accounts/OAuthAuthorizeToken
·请求Access Token服务地址：
https://www.google.com/accounts/OAuthGetAccessToken
Google OAUTH具体的流程如下图所示：
1.用户使用第三方软件操作用户在Google上的若干个服务资源前，第三方软件先向Google OauthGetRequestToken服务请求办法未授权的Request Token。
2.Google收到第三方软件的请求后，判断该软件是否注册。若软件注册了，就为其颁发未授权的Request Token。
3.第三方软件拿到未授权的Request Token后，向Google OauthAuthorizeToken服务请求用户为其未授权的Request Token进行授权。
4.Google收到第三方软件的请求后，引导用户进行登录授权，并提示用户哪些资源要授权，是否确认授权。
5.用户确认是否授权。
6.若用户同意授权，Google将向用户返回授权的Request Token。
7.第三方软件拿到用户授权的Request Token后，向Google OauthGetAccessToken服务请求将授权的Request Token换取Access Token。
8.Google认证请求，通过认证便向第三方软件颁发Access Token。
9.第三方软件每次访问后只要带上Access Token就可以访问用户授权的资源
10.Google 处理第三方软件的请求。
Google OAUTH 提供了一个Demo 环境，大家可以去http://googlecodesamples.com/oauth_playground/ 体验下。由于本人（本人没有自己的网站，只是想了解下，Yahoo，Flickr对于初学者或者非商业人员提供了非商用的consumer key的申请）一直没有申请到Google OAUTH Consumer key，所以没办法自己写代码去测试。
四、Google AuthSub授权认证
当你开发的程序是基于BS的多用户使用的WEB应用时，可可以考虑采用Google AuthSub的认证方式。那Google AuthSub与Google OAUTH有什么区别了？一、Google OAUTH认证是遵守国际OAUTH规范的，是一种标准化的东西，而Google AuthSub只是Google自己实现的一种方式，是非标准化的；二、Google OAUTH是开放的，与OpenId结合，将Google用户体系与其他服务提供商用户体系、授权服务打通，比Google AuthSub更开放；三、Google OAUTH将请求都进行签名，而AuthSub没有，安全性没有OAUTH高。当然，AuthSub也有自己的优势：第三方应用与Google认证中心交互过程简单，开发人员更容易理解与实现。如果你开发出来的程序只涉及到了Google的服务，不妨先考虑AuthSub认证方式，应该它比Google OAUTH更方便。
Google AuthSub认证流程如下图所示：
1.第三方Web应用向Google 认证中心发起AuthSub认证请求，Google AuthSub的授权认证服务请求地址为：https://www.google.com/accounts/AuthSubRequest 。
2.Google认证中心收到第三方Web应用的AuthSub请求后，将引导用户登录（若用户没有登录）并提醒用户是否将相关受保护资源授权给第三方Web应用。
3.用户登录（若没登录）并确认是否同意授权给第三方Web应用。
4.Google将根据用户的操作响应第三方Web应用。若用户同意授权，将会为第三方Web应用办法Token并返回给第三方应用。
5.第三方Web应用收到Google的Token后，带上它就可以访问用户授权的Google服务资源。
6.Google响应第三方应用请求并将处理结果返回给它。
Google提供了一个Demo，下面是用户登录授权的页面：
