OAuth2 培训

timo_jiang 贡献于2012-05-10

作者 liubing  创建于2011-11-10 05:06:00   修改者liubing  修改于2012-02-16 09:43:00字数7955

文档摘要:OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。 OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息,而不需要分享他们的访问许可或他们数据的所有内容。
关键词:

 前言 1 简介 2 认证和授权过程 2 简单历史回顾 3 Oauth2核心参数说明 4 Oauth2取得Access Token的五种方式 4 一、Authorization Code授权码方式 4 二、Implicit Grant隐式授权 7 三、Resource Owner Password Credentials资源所有者密码证书授权 8 四、Client Credentials客户端证书授权 8 五、刷新令牌方式 10 参考资料 11 学习 11 前言 为什么需要开放平台以及验证授权技术? 1. 服务整合,大势所趋 如果在前几年,将不同公司提供的多种服务整合在一起提供给用户,还是一个稀罕事。而如今,互联网服务之间的整合已经由新奇事物慢慢成为主流。 举个简单的例子,如果你是个微博达人,同时具有人人网、开心网、新浪微博、搜狐微博等多个SNS和微博帐号,有时候你想表达一个观点并把这个信息发布到所有这些网站,那么悲剧了,你需要不厌其烦地分别登录各家网站并采用拷贝粘贴的方式一一发布。不过现在好了,你只要使用一个叫“微博通”的客户端,就可以一次操作将信息同步到所有网站了。这个“微博通”就是个第三方应用,它整合了所有这些SNS和微博网站的服务。 实际上,互联网服务之间整合的大趋势,已经为互联网从业者提供了越来越多的创业机会。既然有现成的服务可以利用,你为何要从零开始呢?   2. 安全的保障——验证与授权 如果没有开放平台提供的服务,类似“微博通”这样的第三方能否实现上述功能呢?也可以!下面以人人网作为开放平台方进行论述。我们可以设想,用户将自己的人人网帐号和密码告知微博通,存储在微博通的服务器上。当用户通过微博通发送状态并同步回人人网时,微博通的服务器就可以利用人人网的帐号和密码来模拟用户进行操作了。 msn:liubingbbbb@hotmail.com 但是,这种方式存在着严重的安全问题: (1) 用户的帐号和密码完全暴露在第三方服务提供商面前。这样第三方就可以代替用户做任何事情,甚至包括修改用户的密码,将用户的帐号据为己有。 (2) 第三方的技术缺陷带来的安全隐患。即使这个第三方是我们高度信任的,不会主动作恶,但还是难以避免由于第三方本身技术原因带来的安全隐患。如第三方服务器发生信息泄露,那么上面存储的人人网的这些帐号信息也就危险了。而且这样的安全隐患是我们完全不可控的。 (3) 授权无法限制和回收。我们无法限制第三方的操作权限范围,如我们无法做到只允许第三方代替用户修改状态而不允许修改用户个人资料,而这恰恰是用户关心的隐私问题。另外,如果我们想把权限从第三方收回,也没有任何好的办法,那就只能让每个用户自己修改密码了。 为了解决这些问题,我们就需要提供一种安全的方式来便于第三方整合人人网的服务,这就是开放平台要做的事情。而这其中的关键便是验证和授权技术。 所谓验证,英文词汇叫“authentication”,就是识别出你是谁。这包含两种类型的验证:一个是对于用户的验证,即识别出你是用户A还是用户B;第二个是对于第三方服务器的验证,即识别出一个服务器请求是“小小战争”发出的还是“Q将三国”发出的。 所谓授权,英文词汇叫“authorization”,就是用户对第三方授予某种操作权限,允许第三方在一定范围内代替用户进行操作。例如,用户授予微博通一个“发布状态”的权限,从而允许微博通代表用户修改他的人人网状态。关键在于,用户如果不同意授权给第三方应用,那么第三方应用的行为就没有机会侵犯到用户的隐私。   总之,验证和授权是开放平台的一道大门,它在保护用户隐私、确保调用安全方面起着重要的作用,这也就是它为什么在开放平台技术体系中显得那么重要的原因了。 简介 OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。 OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息,而不需要分享他们的访问许可或他们数据的所有内容。 认证和授权过程 在认证和授权的过程中涉及的三方包括: msn:liubingbbbb@hotmail.com · 服务提供方,用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表。 · 用户,存放在服务提供方的受保护的资源的拥有者。 · 客户端,要访问服务提供方资源的第三方应用,通常是网站,如提供照片打印服务的网站。在认证过程之前,客户端要向服务提供者申请客户端标识。 使用OAuth进行认证和授权的过程如下所示: 1. 用户访问客户端的网站,想操作用户存放在服务提供方的资源。 2. 客户端向服务提供方请求一个临时令牌。 3. 服务提供方验证客户端的身份后,授予一个临时令牌。 4. 客户端获得临时令牌后,将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。 5. 用户在服务提供方的网页上输入用户名和密码,然后授权该客户端访问所请求的资源。 6. 授权成功后,服务提供方引导用户返回客户端的网页。 7. 客户端根据临时令牌从服务提供方那里获取访问令牌。 8. 服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。 9. 客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。 简单历史回顾 OAuth 1.0在2007年的12月底发布并迅速成为工业标准。 2008年6月,发布了OAuth 1.0 Revision A,这是个稍作修改的修订版本,主要修正一个安全方面的漏洞。 msn:liubingbbbb@hotmail.com 2010年四月,OAuth 1.0的终于在IETF发布了,协议编号RFC 5849。 OAuth 2.0的草案是在今年5月初在IETF发布的。 OAuth是个安全相关的协议,作用在于,使用户授权第三方的应用程序访问用户的web资源,并且不需要向第三方应用程序透露自己的密码。 OAuth 2.0是个全新的协议,并且不对之前的版本做向后兼容,然而,OAuth 2.0保留了与之前版本OAuth相同的整体架构。 这个草案是围绕着OAuth2.0的需求和目标,历经了长达一年的讨论,讨论的参与者来自业界的各个知名公司,包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。 OAuth长期以来都被视为快速开放技术的典范,OAuth 2.0也不例外。Facebook和Twitter甚至已经宣布在官方发布第一个草案前的就会开始支持OAuth 2.0。 Oauth2核心参数说明 grant_type参数说明表格: grant_type 说明 authorization_code 标准的Server授权模式 password 基于用户密码的授权模式 client_credentials 基于APP密钥的授权模式 refresh_token 刷新accessToken     response_type参数说明表格: response_type 说明 code 标准的Server授权模式响应模式 token 脚本的授权响应模式,直接返回token,需要对回调进行校验 Oauth2取得Access Token的五种方式 一、Authorization Code授权码方式 标准的的Server授权模式,与目前开放平台的Session机制很像。   1.用户访问授权服务器,比如地址: ? msn:liubingbbbb@hotmail.com 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.同意授权后跳转回来的的地址如 § HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz § 其中 code就是 Authorization Code,state就是上面所说的可选参数。   3.取得的 Authorization Code去换取Access Token  § POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8   grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA msn:liubingbbbb@hotmail.com &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的可能性: § 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 § 成功的话返回的信息为: § HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache   {   "access_token":"2YotnFZFEjr1zCsicMWpAA", msn:liubingbbbb@hotmail.com   "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)。 流程 一、引导用户访问一个专门的授权页面,如 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所定义的网址 § HTTP/1.1 302 Found § Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA §           &state=xyz&token_type=example&expires_in=3600 msn:liubingbbbb@hotmail.com 这样应用就可以通过取地址中的 fragment部分来取得 access token 三、Resource Owner Password Credentials资源所有者密码证书授权 验证主要用于资源所有者对Client有极高的信任度的情况,比如操作系统或高权限程序。只有在不能使用其它授权方式的情况下才使用这种方式。 流程:  提交信息到取 token页面 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为用户密码。 取得的结果如下: 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 msn:liubingbbbb@hotmail.com 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, 返回如下: § 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" msn:liubingbbbb@hotmail.com }    国内一些OAUTH2案例分析 标准的 oauth2中,使用 access token来向资源服务器发出请求,取得资源。这里的资源服务器需要使用 https协议,否则access token极可能被其它方获取。 五、刷新令牌方式 适用于所有有Server端配合的应用 refresh token的作用:就是换取新的access token和refresh token,以达到access token持续有效 例如: Sina公共登录授权页面 https://api.t.sina.com.cn/oauth2/authorize?client_id=496934491&redirect_uri=http%3A%2F%2Fwww.paidai.com%2Fuser%2Foauth_sina.php%3Ffrom%3Dweibo&response_type=code 淘宝公共登录授权页面 https://oauth.taobao.com/authorize?response_type=code&client_id=12368999&redirect_uri=http%3A%2F%2Fwww.paidai.com%2Fuser%2Foauth_taobao.php&state=1 msn:liubingbbbb@hotmail.com https://openapi.baidu.com/oauth/2.0/token?grant_type=refresh_token&refresh_token=2.e8b7dbabc28f731035f771b8d15063f23.5184000.1292922000-2346678-124328&client_id=Va5yQRHlA4Fq4eR3LT0vuXV4&client_secret=0rDSjzQ20XUj5itV7WRtznPQSzr5pVw2&scope=email msn:liubingbbbb@hotmail.com 参考资料 学习 · http://www.oauth.net/2/ auth在auth组织的主页面 · http://hueniverse.com/2010/05/introducing-oauth-2-0/ auth2.0介绍 · http://baike.baidu.com/view/6619164.htm 百度百科对auth2的介绍 · http://zh.wikipedia.org/zh/OAuth auth维基百科 · http://dev.baidu.com/wiki/connect/index.php?title=%E7%99%BE%E5%BA%A6OAuth2.0%E5%AE%98%E6%96%B9%E5%8F%82%E8%80%83%E6%96%87%E6%A1%A3 百度auth2 api文档 · http://wenku.baidu.com/view/b37ed7260722192e4536f66e.html OAuth 2.0中文译本 msn:liubingbbbb@hotmail.com

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 2 人已下载

下载文档