【转】oauth2开放认证协议原理及案例分析

标签: oauth2 认证 原理 | 发表时间:2014-04-17 03:33 | 作者:gdfdfg
分享到:
出处:http://www.iteye.com

之前翻译过一篇 
OAuth认证协议原理分析及使用方法
,虽然 OAuth2还没有正式发布,但是国内外的OAuth2的采用情况几乎要完全替代掉OAuth1.1了。像淘宝、腾讯、人人网、百度开放平台就已经采用Oauth2,新浪微博也发来邮件说是要很快上马OAuth2,彻底替换掉OAuth1.1。目前OAuth2到了
v20草稿阶段
,最新的版本是 2011年7月25号发布的,协议变化还是很快的,所以看到国内的一些已经实现的实例,再比照官方的 oauth2,会有些出入的。

为何要 OAUTH2来替换OAUTH1.1?

  • 一、OAuth2大大简化了认证流程,OAuth1版本,我都感觉有些流程设计不是为安全性而存在,有些东西很难想一个理由,他们为何要弄得如此复杂。复杂可能是增加安全性的一个要素,但是也极大增加了开发者的开发难度。
  • 二、增加了对多种不同方式的认证,原来的认证只能直接或间接通过浏览器,现在有专门的标准来给客户端程序、移动应用、浏览器应用提供认证的方法。

OAUTH2的四种角色

  • resource owner资源所有者:比如twitter用户,他在twitter的数据就是资源,他自己就是这些资源的所有者。
  • resource server资源服务器:保存资源的服务器,别人要访问受限制的资源就要出示 Access Token(访问另牌)。
  • client客户端:一个经过授权后,可以代表资源所有者访问资源服务器上受限制资源的一方。比如 开发者开发的应用。
  • authorization server授权服务器:对 资源所有者进行认证,认证通过后,向 客户端发放 Access Token(访问另牌)。

OAUTH2取得ACCESS TOKEN的四种方式

  • 一、Authorization Code授权码方式:这种是推荐使用的,也是最安全的,也是替换OAuth1.1的一种授权方式。
    流程:
    1、引导用户访问授权服务器,比如地址:

     

    ?
    1
    2
    3
    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

    ,其中response_type 值固定为 code,client_id就是客户端申请开发者的时候取得的 appkey,state是一个可选参数,可以用于保存客户端在引导用户转向前的一些状态,当回到 redirect_uri的时候会原封不动的传回来,redirect_uri是当用户确认授权应用访问的时候跳转回来的地址。
    2,用户同意授权后跳转回来的的地址如:

    ?
    1
    2
    3
    HTTP/1.1 302 Found
    Location: https: //client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

    &state=xyz ,其中 code就是 Authorization Code,state就是上面所说的可选参数。
    3,使用取得的 Authorization Code去换取Access Token:

    ?
    1
    2
    3
    4
    5
    6
    7
    POST /token HTTP/1.1
    Host: server.example.com
    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
     
    =authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

    其中 Authorization是由Client id(app key)及Client password(app secret)组合成的 http basic 验证字符串,grant_type必须为 authorization_code,code是上一步取得的 Authorization Code,redirect_uri是完成后跳转回来的网址。
    如果Client不能发送 Authorization信息,则可以使用下面的方式,/token这个地址必须是 https连接的,不然就有泄露 client secret的可能性:

    ?
    1
    2
    3
    4
    5
    6
    POST /token HTTP/1.1
    Host: server.example.com
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
     
    grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
    &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

    成功的话返回的信息为:

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache
     
    {
       "access_token" : "2YotnFZFEjr1zCsicMWpAA" ,
       "token_type" : "example" ,
       "expires_in" :3600,
       "refresh_token" : "tGzv3JOkF0XG5Qx2TlKWIA" ,
       "example_parameter" : "example_value"
    }
  • 二、Implicit Grant隐式授权:相比授权码授权,隐式授权少了第一步的取Authorization Code的过程,而且不会返回 refresh_token。主要用于无服务器端的应用,比如 浏览器插件。隐式授权不包含Client授权,它的授权依赖于 资源所有者及注册应用时候所填写的redirection URI(跳转地址)。因为Access token是附着在 redirect_uri 上面被返回的,所以这个 Access token就可能会暴露给 资源所有者或者设置内的其它方(对资源所有者来说,可以看到redirect_uri,对其它方来说,可以通过监测浏览器的地址变化来得到 Access token)。
    流程
    一、引导用户访问一个专门的授权页面,如

     

    ?
    1
    2
    3
    GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
         &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

    这里的 response_type为 token,client_id为appkey。可以看到这里取Access token的过程中并没有像 第一种方式那样传入 client_secret。因为如果你传入 client_secret,其实就是相当于告诉用户,你应用的app secret了。
    二、在成功授权后,跳转回到 redirect_uri所定义的网址

    ?
    1
    2
    3
    HTTP/1.1 302 Found
    Location: http: //example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

    ,这样应用就可以通过取地址中的 fragment部分来取得 access token。

  • 三、Resource Owner Password Credentials资源所有者密码证书授权:这种验证主要用于资源所有者对Client有极高的信任度的情况,比如操作系统或高权限程序。只有在不能使用其它授权方式的情况下才使用这种方式。
    流程:
    一、提交信息到取 token页面

     

    ?
    1
    2
    3
    4
    5
    6
    POST /token HTTP/1.1
    Host: server.example.com
    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
     
    grant_type=password&username=johndoe&password=A3ddj3w

    这里的 Authorization是 client_id为username,client_secret为password的http basic验证码。grant_type必须为 password,username为用户名,password为用户密码。
    取得的结果如下:

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache
     
    {
       "access_token" : "2YotnFZFEjr1zCsicMWpAA" ,
       "token_type" : "example" ,
       "expires_in" :3600,
       "refresh_token" : "tGzv3JOkF0XG5Qx2TlKWIA" ,
       "example_parameter" : "example_value"
    }

    Q:为何要这种这么不安全的方式?
    A:取代原来原始的 username,password的授权方式,而且不需要 client保存用户的密码,client只要保存access token就可以。主要用于客户端程序。

  • 四、Client Credentials客户端证书授权:这种情况下 Client使用自己的 client证书(如 client_id及client_secret组成的 http basic验证码)来获取 access token,只能用于信任的client。
    流程:
    一、提交参数取 access token

     

    ?
    1
    2
    3
    4
    5
    6
    POST /token HTTP/1.1
    Host: server.example.com
    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
     
    grant_type=client_credentials

    其中 Authorization是client_id及client_secret组成的 http basic验证串。grant_type必须为client_credentials,
    返回如下:

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache
     
    {
       "access_token" : "2YotnFZFEjr1zCsicMWpAA" ,
       "token_type" : "example" ,
       "expires_in" :3600,
       "example_parameter" : "example_value"
    }

国内一些OAUTH2案例分析

标准的 oauth2中,使用 access token来向资源服务器发出请求,取得资源。这里的资源服务器需要使用 https协议,否则access token极可能被其它方获取。比如

?
1
2
3
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw


bearer是指 token类型
,后面的字符串就是access token。还有一种 
mac类型的 token(目前v20版本的草稿里还没有文档)
,如:

?
1
2
3
4
5
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id= "h480djs93hd8" ,
                    nonce= "274312:dj83hs9s" ,
                    mac= "kDZvddkndxvhGRXZhvuDjEWhGeE="

,因为 https速度相较http慢,而且并非所有服务器或客户都支持https,所以国内一些网站采用一种http也可访问资源的方式。


淘宝开放平台的方式
:应用通过用户授权获取的AccessToken的值即等同于Sessionkey,应用凭借AccessToken调用taobao API即可。查看淘宝SDK,可以看到 其使用应用的app_secret作用密码钥来进行签名,参数里面包含了 这个Sessionkey,这样淘宝在收到这个请求的时候,根据 app_id来判断是哪个应用,根本sessionkey的值来判断是哪个用户,如果不传这个 sessionkey就用 app_id查得app_id所属的淘宝用户就行了。也就是说 sessionkey必须配合 这个 client自己的授权资料appkey appsrecet来访问资源。


百度开放平台方式

人人网方式
、还有腾讯也类似:在返回 access token的同时返回 sessionKey及sessionSecret。如:

?
1
2
3
4
5
6
7
8
{
     "access_token" : "1.a6b7dbd428f731035f771b8d15063f61.86400.1292922000-2346678-124328" ,
     "expires_in" : 86400,
     "refresh_token" : "2.385d55f8615fdfd9edb7c4b5ebdc3e39.604800.1293440400-2346678-124328" ,
     "scope" : "basic email" ,
     "session_key" : "9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=" ,
     "session_secret" : "27e1be4fdcaa83d7f61c489994ff6ed6" ,
}

在调用资源API的时候,如下:

?
1
2
GET /rest/2.0/passport/users/getInfo?session_key=9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A%3D&timestamp=2011-06-21+17%3A18%3A09&format=json&uid=67411167&sign=d24dd357a95a2579c410b3a92495f009 HTTP/1.1
Host: api.example.com

这里参数里面的 session_key,传给服务器后,用户查询 session_secret,sign使用session_secret作为密钥来加密的。可以看到这里调用的时候没有使用 client_id或client_secret信息,所以对于任何获取

?
1
2
"session_key" : "9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=" ,
"session_secret" : "27e1be4fdcaa83d7f61c489994ff6ed6" ,

的一方都可以调用到API。降低系统耦合度。

原文地址:http://kejibo.com/oauth2/



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [oauth2 认证 原理] 推荐:

【转】oauth2开放认证协议原理及案例分析

- - 研发管理 - ITeye博客
OAuth认证协议原理分析及使用方法. ,虽然 OAuth2还没有正式发布,但是国内外的OAuth2的采用情况几乎要完全替代掉OAuth1.1了. 像淘宝、腾讯、人人网、百度开放平台就已经采用Oauth2,新浪微博也发来邮件说是要很快上马OAuth2,彻底替换掉OAuth1.1. ,最新的版本是 2011年7月25号发布的,协议变化还是很快的,所以看到国内的一些已经实现的实例,再比照官方的 oauth2,会有些出入的.

使用Spring Security Oauth2完成RESTful服务password认证的过程 - 王安琪

- - 博客园_首页
        摘要:Spring Security与Oauth2整合步骤中详细描述了使用过程,但它对于入门者有些重量级,比如将用户信息、ClientDetails、token存入数据库而非内存. 配置过程比较复杂,经过几天时间试验终于成功,下面我将具体的使用Spring Security Oauth2完成password认证的过程记录下来与大家分享.

ssh密钥认证原理

- - 寒江孤影
SSH之所以能够保证安全,原因在于它采用了公钥加密. 整个ssh密码登录过程是这样的:. 1)用户向远程主机发登录请求:ssh user@远程主机. 2)远程主机收到用户的登录请求,把自己的公钥发给用户. 2)用户使用这个公钥,将登录密码加密后,发送回远程主机. 3)远程主机用自己的私钥,解密登录密码,如果密码正确,就同意用户登录.

Spring security oauth2最简单入门环境搭建--二、干货

- - ITeye博客
关于OAuth2的一些简介,见我的上篇blog: http://wwwcomy.iteye.com/blog/2229889 PS:貌似内容太水直接被鹳狸猿干沉. 友情提示 学习曲线:spring+spring mvc+spring security+Oauth2基本姿势,如果前面都没看过请及时关闭本网页.

webservice认证

- - 行业应用 - ITeye博客
1、服务器端,增加拦截认证--ServerPasswordCallback.java.                 throw new WSSecurityException("用户不匹配.                 throw new WSSecurityException("密码不匹配.

oauth 认证心得

- 非狐外传 - python.cn(jobs, news)
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准. 简易来说,就是我们可以在某一个第三方服务器,如:新浪,豆瓣,在用户授权,并且不透漏密码等信息给我们的条件下,访问和修改用户的资源. oauth的项目主页为:http://oauth.net/ ,现在国内很多网站的开放平台都采用了Oauth方式来进行授权.

jass登录认证

- - 行业应用 - ITeye博客
Java 认证和授权服务”(Java Authentication and Authorization Service,JAAS)是对 Java 2 SDK 的扩展. JAAS 可分Authentication和Authorization. 1)  Authentication:认证用户身份. 通俗的来说就是哪个用户在执行操作.

Google+ 支持加 V 认证

- Nanqi - 36氪
在 Google+ 上看到一个叫 +truant 的人不确定是不是我. Google+ 团队的 Wen-Ai Yu 宣布 Google+ 推出了认证帐户(相当于新浪微博的加V),在用户的个人档案页面,会有一个蓝色的对勾,提示你这是一个 verified name (认证帐户). 鼠标悬停放上去会显示这个人的认证信息.

Google Translate Beatbox 获得官方认证

- OrcaXS - 谷奥——探寻谷歌的奥秘
上个月底一群无聊人发明了用 Google Translate 的 TTS 引擎玩 Beatbox,很显然 Google 的工程师们都没想到用户还能玩出这些花样,随后他们彻底被折服,并且将这一功能正式加入到 Google Translate 中. 如上图,现在在 Google Translate 中输入 "pv zk pv pv zk pv zk kz zk pv pv pv zk pv zk zk pzk pzk pvzkpkzvpvzk kkkkkk bsch " 等 Beatbox 触发句的话,你会发现左下角喇叭边上的文字从 Listen 变成了 Beatbox,真是赞到飞起啊.

Google+开始实名认证用户

- changke - Solidot
Google坚持在Google+中采用实名制的做法引起了许多用户的不满,现在Google更进一步的推出了实名认证徽章. Google雇员Wen-Ai Yu在Google+上发帖称,Google正逐步推广实名认证徽章,此举是为了确保被用户加到圈子里的人是他们想要圈起来的人. 她表示,Google第一步的重点认证对象是公众人物和名人,以及被大量用户加到圈子里的人,之后将会扩大到其他人.