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

标签: oauth2 开放 认证 | 发表时间:2014-04-17 11: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,会有些出入的.

使用OAUTH2+Zuul实现认证和授权 GitHub - wiselyman/uaa-zuul:

- -
在 Spring Cloud需要使用 OAUTH2来实现多个微服务的统一认证授权,通过向 OAUTH服务发送某个类型的 grant type进行集中认证和授权,从而获得 access_token,而这个token是受其他微服务信任的,我们在后续的访问可以通过 access_token来进行,从而实现了微服务的统一认证授权.

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

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

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 (认证帐户). 鼠标悬停放上去会显示这个人的认证信息.

ssh密钥认证原理

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

HTTP API 认证授权术

- - 酷 壳 – CoolShell
我们知道,HTTP是无状态的,所以,当我们需要获得用户是否在登录的状态时,我们需要检查用户的登录状态,一般来说,用户的登录成功后,服务器会发一个登录凭证(又被叫作Token),就像你去访问某个公司,在前台被认证过合法后,这个公司的前台会给你的一个访客卡一样,之后,你在这个公司内去到哪都用这个访客卡来开门,而不再校验你是哪一个人.