国内开放平台泛滥,大多使用的是OAuth或其变形,但对于openID则了解较少。

当前有一个需求,核心其实是用户的身份验证,从目前看来,并没有后续资源访问了,使用oauth感觉小题大做。而如果自己定义协议,又增加了用户的学习成本,且有安全性等疏漏的隐患。

OpenID和OAuth的区别及第三方登录的安全隐患分析一文中,作者分析了openID与OAuth的区别:

OpenID和OAuth完全是为了两种不同的需求而生

OpenID的目标是为了帮助网站确认一个用户的身份
OAuth的目标是为了授权第三方在可控范围下访问用户资源

同时,http://www.slideshare.net/gongjt/oauthopenid 里也比对比了两者,并给出国内目前可用的openID案例:比如http://www.lepu.com/login使用了google的openID.

—————————

综合以上的分析,对于需要开放资源的平台而言,oauth更合适。而仅提供用户身份验证的平台,openID就足够用了。考虑到我们的需求,以下详细研究OAuth2.0。

具体的计划是:

  1. 泛读OAuth2.0 draft协议
  2. 泛读百度内部文档中,关于OAuth的部分,关注有哪些部门选用了OAuth,是哪个版本或者变种,实现机制是什么?
  3. 结合步骤2,以及网络上关于OAuth实现版本的分析,快速浏览两到三种OAuth2.0 server端的php开源代码,并进行搭建,分析其性能/安全性/可扩展性/协议实现的完整程度
  4. 选用一种实现代码,进行必要的修改
  5. 选择对应的OAuth client SDK,完成授权流程
  6. 结合业务需求,开发open api,完成一期api开发流程

出于时间的考虑,目前仅focus在web server scenarios上,不考虑js/mobile等场景。

大多数OAuth2.0实现的授权过程如下:

1. app方,根据appkey/return_url(授权成功后返回的url)等,拼成授权登录的url,header user 到这个url(该url部署在授权服务器上)

2.user在这个url页面里,登录,并同意授权给该app

3.授权服务器验证用户登录和授权成功,生成request_token/request_token_secret,拼在return_url后面,header user到该return_url(加密和签名后的)

4.app方,根据该request_token/appkey,生成获取access_token的api url(该url也部署在授权服务器上),调用该api;授权服务器检查requset_token和appkey是否匹配,生成access_token/access_token_secret,作为返回值;app方,获取返回值中的access_token/access_token_secret,并保存。

5.app方,利用access_token,调用资源服务器提供的api

资料:

1. oauth2-11 版本中文译文 http://wenku.baidu.com/view/b37ed7260722192e4536f66e.html

2.oauth2-26 英文版 http://tools.ietf.org/html/draft-ietf-oauth-v2-26

3.Using OAuth 2.0 to Access Google APIs https://developers.google.com/accounts/docs/OAuth2?hl=zh-CN

4.OAuth官网 http://oauth.net/

Leave a Reply