Google 授权体系

 

Google API 授权体系

 

访问 Google API 或者 Google 里面的数据时,第三方应用程序通常需要从首先从 Google 拿到授权。比如说,用户使用了一个第三方应用程序,而此应用程序需要拿用户的日历信息,代表用户拿到 calendar 的信息,首先必须从 Google 得到授权,不能说谁都可以拿用户的敏感信息吧。因此 Google API 的授权体系正是为了保证用户的数据,保护应用程序本身而设计的一整套安全的系统。了解 Google 的授权体系同样有利于我们构建自己的用户认证和授权系统,目前部门的一些系统已经采用了 Google 类似的授权方案。显然,学习好的架构是百利而无一害的。

 

1. Old 授权体系

 

1.1The AuthSub authorization process

 


 

1. 当应用程序需要访问用户的Google 服务时,如日历,Google Doc 等服务时,可以向Google 授权代理服务发起一个AuthSub 的调用。

 

2. 授权服务回应一个访问请求Page ,这个Google 托管的page 要求用户grant\deny 访问他们的google service 的请求。

 

3. 用户决定是否同意该第三方程序访问他们。如果用户拒绝访问,该page 会跳转到Google 页面而不是返回给应用程序。

 

4. 如果用户同意授权,则授权服务将page 重定向给应用程序,这个重定向URL 包含一个授权的token ,这个token 只能使用一次,而且这个token 可以交换成生命周期更长的token

 

5. 应用程序用一个请求访问google 服务,并使用授权token 来代表充当用户的角色。

 

6. 如果 google 认识该 token ,则给应用程序提供请求的数据。

 

1.2 Token和token的管理

每个授权token只是针对一个用户帐号而言的,但是对于该帐号的多个服务可以使用同一个token。Tokens可以限制在某个范围之内。例如,个人的服务可以限制访问某个特定类型的数据或者活动(如限制对该数据只提供只读的权限)

你可以选择使用一次性的tokens或者session tokens,依赖于你的应用程序使用token的用途。一次性使用的token允许应用程序发送单个的对Google service的调用。而session token允许让应用程序无限次调用Google service。Session tokens不会过期。当使用session tokens,你的应用程序应该存储每个用户对应的session token,而不是每次都请求新的token。如果想看token管理的其它选项,请看“Working with AuthStub”

经过注册的web应用程序可以在他们的AuthStub中指定一个安全的token,当使用secure token调用Google service的时候,应用程序必须对request进行数字化签名,包含token和在request header里面的签名。该请求可能包含一个时间戳以提高安全性以防止重放攻击。如果想了解更多的关于使用secure token的信息,可以参考 “Signing request”。除了这些变化,AuthStub使用secure和非secure tokens的请求流程是相同的。

 

Note:一些Google services只允许那些已经注册过和使用安全tokens的web应用程序访问


1.3注册

如果你正在使用AuthSub,你可以选择注册你的应用程序,并且通过创建安全证书为你的用户提供更好的安全性。尽管大多数Google services允许未注册的应用程序访问,而有些需要更多的安全访问。如果需要更多关于注册流程的信息,请参考Registration for Web Applications

 

1.4 Working with AuthSub

整合AuthSub,你需要做以下工作:

1.首先决定你的应用程序是否需要注册
经过注册的应用程序有个优势是让Google认识你。在Google 登录页面显示给用户标准的警告将被滤除或者修改,另外经过注册的程序是通过描述名来识别,而不是仅仅是通过调用的URL。记住有些Google service强制要求应用程序必须经过注册,如果你选择注册,请使用自动化的注册流程。

如果你注册,你也可以提供一个安全证书和key。有证书的经过注册的web 程序能够获取安全token。

2.决定使用什么类型的tokens和怎么去管理他们
从Google拿到授权的token是用于以后和特定的Google service进行交互的。选择一次性的token还是session token取决于你的应用程序的与google service交互的类型,例如单次使用的token适合于只需要交互一次或者很少需要尽兴交互的情况。

如果你选择使用session tokens,并且使用他们进行常规的对Google服务的访问,你的额应用程序将需要管理token的存储,包括跟踪为user和google service的token正确性,Google 帐号并不是为了管理大量的tokens,并且实际上不允许多余10个以上正确的tokens(对于每个应用程序,每个用户),如果有必须这种限制允许程序使用多个tokens去覆盖不同的服务。如果你决定存储session tokens,这些tokens应该象对待其他敏感信息一样要进行安全保护。

 

3.决定Google service的访问的scope

service他们自己决定允许什么类型的访问并且允许访问多少内容。这种访问是通过一个scope的值来表达的。一个服务的scope可以是一个简单的URL来代表整个service,或者可以指定更加严格的访问。一些服务对访问提出了非常高的限制,例如对某些限制性的内容只提供只读的访问。要获取你想要访问的Google service的scope,请参考相应service的文档。你必须尽量指定更严格的scope,例如,如果你想要访问Gmail的Atom feed feature,应尽量使用"http://www.google.com/calendar/feeds/"的scope而不是"http://www.google.com/calendar/",Google service对large scope的请求更加严格。

 

4.准备一种机制去发送和接收授权token

这种机制必须产生一个正确的AuthSub request的调用,包括指定合适的scope的URL值和next url。如果你正在使用安全的token或者你正在使用session tokens,这个请求必须也包含这些变量的值。

Next的URL可以包含查询参数。例如,当支持多语言版本时,可以包含一个web应用程序语言版本的查询参数,那么next的URL:http://www.yoursite.com/Retrievetoken?Lang=de 的请求,会产生一个
http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE的redirect。解析token和语言参数可以保证重定向到指定语言的site。

这种token机制必须解析从Google redirect回来的token参数,这个token是单个使用的token,因为授权tokens是针对一个用户而言的,应用程序必须能将这个token跟这个用户关联起来。你可以使用cookie来关联user和token,当google将带有token的url将user重定向回到你的site时,你的程序可以读取cookie并关联到正确的user。

 

5.准备一种机制去请求session token,别且存储或者销毁他们

取决于你选择哪一种token管理,你可能需要创建一种机制去获取和销毁session tokens(AuthSubSessionToken and AuthSubRevokeToken)。 测试session和销毁机制,使用AuthSubTokenInfo,这个对象可以表明一个token是否正确。如果存储token,应用程序必须跟踪user ID和token覆盖service的范围。

 

6.准备一种机制去请求对Google service的访问
请参考具体访问的google service所要求的格式。所有对Google service的请求必须包含一个正确的授权。一般来说,对Google service的请求是HTTP GET请求,token放在请求的头里:

请求头必须是下面的形式;

Authorization: AuthSub token="token"

这里的token是授权的token,单个使用的还是session token。如果token是安全的,还必须包含一个数字签名,请参考"Signing requests"了解更多的具体情况。

下面的例子是阐述一个请求头里面发送的Google calendar feed service的格式,这个请求头里的token不是一个安全的token:

GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

 

参考资料:
1.http://code.google.com/intl/en/apis/accounts/docs/GettingStarted.html#OAuth2
2.http://code.google.com/intl/zh-TW/apis/accounts/docs/AuthSub.html

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值