互联网工程任务组（IETF）E.锤Lahav，埃德。 请求评论：2010年4月5849 分类：信息 ISSN：2070至1721年 OAuth的1.0协议 摘要 OAuth的为客户提供了一个方法来访问服务器资源 资源所有者的代表（如不同的客户端或结束 用户）。它还提供了一个过程，为最终用户授权第三 党访问到他们的服务器资源不共享 凭据（通常情况下，对用户名和密码），使用用户 代理重定向。 本备忘录的状态 这个文件是不是一个Internet标准跟踪规范，它是 发表，供参考之用。 这个文件是互联网工程任务组的产品 （IETF）的。它代表了IETF的社会共识。它有 接受公众审查批准，并已出版 互联网工程指导组（IESG）。不是所有文件 IESG批准的任何级别的互联网的候选人 标准，请参阅RFC 5741的第2条。 有关本文档的当前状态，任何勘误， 以及如何提供反馈，可于 http://www.rfc-editor.org/info/rfc5849。 版权声明 版权所有（c）2010 IETF信托基金和作为确定的人 文档作者。保留所有权利。 这个文件是受口岸78和IETF的信托的法律 IETF文档的有关规定 （http://trustee.ietf.org/license-info）中的日期起生效 本文件的出版。请仔细阅读这些文件 小心，因为它们描述了您的权利和尊重的限制 本文件。从这份文件中提取的代码组件 包括简体BSD许可证文本在第4.E 信托和法律规定，提供不附带作为 描述在简体的BSD许可证。 锤Lahav信息[1] RFC 5849 OAuth的1.0 2010年4月 目录表 1。简介................................................. ... ... 3 1.1。术语................................................ 4 1.2。示例................................................. ... ... 5 1.3。符号约定..................................... 7 2。重定向为基础的授权................................. 8 2.1。临时全权证书...................................... 9 2.2。资源所有者的授权.............................. 10 2.3。令牌凭据......................................... 12 3。经过身份验证的请求......................................... 14 3.1。提出要求........................................... 14 3.2。验证要求........................................ 16 3.3。nonce和时间戳....................................... 17 3.4。签名................................................. 18 3.4.1。签名基本字符串.............................. 18 3.4.2。HMAC - SHA1算法.......................................... 25 3.4.3。RSA - SHA1 ........................................... 25 3.4.4。PLAINTEXT .......................................... 26 3.5。参数传递.................................... 26 3.5.1。Authorization头............................... 27 3.5.2。表单编码的机构.................................. 28 3.5.3。请求URI查询.................................. 28 3.6。百分比编码.......................................... 29 4。安全注意事项........................................ 29 4.1。RSA - SHA1签名方法................................. 29 4.2。保密性要求............................... 30 4.3。欺骗通过假冒服务器........................... 30 4.4。代理和缓存的验证内容............. 30 4.5。明文存储的凭据.......................... 30 4.6。保密客户端凭据......................... 31 4.7。钓鱼攻击.......................................... 31 4.8。划定范围的访问请求................................ 31 4.9。熵的秘密........................................ 32 4.10。拒绝服务/资源耗尽攻击.......... 32 4.11。SHA - 1加密攻击.............................. 33 4.12。签名基本字符串限制........................ 33 4.13。跨站点请求伪造（CSRF）........................ 33 4.14。用户界面申诉................................... 34 4.15。自动处理重复授权............ 34 5。致谢................................................ 35 附录A.从社区版的差异............... 36 6。参考文献................................................. .... 37 6.1。规范性引用文件...................................... 37 6.2。资料性参考文献.................................... 38 锤Lahav信息[第2页] RFC 5849 OAuth的1.0 2010年4月 1。简介 OAuth协议最初创建一个小社区的Web 开发商从各种网站和其他互联网服务世界卫生组织 要解决使委派访问的常见问题 受保护的资源。由此产生的OAuth协议稳定在 1.0版在2007年10月，并于2009年6月修订（修订版A） 在<http://oauth.net/core/1.0a>出版。 本规范规定的OAuth的信息文档 核心1.0修订版A，地址，因为这几个勘误报告 时间，使众多的编辑澄清。虽然这 规范并不是IETF的OAuth的工作组，项目 在写作时是OAuth的版本，可以 适合在标准轨道上刊登，它已 转移到IETF变更控制原始作者 工作。 在传统的客户机 - 服务器的身份验证模型，客户端 使用其凭据来访问服务器托管其资源。 随着越来越多地使用分布式Web服务和云 计算，第三方应用程序需要访问这些服务器 托管资源。 OAuth的引入了第三个角色，以传统的客户机 - 服务器 身份验证模式：资源的所有者。在OAuth的模型， 客户端（这是不是资源的所有者，但代表其行事） 请求访问资源的所有者所控制的资源，但 由服务器托管。此外，OAuth的允许服务器验证 不仅是资源的所有者的授权，但也是身份 客户端提出请求。 OAuth的为客户提供了一个方法来访问服务器资源 资源所有者的代表（如不同的客户端或结束 用户）。它还提供了一个过程，为最终用户授权第三 党访问到他们的服务器资源不共享 凭据（通常情况下，对用户名和密码），使用用户 代理重定向。 例如，一个网络用户资源的所有者可以授予印刷服务 （客户端）访问她的私人照片存储在照片共享 服务（服务器），如果没有她的用户名和密码与共享 印刷服务。相反，她验证直接与照片 共享服务问题的印刷服务代表团 凭据。 锤Lahav信息[第3页] RFC 5849 OAuth的1.0 2010年4月 在为客户端访问资源时，它首先必须获得 从资源所有者的许可。此权限表示 令牌的形式和配套共享秘密。的目的 令牌是不必要的资源所有者分享其 与客户端的凭据。不同的是资源的所有者凭证， 令牌可发出与一个受限制的范围和使用寿命有限， 撤销独立。 本规范由两部分组成。第一部分定义了一个 基于重定向用户代理进程，为最终用户授权 客户端访问自己的资源，通过直接与认证 服务器和客户端配置与使用令牌 身份验证方法。第二部分定义了一个制作方法 验证HTTP [RFC2616]的要求，使用两套全权证书， 确定客户端请求，第二个 标识上资源的所有者，其代表的请求被 作出。 与任何传输协议，比[RFC2616中的OAuth的其他用途 不确定的。 1.1。术语 客户端 HTTP客户端（每[RFC2616]）能够使OAuth的 身份验证的请求（第3）。 服务器 HTTP服务器（每[RFC2616]）能够接受OAuth的 身份验证的请求（第3）。 受保护的资源 可以从一个访问受限资源 服务器使用OAuth的身份验证的请求（第3）。 资源的所有者 一个实体能够访问和控制保护 资源使用证书进行身份验证的服务器。 凭据 凭据是对一个唯一的标识符匹配 共享的秘密。OAuth的定义了三个班的凭据： 客户端，暂时的，和令牌，用于识别和认证 客户端提出请求时，授权请求， 批的访问。 锤Lahav信息[第4页] RFC 5849 OAuth的1.0 2010年4月 令牌 发出的服务器和客户端所使用的唯一标识符 联想到与资源拥有者进行身份验证的请求 其授权要求，或已获得 客户端。令牌有一个共享的秘密是使用匹配 客户端的记号，以确定其所有权，其 有权代表资源的所有者。 原有的社会规范使用略有不同 术语本规范地图如下（原 左侧提供的社会计算）： 消费者：客户端 服务提供商：服务器 用户名：资源的所有者 消费者密钥和秘密：客户端凭据 请求令牌和秘密：临时凭据 访问令牌和秘密：令牌的凭据 1.2。示例 简（资源的所有者）最近上传一些私人度假 照片（受保护的资源），以她的照片共享网站 “photos.example.net”（服务器）。她想使用 “printer.example.com”网站（客户端）来打印这些照片之一。 通常情况下，简成“photos.example.net”标志使用她的用户名 和密码。 但是，简不希望分享她的用户名和密码 “printer.example.com”网站，该网站需要访问照片的 为了打印出来。为了它的用户提供更好的 服务，“printer.example.com”已签署了一套 “photos.example.net”客户端凭据的时间提前： 客户端标识符 dpf43f3p2l4k3l03 客户端的共享秘密： kd94hf93k423kf44 'printer.example.com“网站也配置及其应用 使用协议“photos.example.net的API中列出的端点 文档，它使用“HMAC - SHA1”签名的方法： 锤Lahav信息[第5页] RFC 5849 OAuth的1.0 2010年4月 临时凭证请求 https://photos.example.net/initiate 资源所有者的授权URI： https://photos.example.net/authorize 令牌请求的URI： https://photos.example.net/token 之前，“printer.example.com'可以要求简授予访问 照片，它必须先建立一个临时凭据 'photos.example.net“，以确定该代表团的要求。要做到这一点， 客户端发送以下的HTTPS [RFC2818]请求到服务器： POST /启动HTTP/1.1 主机：photos.example.net 授权：OAuth的境界=“照片”， oauth_consumer_key =“dpf43f3p2l4k3l03” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131200”， oauth_nonce =“wIjqoS” oauth_callback =“HTTP％3A％2F％2Fprinter.example.com％2Fready” oauth_signature =“74KNZJeDHnMBp0EMJ9ZHt％2FXKycU％3D” 服务器验证请求，并答复了一套临时 在HTTP响应体的凭据（换行符 显示仅供参考）： HTTP/1.1 200 OK 内容类型：应用程序/ x - www的形式进行了urlencoded oauth_token = hh5s93j4hdidpola＆oauth_token_secret = hdhd0244k9j7ao03＆ oauth_callback_confirmed = TRUE 客户端重定向简的用户代理服务器的资源的所有者 获得授权的端点简氏访问她的批准 私人照片： https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola 服务器请求简签署在使用自己的用户名和密码 如果成功的话，问她批准授予“printer.example.com” 访问她的私人照片。简批准的要求和她的 用户代理重定向到客户端所提供的回调的URI 在先前的请求（仅用于显示目的换行符）： http://printer.example.com/ready？ oauth_token = hh5s93j4hdidpola oauth_verifier = hfdp7dh39dks9884 锤Lahav信息[6] RFC 5849 OAuth的1.0 2010年4月 回调要求通知客户端，简完成 授权过程。然后，客户端请求的令牌 使用在一个安全的运输的临时凭据（凭据 层安全（TLS）通道）： POST /令牌HTTP/1.1 主机：photos.example.net 授权：OAuth的境界=“照片”， oauth_consumer_key =“dpf43f3p2l4k3l03” oauth_token =“hh5s93j4hdidpola” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131201”， oauth_nonce =“walatlh” oauth_verifier =“hfdp7dh39dks9884”， oauth_signature 2FIHF7IU％=“gKgrFCywp7rO0OXSjdot％3D” 服务器验证的令牌的请求和答复 在HTTP响应体的全权证书： HTTP/1.1 200 OK 内容类型：应用程序/ x - www的形式进行了urlencoded oauth_token = nnch734d00sl2jdk oauth_token_secret = pfkkdhi9sl3r4s00 客户端的令牌凭据，现在准备请求 私人照片： GET /照片文件= vacation.jpg大小=原HTTP/1.1 主机：photos.example.net 授权：OAuth的境界=“照片”， oauth_consumer_key =“dpf43f3p2l4k3l03” oauth_token =“nnch734d00sl2jdk” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131202”， oauth_nonce =“chapoH” oauth_signature =“MdpQcU8iPSUjWoN％2FUDMsK2sui9I％3D” “photos.example.net”服务器验证请求和响应 要求的相片。“printer.example.com”能够继续 使用同一组的令牌访问珍的私人照片 简的授权期限的凭据，或直至简 撤销访问。 1.3。符号约定 关键词“必须”，“MUST NOT”，“”，“应该”，“不得”， “应该”，“不应该”，“建议”，“可能”，和“可选的”在此 文件[RFC2119]中描述的被解释为。 锤Lahav信息[7] RFC 5849 OAuth的1.0 2010年4月 2。基于重定向的授权 OAuth的代表授予的授权使用令牌 客户端资源的所有者。通常情况下，令牌认证 服务器资源所有者的要求发出后， 验证资源所有者的身份（通常使用 用户名和密码）。 有许多方法，其中一台服务器可以方便的配置 令牌的凭据。本节定义了一个这样的方式，使用HTTP 重定向和资源所有者的用户代理。这种重定向 - 基于授权的方法包括三个步骤： 1。客户端从服务器获得一个临时凭据 （在标识符和共享秘密的形式）。临时 凭据用于识别访问请求，整个 授权的过程。 2。资源所有者授权服务器，给予客户的 访问请求（临时的凭据确定）。 3。客户端使用暂时的凭据，要求一套 从服务器的令牌凭证，这将使它能够访问 资源所有者的受保护资源。 该服务器后，必须撤销所使用的临时凭据 一旦获得令牌的凭据。这是建议 临时凭据有一个有限的生命周期。服务器应该启用 资源所有者后，他们已撤销令牌凭据 向客户发出。 为了为客户端执行这些步骤，服务器需要 做广告以下三个端点的URI： 临时凭证请求 用于获取客户端的临时端点 2.1节中所述的凭据。 资源所有者的授权 端点资源的所有者将被重定向到授予 授权2.2节中所述。 令牌的请求 客户端所使用的端点请求令牌 使用设置临时凭据的凭据描述 在第2.3节。 锤Lahav信息[8] RFC 5849 OAuth的1.0 2010年4月 三个服务器发布的URI可能包括一个查询组件 所界定的[RFC3986]，第3，但如果存在的话，查询必须 不包含任何参数“oauth_”前缀开始， 避免冲突的协议参数的URI时 使用。 在该服务器的通告和文件，它的三个方法 端点超出本规范的范围。客户应 避免使有关的纪念品和其他大小的假设服务器 生成的值，这是左本规范未定义的。在 此外，协议参数可能包括需要的值 编码传输时。不应该使客户端和服务器 假设他们的价值可能范围。 2.1。临时全权证书 客户端获得一个临时凭据从服务器通过设置 经过身份验证（第3）HTTP“POST”的要求 临时凭证请求端点（除非服务器通告 另一个客户端使用的HTTP请求方法）。客户端 通过添加以下所需的参数，构造一个请求URI 请求（除了其他的协议参数，使用 相同的参数的传输方法）： oauth_callback：回服务器将绝对URI 当资源的所有者重定向资源的所有者 完成授权的步骤（2.2节）。如果 客户端无法接收回调或 已通过其他手段建立回调的URI， 参数值必须设置为“OOB”（区分 敏感），以表明一个out - of -波段 配置。 服务器可以指定额外的参数。 提出请求时，客户端进行身份验证仅使用 客户端凭据。客户端可以省略空“oauth_token” 协议从请求参数，必须使用空字符串 令牌的秘密值。 由于纯文本传输的请求结果 在HTTP响应中的凭据，服务器必须要求使用 如TLS或安全套接字层（SSL）传输层机制 （或具有同等保护的安全通道）。 锤Lahav信息[9] RFC 5849 OAuth的1.0 2010年4月 例如，客户端以下的HTTPS请求： POST / request_temp_credentials HTTP/1.1 主机：server.example.com 授权：OAuth的境界=“范例”， oauth_consumer_key =“jd83jd92dhsh93js” oauth_signature_method =“明文”， oauth_callback =“HTTP％3A％2F％2Fclient.example.net％2Fcb 3Fx％3D1％”， oauth_signature =“ja893SD9 26％” 服务器必须验证（3.2节）的要求，如果有效， 回应一个临时凭据与客户端（在 标识符和共享秘密的形式）。临时 凭据是包含在HTTP响应体中使用 “应用程序/ X - WWW形式进行了urlencoded”的内容类型定义 [W3C.REC HTML40 - 19980424] 200状态码（确定）。 响应包含下列必需参数： oauth_token 临时凭据标识符。 oauth_token_secret 共享秘密的临时凭据。 oauth_callback_confirmed 必须存在，并且设置为“true”。该参数是用来 区别于以前的版本的协议。 请注意，即使参数名称包括“令牌”一词， 这些凭据没有令牌的凭据，但在未来使用 两个步骤，以类似的方式令牌凭据。 例如（仅用于显示目的换行符）： HTTP/1.1 200 OK 内容类型：应用程序/ x - www的形式进行了urlencoded oauth_token = hdk48Djdsa oauth_token_secret = xyz4992k83j47x0b oauth_callback_confirmed = TRUE 2.2。资源所有者的授权 在客户端请求从令牌凭据 服务器时，必须到服务器的用户发送授权请求。 加入以下所需客户端构造请求URI 资源所有者的授权端点URI查询参数： 锤Lahav信息[10] RFC 5849 OAuth的1.0 2010年4月 oauth_token 在2.1节中获得临时凭据标识符 “oauth_token”参数。服务器可以宣布这一点 作为可选的参数，在这种情况下，他们必须提供一种方式 资源所有者表明通过其他标识符 手段。 服务器可以指定额外的参数。 使用客户端指示资源所有者的构造的URI HTTP重定向响应，或可通过其他手段 资源所有者的用户代理。要求必须使用的HTTP“GET” 方法。 例如，客户端资源的所有者的用户代理重定向 以下的HTTPS请求： GET / authorize_access？oauth_token = HTTP/1.1的hdk48Djdsa 主机：server.example.com 在该服务器的方式处理授权请求， 包括是否使用TLS / SSL的安全通道如超出 本规范的范围。然而，服务器必须首先 验证资源的所有者的身份。 当要求的资源所有者授权的访问请求， 服务器应提供有关的资源所有者信息 客户端请求访问的基础上，临时协会 凭据与客户端的身份。当显示任何此类 信息，服务器应说明信息已 验证。 接收从资源所有者的授权决定后， 服务器重定向资源的所有者，如果一个回调URI 在“oauth_callback”参数或以其他方式提供。 为了确保授予访问资源的所有者是相同的 资源的所有者返回到客户端来完成的过程， 服务器必须生成一个验证码：unguessable价值 通过资源的所有者，并传递给客户端要求完成 的过程。服务器结构中加入请求URI 回调URI查询组件所需的参数： oauth_token 从客户端收到的临时凭据标识符。 锤Lahav信息[11] RFC 5849 OAuth的1.0 2010年4月 oauth_verifier 验证码。 如果回调URI已经包含了查询组件，服务器 OAuth的参数必须附加到现有的查询结束。 例如，服务器资源所有者的用户代理重定向 下面的HTTP请求： GET / CB？X = 1＆oauth_token = hdk48Djdsa＆oauth_verifier = 473f82d3 HTTP/1.1 主机：client.example.net 如果客户端没有提供一个回调URI，服务器应该 显示的验证码的值，并指示资源 所有者手动通知客户端，完成授权。 如果服务器知道客户端运行在一个有限的设备，它 应确保，验证值是适合于手工录入。 2.3。令牌的全权证书 客户端获得一个从服务器的令牌凭据通过设置 经过身份验证（第3）HTTP“POST”的请求令牌 请求端点（除非服务器通告另一个HTTP请求 客户端使用的方法）。客户端构造一个请求URI 通过添加下列所需的参数的要求（在 除了其他的协议参数，使用相同的参数 传输方法）： oauth_verifier 在前面的，从服务器收到验证码 第一步。 提出请求时，客户端使用客户端进行身份验证 凭据以及临时凭据。临时 在令牌凭据的替代品被用作凭据 身份验证的请求和传送使用“oauth_token” 参数。 由于纯文本传输的请求结果 在HTTP响应中的凭据，服务器必须要求使用 如TLS或SSL（传输层的机制或一个安全通道 具有同等的保护）。 锤Lahav信息[12] RFC 5849 OAuth的1.0 2010年4月 例如，客户端以下的HTTPS请求： POST / request_token HTTP/1.1 主机：server.example.com 授权：OAuth的境界=“范例”， oauth_consumer_key =“jd83jd92dhsh93js” oauth_token =“hdk48Djdsa” oauth_signature_method =“明文”， oauth_verifier =“473f82d3”， oauth_signature =“ja893SD9％26xyz4992k83j47x0b” 服务器必须验证（3.2节）的请求的有效性， 确保资源的所有者已授权供应 令牌凭据客户端，并确保临时 没有过期的凭据或使用过。服务器必须 也验证从客户端收到的验证码。如果 请求是有效的，并授权令牌的凭据 在使用HTTP响应体 “应用程序/ X - WWW形式进行了urlencoded”的内容类型定义 [W3C.REC HTML40 - 19980424] 200状态码（确定）。 响应包含下列必需参数： oauth_token 令牌的标识符。 oauth_token_secret 令牌的共享秘密。 例如： HTTP/1.1 200 OK 内容类型：应用程序/ x - www的形式进行了urlencoded oauth_token = j49ddk933skd9dks oauth_token_secret = ll399dj47dskfjdk 服务器必须保留的范围，期限和其他属性 批准资源的所有者，并强制执行这些限制 接收客户端请求发出的令牌凭据。 一旦客户端接收和存储令牌的凭据，它可以 代表资源的所有者进行访问受保护资源 通过使用客户端的身份验证的请求（第3） 收到令牌的凭据凭据一起。 锤Lahav信息[13] RFC 5849 OAuth的1.0 2010年4月 3。经过身份验证的请求 [RFC2617]使客户定义的HTTP身份验证方法 使身份验证的HTTP请求。使用这些方法的客户端 获得访问受保护资源，利用他们的凭据 （通常情况下，对用户名和密码），它允许服务器 验证其真实性。使用这些方法代表团 要求客户端资源的所有者承担的角色。 OAuth的方法提供了设计，包括两套全权证书 每个请求，识别客户端，而另一个 确定资源的所有者。在用户端可以验证 对资源的所有者代表的请求，它必须获得一个令牌 由资源的所有者授权。第2节提供了这样一个方法 通过该客户端即可获得授权令牌 资源的所有者。 客户端凭据采取的形式和一个唯一的标识符 相关的共享秘密或RSA密钥对。在作出 身份验证的请求，客户端建立一组凭据 与服务器。配置这些过程和要求 本规范的范围之外。实施者敦促 考虑使用客户端凭据的安全后果， 其中有些是在第4.6节。 身份验证的请求需要的先验知识 服务器的配置。OAuth的包括多种方法 传输协议参数的要求（3.5节），以及 为多个客户端的方法来证明其合法所有权 使用的凭据（3.4节）。，其中客户端的方式 发现所需的配置是此范围以外的 规范。 3.1。提出要求 经过身份验证的请求包括几项协议参数。每个 参数的名字开始与“oauth_”的前缀，参数 名称和值是大小写敏感的。客户端发出身份验证的 请求通过计算一个协议参数设置的值 并将它们添加到HTTP请求如下： 1。客户端分配这些必要的（除非 协议另有规定外）的参数： 锤Lahav信息[14] RFC 5849 OAuth的1.0 2010年4月 oauth_consumer_key 客户端凭据的标识符部分（相当于 用户名）。参数的名称反映了过时的的术语 （消费密钥），用于在以前版本的规范， 并一直保留，以保持向后兼容性。 oauth_token 使用标记值与资源相关联的要求 所有者。如果请求是不相关的资源所有者 （可用任何标记），客户可以省略参数。 oauth_signature_method 客户端所使用的签名方式签署的名称 要求，在3.4节中定义。 oauth_timestamp 在3.3节中定义的时间戳值。该参数 使用“明文”签名的方法时，可以省略。 oauth_nonce nonce值在3.3节中定义的。该参数可能 使用“明文”签名的方法时，可以省略。 oauth_version 可选的。如果存在，必须被设置为“1.0”。提供的 在这个定义的认证过程中的版本 规范。 2。协议参数被添加到使用一个请求 在3.5节中列出的传输方法。每个参数都必须 不会出现超过每请求一次。 3。客户端计算和分配的价值 “oauth_signature”参数描述在3.4节，并增加了 请求参数，在使用相同的方法 前面的步骤。 4。客户端发送到服务器的身份验证的HTTP请求。 例如，下面的HTTP请求进行身份验证（ “C2＆A3 = 2 + Q”字符串，在下面的例子是用来说明 的形式编码的实体主体的影响）： B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？ 主持人：example.com 内容类型：应用程序/ x - www的形式进行了urlencoded C2＆A3 = 2 + Q 锤Lahav信息[15] RFC 5849 OAuth的1.0 2010年4月 客户端分配值以下协议参数使用 它的客户端凭据，令牌认证，当前时间戳， 唯一产生的随机数，并表示，它将使用 “HMAC - SHA1”签名的方法： oauth_consumer_key：9djdj82h48djs9d2 oauth_token：kkk9d7dh3k39sjv7 oauth_signature_method：HMAC - SHA1算法 oauth_timestamp：137131201 oauth_nonce：7d8f3e4a 客户端将使用请求的协议参数 OAuth的HTTP的“授权”标头字段： 授权：OAuth的境界=“范例”， oauth_consumer_key =“9djdj82h48djs9d2” oauth_token =“kkk9d7dh3k39sjv7” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131201”， oauth_nonce =“7d8f3e4a” 然后，计算出“oauth_signature”参数值 （使用客户端的秘密“j49sk3j29djd”令牌的秘密“dh893hdasih9”）， 将它添加到该请求，并发送HTTP请求到服务器： B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？ 主持人：example.com 内容类型：应用程序/ x - www的形式进行了urlencoded 授权：OAuth的境界=“范例”， oauth_consumer_key =“9djdj82h48djs9d2” oauth_token =“kkk9d7dh3k39sjv7” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131201”， oauth_nonce =“7d8f3e4a” oauth_signature =“bYT5CMsGcbgUdFHObYMEfcx6bsw％3D” C2＆A3 = 2 + Q 3.2。验证要求 接收经过身份验证的请求的服务器必须验证： Ø重新计算请求签名独立所述 从客户端收到第3.4节和它的价值进行比较 通过“oauth_signature”参数。 锤Lahav信息[16] RFC 5849 OAuth的1.0 2010年4月 如果使用“的HMAC - SHA1”或“RSA - SHA1”签名方法，确保 结合的nonce /时间戳/令牌（如果存在） 从客户端收到尚未使用过的，在以前的 请求（服务器可能会拒绝陈旧的时间戳请求 在3.3节中所述）。 o如果一个记号目前，核查的范围和状态 客户端授权令牌（服务器可以代表 选择它是客户端的令牌的使用限制 印发）。 o如果“oauth_version”参数，确保其价值 “1.0”。 如果请求验证失败，服务器应与 适当的HTTP响应状态代码。该服务器可以包括 为何请求被拒绝响应的进一步细节 身体。 服务器应当返回一个400（错误请求）状态代码时 接受与不支持的参数，不支持请求 签名的方法，缺少的参数，或复制协议 参数。服务器应当返回一个401（未授权）状态 代码时，接收请求的，无效的客户端凭据 无效或过期的令牌，签名无效，或无效或使用 NONCE。 3.3。nonce和时间戳 时间戳值必须是一个正整数。除非另有 由该服务器的文档指定，表示时间戳 在1970年1月1日起，日00:00:00 GMT以来的秒数。 一个nonce是一个随机字符串，唯一由客户端生成，让 服务器来验证一个请求前，从未 有助于防止重放攻击，非安全请求时 通道。nonce值必须是唯一的与所有要求 相同的时间戳，客户端凭据，令牌组合。 为了避免需要保留一个无限数量的nonce值 以后的检查中，服务器可以选择限制一段时间后 这与旧的时间戳的请求被拒绝。请注意，这 限制意味着客户端之间的同步水平 与服务器的时钟。应用这种限制的服务器可提供 一个客户端与服务器的时钟同步方式;另外， 这两个系统可以同步一个值得信赖的时间服务。详情 时钟同步的战略已经超出此范围 规范。 锤Lahav信息[17] RFC 5849 OAuth的1.0 2010年4月 3.4。签名 OAuth的身份验证的请求可以有两套全权证书：那些 通过“oauth_consumer_key”参数，并在通过 “oauth_token”参数。在为服务器，以验证 真实性的要求，并防止未经授权的访问， 客户的需求，以证明它是的合法所有者 凭据。这是通过使用共享秘密的（或RSA 键），每个组凭据的一部分。 OAuth的为客户提供了三种方法来证明其合法 所有权的凭据：“HMAC - SHA1算法”，“RSA - SHA1”，并 “明文”。这些方法一般简称为签名 方法，即使“明文”不涉及一个签名。在 此外，“RSA - SHA1”利用，而不是共享的RSA密钥 秘密相关的客户端凭据。 OAuth的不规定特定签名的方法，因为每个 实施可以有自己独特的要求。服务器是 免费实施和记录自己的自定义方法。 推荐任何特定的方法是超出了这个范围 规范。实施者应审查安全 注意事项“部分（第4），然后决定哪种方法 支持。 其中签名的方法是通过使用客户端声明 “oauth_signature_method”参数。然后生成一个签名 （或同等价值的字符串）和包括在 “oauth_signature”参数。服务器验证签名 指定为每个方法。 签名过程中不会改变的请求或参数， 除了“oauth_signature”参数。 3.4.1。签名基本字符串 签名基字符串是一致的，重复性的串联 几个成一个字符串的HTTP请求元素。“ 字符串作为输入到“HMAC - SHA1算法”和“RSA - SHA1” 签名方法。 签名基字符串包含了以下组件 HTTP请求： Ø HTTP请求方法（例如，“GET”，“POST”等）。 Ø的HTTP“主机”请求头字段声明的权力。 锤Lahav信息[18] RFC 5849 OAuth的1.0 2010年4月 Ø请求资源的URI路径和查询组件。 Ø不包括“oauth_signature”协议参数。 o参数包括在请求实体主体，如果他们遵守 在3.4.1.3节中定义的严格限制。 签名的基本字符串，不包括整个HTTP请求。 最值得注意的是，它不包括在大多数请求的实体主体， 也不包括最HTTP实体头。重要的是要 请注意，服务器无法验证的排斥的真实性 不要求使用额外的保护，如SSL /组件 TLS或其他方法。 3.4.1.1。字符串建设 签名基字符串构造串连在一起， 为了下面的HTTP请求的内容： 1。以大写的HTTP请求方法。例如：“团长”， “GET”，“POST”等，如果要求使用一个自定义的HTTP方法， 必须进行编码（第3.6节）。 2。一个“＆”字符（ASCII代码38）。 3。从第3.4.1.2基本字符串URI，被编码后 （3.6节）。 4。一个“＆”字符（ASCII代码38）。 5。第3.4.1.3.2请求参数正常化后， 被编码（第3.6节）。 例如，HTTP请求： B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？ 主持人：example.com 内容类型：应用程序/ x - www的形式进行了urlencoded 授权：OAuth的境界=“范例”， oauth_consumer_key =“9djdj82h48djs9d2” oauth_token =“kkk9d7dh3k39sjv7” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131201”， oauth_nonce =“7d8f3e4a” oauth_signature =“bYT5CMsGcbgUdFHObYMEfcx6bsw％3D” C2＆A3 = 2 + Q 锤Lahav信息[19] RFC 5849 OAuth的1.0 2010年4月 代表由以下签名的基本字符串（换行符 仅供显示）： 邮政的http％3A％2F％2Fexample.com％2Frequest A2％3DR％2520b％26a3％3D2％2520q ％26a3％3DA％26b5％3D％253D％25253D％26C％2540％26c2％3D％3D％26oauth_consumer_ 关键26oauth_nonce％3D9djdj82h48djs9d2％％3D7d8f3e4a％26oauth_signature_m ethod％3DHMAC - SHA1％26oauth_timestamp％3D137131201％26oauth_token％3Dkkk 9d7dh3k39sjv7 3.4.1.2。基本字符串URI 该计划的权威性，请求资源的路径的URI [RFC3986] 包括兴建一个“HTTP”或“https”的URI代表 请求资源（不包括查询或片段）如下： 1。该计划和主机必须是小写。 2。主机和端口值必须匹配的HTTP内容 要求“主机”头字段。 3。如果它不是默认端口为端口必须包括 如果它是默认的计划，必须排除。具体来说， 端口HTTP请求时，必须排除[RFC2616] 到80端口或HTTPS请求时，[RFC2818] 443端口。 必须包括所有其他非默认端口号。 例如，HTTP请求： GET / R％20V / X吗？ID = 123 HTTP/1.1 主持人：EXAMPLE.COM：80 为代表的基本字符串的URI：“http://example.com/r％20V / X”。 在另一个例子中，HTTPS请求： Q = 1 HTTP/1.1的的GET /？ 主机：www.example.net:8080 为代表的基本字符串URI： “https://www.example.net:8080/”。 3.4.1.3。请求参数 为了保证一个一致的和可重复性的代表性 请求参数，参数的收集和解码 其原始的解码形式。然后，他们排序，并在编码 特定的方式，往往是从原来的不同 编码方案，并串联成一个字符串。 锤Lahav信息[20] RFC 5849 OAuth的1.0 2010年4月 3.4.1.3.1。参数源 从下列来源的参数都收集到一个单一的 列表中的名称/值对： Ø所定义的HTTP请求的URI的查询组件 [RFC3986]，第3.4节。查询组件解析成一个列表 当作一个名称/值对 “应用程序/ X - WWW形式进行了urlencoded”字符串，分隔名称 和值和解码定义 [W3C.REC HTML40 - 19980424]，第17.13.4。 Ø了OAuth HTTP“授权”标头栏位（第3.5.1节） 目前。标题的内容解析为名称/值列表 对排除的“境界”的参数，如果目前。该参数 3.5.1节中定义的值解码。 Ø HTTP请求实体主体，但只有当所有下列 条件是： *实体主体是单一的一部分。 *实体主体遵循的编码要求 “应用程序/ X - WWW形式进行了urlencoded”所界定的内容类型 [W3C.REC HTML40 - 19980424]。 * HTTP请求实体标题包括“内容类型” 头字段设置为“应用程序/ X - WWW形式进行了urlencoded”。 实体主体是解析成一个解码的名称/值对列表 [W3C.REC HTML40 - 19980424]，第17.13.4。 “oauth_signature”参数必须排除的签名 基本字符串（如果存在）。在没有明确包含的参数 销售的要求，必须排除从签名的基本字符串（例如，。 “oauth_version”参数省略时）。 锤Lahav信息[21] RFC 5849 OAuth的1.0 2010年4月 例如，HTTP请求： B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？ 主持人：example.com 内容类型：应用程序/ x - www的形式进行了urlencoded 授权：OAuth的境界=“范例”， oauth_consumer_key =“9djdj82h48djs9d2” oauth_token =“kkk9d7dh3k39sjv7” oauth_signature_method =“HMAC - SHA1算法” oauth_timestamp =“137131201”， oauth_nonce =“7d8f3e4a” oauth_signature =“djosJKDKJSD8743243％2Fjdk33klY％3D” C2＆A3 = 2 + Q 包含以下（全解码）中使用的参数 签名基地蜇： +------------------------+------------------+ |名称|价值| +------------------------+------------------+ | B5 | =％3D | | A3 | Å | | C @ | | | A2 | RB | | oauth_consumer_key | 9djdj82h48djs9d2 | | oauth_token | kkk9d7dh3k39sjv7 | | oauth_signature_method | HMAC - SHA1算法| | oauth_timestamp | 137131201 | | oauth_nonce | 7d8f3e4a | | C2 | | | A3 | 2 Q | +------------------------+------------------+ 请注意，“B5”的价值是“=％3D”，而不是"==". 这两个“C”和 “C2”空值。虽然在这个指定的编码规则 规范签名基地建设的目的 字符串排除使用一个“+”字符（ASCII代码43） 代表编码的空格字符（ASCII代码32），这种做法 在“应用程序/ x - www的形式，进行了urlencoded”编码值中被广泛使用， ，必须正确解码，由“A3”一个证明 参数实例（“A3”的参数是用来在这两次 请求）。 锤Lahav信息[22] RFC 5849 OAuth的1.0 2010年4月 3.4.1.3.2。参数正常化 第3.4.1.3收集到的参数归成 单个字符串如下： 1。首先，名称和每个参数的值编码 （3.6节）。 2。参数按名称进行排序，采用递增的字节值 订购。如果两个或多个参数有着相同的名字，他们 其价值排序。 3。每个参数的名称被连接到其相应的 价值作为分隔符使用一个“=”字符（ASCII代码61），即使 如果值是空的的。 4。排序的名称/值对串联在一起成 通过使用一个“＆”字符（ASCII代码38）的单个字符串 分隔符。 例如，从上一节的参数列表 被归为如下： 编码： +------------------------+------------------+ |名称|价值| +------------------------+------------------+ | B5 |％3D％253D | | A3 | Å | | C％40 | | | A2 | R％20B | | oauth_consumer_key | 9djdj82h48djs9d2 | | oauth_token | kkk9d7dh3k39sjv7 | | oauth_signature_method | HMAC - SHA1算法| | oauth_timestamp | 137131201 | | oauth_nonce | 7d8f3e4a | | C2 | | | A3 | 2％20Q | +------------------------+------------------+ 锤Lahav信息[23] RFC 5849 OAuth的1.0 2010年4月 排序方式： +------------------------+------------------+ |名称|价值| +------------------------+------------------+ | A2 | R％20B | | A3 | 2％20Q | | A3 | Å | | B5 |％3D％253D | | C％40 | | | C2 | | | oauth_consumer_key | 9djdj82h48djs9d2 | | oauth_nonce | 7d8f3e4a | | oauth_signature_method | HMAC - SHA1算法| | oauth_timestamp | 137131201 | | oauth_token | kkk9d7dh3k39sjv7 | +------------------------+------------------+ 串联双： +-------------------------------------+ |名称=值| +-------------------------------------+ | A2 = R％20B | | A3 = 2％20Q | | A3 = Å | | B5 =％3D％253D | | C％40 = | | C2 = | | oauth_consumer_key = 9djdj82h48djs9d2 | | oauth_nonce = 7d8f3e4a | | oauth_signature_method = HMAC - SHA1 | | oauth_timestamp = 137131201 | | oauth_token = kkk9d7dh3k39sjv7 | +-------------------------------------+ 并连接成一个字符串（换行符 显示仅供参考）： A2 = R％20B＆A3 = 2％20Q＆A3 = A＆B5 =％3D％253D＆C％40 =＆C2 =＆oauth_consumer_key = 9dj dj82h48djs9d2＆oauth_nonce = 7d8f3e4a oauth_signature_method = HMAC - SHA1算法 ＆oauth_timestamp = 137131201＆oauth_token = kkk9d7dh3k39sjv7 锤Lahav信息[24] RFC 5849 OAuth的1.0 2010年4月 3.4.2。HMAC - SHA1算法 “HMAC - SHA1”签名的方法，使用HMAC - SHA1算法的签名 算法，在[RFC2104]中定义： 消化= HMAC - SHA1算法（键，文本） HMAC - SHA1算法的函数变量用于下列方式： 文字签名基地字符串的值设置为从 第3.4.1.1。 关键是设置的串联值： 1。客户端的共享秘密，被编码后 （3.6节）。 2。“＆”字符（ASCII代码38），它必须被列入 甚至秘密时要么是空的。 3。令牌的共享秘密，被编码后 （3.6节）。 消化是用来设置“oauth_signature”协议的价值 参数后，结果字节串是base64编码 每[RFC2045]，第6.8节。 3.4.3。RSA - SHA1 “RSA - SHA1”签名方法使用RSASSA - PKCS1 - v1_5签名 算法定义在[RFC3447]，第8.2节（也称为 PKCS＃1），使用SHA - 1散列函数，EMSA - PKCS1 - v1_5。要 使用这种方法，客户端必须建立客户端凭据 与服务器的方式，包括RSA公钥（ 本规范的范围之外）。 使用客户端的RSA私钥签名基字符串签署 每[RFC3447]键，第8.2.1节： S = RSASSA - PKCS1 - V1_5 - SIGN（K，M） 其中： K是设置客户端的RSA私钥， M是设置签名基地字符串值 第3.4.1.1 锤Lahav信息[25] RFC 5849 OAuth的1.0 2010年4月 S是用来设置值的结果签名 “oauth_signature”协议参数，结果八位字节后 字符串％[RFC2045]的6.8节是base64编码。 服务器验证％[RFC3447]第8.2.2节的签名： RSASSA - PKCS1 - V1_5验证（（N，E），M，S） 其中： （N，E）设置为客户端的RSA公钥， M是设置签名基地字符串值 第3.4.1.1 S设置为字节串“oauth_signature”价值 从客户机接收协议参数。 3.4.4。PLAINTEXT “明文”的方法，不采用的签名算法。它 必须使用传输层机制，如TLS或SSL（或 在一个相当于保护的安全通道发送）。它不 利用签名的基本字符串或“oauth_timestamp”和 “oauth_nonce”参数。 “oauth_signature”协议参数设置的串联 价值： 1。客户端的共享秘密被编码后，（第3.6节）。 2。“＆”字符（ASCII代码38），它必须被列入甚至 无论是秘密的时候是空的。 3。令牌的共享秘密，被编码后的（3.6节）。 3.5。参数传递 OAuth的身份验证的请求时，协议参数 以及任何其他参数，应使用“oauth_”前缀 包括在使用之一，下面只有一个请求 地点，偏好递减的顺序列出： 1。HTTP的“授权”标头字段中所述 第3.5.1节。 2。HTTP请求实体主体的第3.5.2节中所述。 锤Lahav信息[26] RFC 5849 OAuth的1.0 2010年4月 3。在3.5.3节中描述的HTTP请求的URI查询。 除了这三种方法，在未来的扩展，可以定义 其他方法，包括请求的协议参数。 3.5.1。Authorization头 可以传输协议参数使用HTTP的“授权” 头字段[RFC2617]中定义的设置与验证计划名称 “OAuth的”（不区分大小写）。 例如： 授权：OAuth的境界=“范例”， oauth_consumer_key =“0685bd9184jfhq22” oauth_token =“ad180jjd733klru7” oauth_signature_method =“HMAC - SHA1算法” oauth_signature =“wOJIO9A2W5mFwDgiDvZbTSMK％2FPY％3D” oauth_timestamp =“137131200”， oauth_nonce =“4572616e48616d6d65724c61686176” oauth_version =“1.0” 协议参数应包括在“授权”头 字段如下： 1。每个参数编码的编码参数名称和值 （3.6节）。 2。每个参数的名称后面紧跟着一个“=”字符 （ASCII代码61），“”字符（ASCII代码34），参数 值（可能为空），和另一个“”“字符（ASCII代码34）。 3。参数分离“，”字符（ASCII代码44）和 可选的线性空白每[RFC2617]。 4。可选的“境界”的参数可以补充和解释每 [RFC2617] 1.2节。 服务器可能表明他们为“OAuth的”验证计划的支持 返回的HTTP“的WWW - Authenticate”响应头字段后， 受保护的资源的客户端请求。由于每[RFC2617]，这样的 响应可能包括额外的HTTP“的WWW - Authenticate”头 专业领域： 例如： WWW验证：OAuth的境界=“http://server.example.com/” 锤Lahav信息[27] RFC 5849 OAuth的1.0 2010年4月 realm参数定义了一个保护领域，每[RFC2617]，第 1.2。 3.5.2。表单编码的身体 协议参数可以传送HTTP请求的实体 的身体，但只有如果满足下列要求的条件： Ø实体主体是单一的一部分。 Ø实体主体遵循的编码要求 “应用程序/ X - WWW形式进行了urlencoded”所界定的内容类型 [W3C.REC HTML40 - 19980424]。 Ø HTTP请求实体标题包括“内容类型”的头 字段设置为“应用程序/ X - WWW形式进行了urlencoded”。 例如（仅用于显示目的换行符）： oauth_consumer_key = 0685bd9184jfhq22 oauth_token = ad180jjd733klr U7 oauth_signature_method = HMAC - SHA1算法oauth_signature = wOJIO9A2W5 mFwDgiDvZbTSMK％2FPY％3D＆oauth_timestamp = 137131200＆oauth_nonce = 4 572616e48616d6d65724c61686176＆oauth_version = 1.0 该实体的身体可能包括其他请求特定的参数， 这种情况下，应附加协议参数后 请求特定的参数，适当的“＆”字符隔开 （ASCII码38）。 3.5.3。请求URI查询 可以被添加到HTTP传输协议参数 请求URI [RFC3986]，第3节中定义一个查询参数。 例如（仅用于显示目的换行符）： /例如/路径？oauth_consumer_key = 0685bd9184jfhq22＆ oauth_token = ad180jjd733klru7 oauth_signature_method = HM AC - SHA1 oauth_signature = wOJIO9A2W5mFwDgiDvZbTSMK％2FPY％ 3D＆oauth_timestamp = 137131200＆oauth_nonce = 4572616e48616 d6d65724c61686176 oauth_version = 1.0 HTTP/1.1 请求URI可能包括其他特定于请求的查询参数， 在这种情况下，应附加以下协议参数 请求特定的参数，由一个适当分离“及” 字符（ASCII代码38）。 锤Lahav信息[28] RFC 5849 OAuth的1.0 2010年4月 3.6。百分比编码 现有的％编码方法不保证一以贯之 签名的基本字符串的建设。以下％ 没有定义编码方法，以取代现有的编码 [RFC3986]中定义的方法和[W3C.REC HTML40 - 19980424]。这是 只在签名基地字符串的建设和使用 “授权”标头字段。 本规范定义了编码％以下方法 字符串： 1。文本值将被编码为UTF - 8％[RFC3629]八位字节，如果 他们是不是已经。这不包括的二进制值 不适合人类食用。 2。使用[RFC3986]％的编码的值，然后逃脱 （百分之二十）的机制如下： *在毫无保留的字符的字符集定义 [RFC3986]，第2.3（字母，数字，“ - ”“，”_“，”〜“） 不进行编码。 *所有其他字符必须进行编码。 *用来表示编码的两个十六进制字符 字符必须是大写的。 此方法不同，所使用的编码方案 “应用程序/ X - WWW形式进行了urlencoded”的内容类型（例如，IT 空格字符的编码为“％20”，而不是使用“+”字符）。 它可能是从所提供的％编码功能的不同 Web开发框架（例如，不同的字符编码，使用 小写十六进制字符）。 4。安全注意事项 正如在[RFC2617]中指出，风险最大的来源通常是 在核心协议本身不符合，但在政策和程序 围绕它的使用。大力鼓励实施者评估 这个协议是如何满足其安全要求。 4.1。RSA - SHA1签名方法 “RSA - SHA1”签名的身份验证的请求不使用 令牌的共享秘密，或任何配置的客户端共享秘密。这 意味着要求完全依赖私钥的保密性 客户端使用的签名请求。 锤Lahav信息[29] RFC 5849 OAuth的1.0 2010年4月 4.2。保密性要求 虽然这个协议提供了一个验证的完整性的机制 的请求，但它没有提供要求保密的保证。 除非采取进一步的预防措施，将有充分的窃听 访问请求的内容。服务器应该仔细考虑 种可能是这样的请求的一部分发送的数据，并应 采用传输层的安全机制来保护敏感 资源。 4.3。通过假冒服务器的欺骗 该协议并没有试图验证真伪 服务器。一个敌对的一方可以利用这一优势，通过拦截 客户机的请求，并返回误导或不正确的 反应。服务供应商应该考虑这样的攻击时 使用此协议的开发服务，并应要求 传输层安全性任何请求所在的真实性 请求响应的服务器，或者是一个问题。 4.4。代理和缓存的验证内容 HTTP身份验证计划（第3.5.1节）是可选的。然而， [RFC2616]依靠的“授权”和“的WWW - Authenticate”头 领域，所以它可以区分身份验证的内容 保护。代理和缓存，特别是可能会失败，以充分 保护不使用这些头域的请求。 例如，可能是私人验证的内容存储在（从而 从检索）公开访问的缓存。服务器不使用 HTTP的“授权”标头字段应注意使用其他 机制，如“的Cache - Control”头字段，以确保 验证的内容是保护。 4.5。明文存储的凭据 客户端共享秘密共享秘密和令牌的功能相同 在传统的身份认证系统方式密码。为了 计算方法比“，RSA - SHA1”其他用途的签名， 服务器必须有明文形式获得这些机密。这是 相反，例如，现代操作系统，存储 用户凭据只是一个单向散列。 如果攻击者获得这些秘密 - 或者更糟， 服务器的数据库 - 所有这些秘密，他或她将能够 执行任何行动上的任何资源所有者的代表。因此， 关键是服务器，防止未经授权的这些秘密 访问。 锤Lahav信息[30] RFC 5849 OAuth的1.0 2010年4月 4.6。保密客户端凭据 在许多情况下，客户端应用程序的控制下将 可能不受信任的政党。例如，如果客户端是一个 桌面应用程序或免费提供源代码 可执行二进制文件，攻击者可以下载一个副本 分析。在这种情况下，攻击者将能够恢复 客户端凭据。 因此，服务器不应该使用客户端凭据单独 验证客户的身份。在可能的情况下，其他因素 如IP地址，以及应使用。 4.7。钓鱼攻击 广泛部署和类似协议可能会导致资源 业主变得习惯于被重定向到实践 他们被要求输入自己的密码的网站。如果资源 业主不小心，以验证这些网站的真实性 才进入他们的凭据，这将是攻击者可能 利用这种做法，以窃取资源所有者密码。 服务器应该尝试教育资源所有者的风险 钓鱼式攻击的姿势，并应提供机制，使 资源所有者确认其网站的真伪。 客户端开发人员应该考虑如何安全的影响 它们与用户代理（如单独的窗口，嵌入式）， 和最终用户的能力，以验证真伪 服务器的网站。 4.8。划定范围的访问请求 就其本身而言，这个协议不提供任何作用域的方法 授予客户端访问权限。然而，大多数应用程序 需要更大的访问权限粒度。例如，服务器 不妨使人们有可能授予访问一些受保护的 的资源，但不是别人，或给予只有有限的访问（如 只读访问）那些受保护的资源。 服务器执行这一议定书时，应考虑类型 访问资源所有者可能希望授予客户，并应提供 这样做的机制。服务器也应照顾，以确保 资源所有者了解他们授权的访问，以及 任何可能涉及的风险。 锤Lahav信息[31] RFC 5849 OAuth的1.0 2010年4月 4.9。秘密熵 除非是用于传输层安全协议，窃听 将有充分的访问身份验证的请求和签名，并 从而能够安装脱机蛮力攻击收回 凭据使用。服务器应该小心地分配共享的秘密 足够长的时间，以及足够的随机，抵御此类攻击 至少时间的长短，共享秘密是有效的。 例如，如果共享机密的有效期为两个星期，服务器 应确保安装蛮力攻击，这是不可能 在不到两周的时间恢复共享的秘密。当然， 服务器敦促谨慎，并使用时间最长的 秘密合理。 同样重要的是，伪随机数发生器 （PRNG）的用于生成这些秘密足够高 质量。许多PRNG的实现产生数字序列 可能会出现是随机的，但是，然而表现出的图案或 其他的弱点，使密码分析或蛮力攻击 更容易。实施者应谨慎使用加密 安全PRNGs避免这些问题。 4.10。拒绝服务/资源耗尽攻击 本规范包含的功能，可能使 资源耗尽攻击的服务器可能。例如， 这个协议要求服务器跟踪使用的随机数。如果一个攻击者 能够使用许多随机数迅速，所需的资源来跟踪 他们可能会耗尽可用容量。再次，这个协议可以 需要服务器来执行潜在的昂贵的计算 为了验证传入的请求签名。攻击者可能会 利用此派遣一个由执行拒绝服务攻击 无效的请求到服务器的数量。 资源耗尽攻击，绝不是特定 规范。然而，实施者应慎重考虑 攻击这个协议公开，更多的渠道 相应地设计其实现。例如，熵 要么完全否定的服务通常会导致饥饿 同时系统等待新的熵或其他弱（容易 猜测的）秘密。执行本议定书时，服务器应 考虑这些，他们提出了更严重的风险 相应的应用和设计。 锤Lahav信息[32] RFC 5849 OAuth的1.0 2010年4月 4.11。SHA - 1密码攻击 SHA - 1“HMAC - SHA1算法的哈希算法”使用和“RSA - SHA1” 签名的方法，已被证明有一个加密的数量 弱点，大大降低其耐碰撞 攻击。虽然这些弱点似乎不影响使用 基于散列的消息认证码（HMAC）和SHA - 1 应该不会影响“HMAC - SHA1”签名的方法，它可能会影响 使用“RSA - SHA1”签名方法。NIST已经宣布，它 由2010年的数字签名将淘汰使用SHA - 1 [NIST_SHA 1Comments]。 实事求是地讲，这些弱点是难以利用， 自己不构成重大风险，这个用户 协议。可能，但是，他们作出更有效的攻击， 和服务器时，应该考虑到这一点考虑是否 SHA - 1为他们的应用提供了充分的安全水平。 4.12。签名基本字符串限制 支持签名，签名设计已基本字符串 在本规范中定义的方法。那些设计额外 签名的方法，应该评估的兼容性 签名其安全要求的基本字符串。 自签名基字符串不覆盖整个HTTP 要求，如请求的实体体，大多数实体头，并 在其中的参数是发送的顺序，服务器应该采用 额外的机制来保护这些元素。 4.13。跨站点请求伪造（CSRF） 跨站点请求伪造（CSRF）是一个基于Web的攻击，即HTTP 请求从该网站信任的用户发送或有 身份验证。授权批准的CSRF攻击可以让一个 攻击者没有获得对受保护资源的授权 对用户的同意。服务器应该强烈考虑的最佳做法 CSRF的所有协议授权端点的预防。 CSRF的OAuth的回调URI的托管客户端的攻击也 可能。客户应防止对OAuth的回调URI的CSRF攻击 通过验证，在客户端站点资源的所有者打算 完成与服务器的OAuth的谈判。对方法 防止此类CSRF攻击范围超出了本 规范。 锤Lahav信息[33] RFC 5849 OAuth的1.0 2010年4月 4.14。用户界面的申诉 服务器应该防止用户的授权过程 界面（UI）纠正攻击（又称常说的“clickjacking”）。作为 写这篇文章时，对用户界面没有完整的防御补救 可用。服务器可以减轻风险的UI纠正攻击使用 以下技术： Ø的JavaScript框架破坏。 Ø的JavaScript框架的破坏，并要求浏览器 授权页面上启用JavaScript。 Ø浏览器特定的反成帧技术。 Ø要求之前发出OAuth的令牌密码折返。 4.15。重复授权的自动处理 服务器可能希望自动处理授权请求 （2.2节），从先前已授权的客户端 资源的所有者。当资源的所有者将被重定向到 授予访问服务器，服务器检测到资源的所有者 已经获得特定客户端的访问。而是 促使批准的资源所有者，服务器会自动 资源所有者重定向回客户端。 如果客户端凭据被泄露，自动处理 创建额外的安全风险。攻击者可以利用被盗 客户端凭据将与服务器资源的所有者 授权请求。然后，服务器将授予访问 资源所有者的数据资源所有者的明确批准的情况下， 甚至攻击意识。如果没有自动批准 实施，攻击者必须使用社会工程来说服 资源所有者批准的访问。 服务器可以减轻与自动处理相关的风险 通过自动获得的令牌认证的范围限制 批准。通过明确的资源获得的令牌认证 拥有人的同意，可以不受影响。客户可以降低风险 自动处理相关的保护他们的客户 凭据。 锤Lahav信息[34] RFC 5849 OAuth的1.0 2010年4月 5。致谢 这个规范是直接基于OAuth的核心1.0修订版A 社会规范，这又是后，现有的建模 专有协议和已经独立的最佳做法 各公司实施。 社会规范被编辑伊兰锤Lahav 作者：马克阿特伍德，德克Balfanz，达伦界限，理查德M. 康兰，布莱恩库克，莉娅卡尔弗，布雷诺德门德洛斯，布赖恩伊顿， Kellan埃利奥特马克瑞，拉里HALFF，伊兰锤Lahav，本劳丽 克里斯墨西拿，大卫Recordon，伊兰，奎格利山姆，约翰装甲 桑德勒，乔纳森Sergent，托德Sieling，布莱恩Slesinsky，和安迪 史密斯。 编辑想感谢他们的以下个人 这个版本的出版的宝贵贡献 协议：丽莎Dusseault，贾斯汀哈特，Avshalom Houri，克里斯墨西拿， 马克诺丁汉大学，，彼得圣安德烈添波尔克，约瑟夫斯马，和保罗 沃克。 锤Lahav信息[35] RFC 5849 OAuth的1.0 2010年4月 附录A.从社区版的差异 本规范包括向以下变化 原有的社区文件[]以OAuthCore1.0_RevisionA 纠正错误和遗漏确定，因为该文件是 最初出版<http://oauth.net>。 Ø改变使用TLS / SSL当发送或请求纯文本 从应该必须凭据。这种变化会影响任何使用 “明文”的签名方法，以及要求临时 凭据（2.1节），并获得令牌的凭据 （2.3节）。 Ø调整nonce的语言，以表明它是每令牌独特/ 时间戳/客户端的结合。 Ø删除时间戳的要求等于或大于 比以前的请求中使用时间戳。 Ø改变nonce和时间戳参数可选的，使用时 “明文”的签名方法。 O扩展签名基字符串覆盖，包括 “应用程序/ X - WWW形式进行了urlencoded”实体主体的参数，当 所使用的HTTP方法是“邮报”和URI查询参数以外 当所使用的HTTP方法以外的“GET”。 Ø公司在每个签名的说明的更正 的方法进行编码的签名值前插入 “oauth_signature”参数，消除错误， 造成双重编码值。 Ø允许省略“oauth_token”的参数为空时。 Ø允许发送一个空的临时凭据请求 “oauth_token”参数。 Ø定义额外的“oauth_删除”的限制 参数。 锤Lahav信息[36] RFC 5849 OAuth的1.0 2010年4月 6。参考文献 6.1。规范性引用文件 [RFC2045]中解放出来，N. N.鲍仁斯坦，“多用途Internet邮件 扩展（MIME）第一部分：Internet邮件格式 团体“，RFC 2045，1996年11月。 [RFC2104] Krawczyk，H.，Bellare，研究和R.卡内蒂，“HMAC：键入 散列用于消息身份验证“，RFC 2104， 1997年2月。 [RFC2119]中布拉德纳，S.，“在RFC中主要使用的话来表示 要求水平“，BCP 14，RFC 2119，1997年3月。 [RFC2616]菲尔丁，河，Gettys，研究，莫卧儿研究，Frystyk，阁下， Masinter，L.，利奇，P.和T伯纳斯 - 李，“超 传输协议 - HTTP/1.1“，2616，1999年6月。 [RFC2617]弗兰克斯，哈勒姆贝克，体育，霍斯泰特勒研究，劳伦斯，南， 利奇，P.，Luotonen，A.，和L.斯图尔特“HTTP 身份验证：基本和摘要访问认证“， RFC 2617，1999年6月。 [RFC2818] Rescorla，E.，“TLS之上的HTTP”，RFC 2818，2000年5月。 [RFC3447]琼森，J. B. Kaliski，“公钥加密 标准（PKCS）＃1：RSA加密规格 2.1版“，RFC 3447，2003年2月。 [RFC3629] Yergeau，F.，“UTF - 8，ISO转换格式 10646“，STD 63，RFC 3629，2003年11月。 [RFC3986]伯纳斯 - 李，T.，菲尔丁和L Masinter，“统一。 资源标识符（URI）：通用语法“，性病66 RFC 3986，2005年1月。 [W3C.REC HTML40 - 19980424] 开胃，A.，Raggett，D.和一雅各布，“HTML 4.0的 规范“，万维网联盟 建议拍摄HTML40 - 19980424，1998年4月， <http://www.w3.org/TR/1998/REC-html40-19980424>。 锤Lahav信息[37] RFC 5849 OAuth的1.0 2010年4月 6.2。资料性参考文献 [NIST_SHA - 1Comments] 伯尔，W.，“NIST的密码分析攻击的评论 SHA - 1“， <http://csrc.nist.gov/groups/ST/hash/statement.html>。 [OAuthCore1.0_RevisionA] OAuth的社区，“OAuth的核心1.0修订版A”， <http://oauth.net/core/1.0a>。 作者地址 伊兰锤Lahav（编辑） 电子邮件：eran@hueniverse.com URI：http://hueniverse.com
互联网工程任务组（IETF）E.锤Lahav，埃德。
请求评论：2010年4月5849
分类：信息
ISSN：2070至1721年
OAuth的1.0协议
摘要
OAuth的为客户提供了一个方法来访问服务器资源
资源所有者的代表（如不同的客户端或结束
用户）。它还提供了一个过程，为最终用户授权第三
党访问到他们的服务器资源不共享
凭据（通常情况下，对用户名和密码），使用用户
代理重定向。
本备忘录的状态
这个文件是不是一个Internet标准跟踪规范，它是
发表，供参考之用。
这个文件是互联网工程任务组的产品
（IETF）的。它代表了IETF的社会共识。它有
接受公众审查批准，并已出版
互联网工程指导组（IESG）。不是所有文件
IESG批准的任何级别的互联网的候选人
标准，请参阅RFC 5741的第2条。
有关本文档的当前状态，任何勘误，
以及如何提供反馈，可于
http://www.rfc-editor.org/info/rfc5849。
版权声明
版权所有（c）2010 IETF信托基金和作为确定的人
文档作者。保留所有权利。
这个文件是受口岸78和IETF的信托的法律
IETF文档的有关规定
（http://trustee.ietf.org/license-info）中的日期起生效
本文件的出版。请仔细阅读这些文件
小心，因为它们描述了您的权利和尊重的限制
本文件。从这份文件中提取的代码组件
包括简体BSD许可证文本在第4.E
信托和法律规定，提供不附带作为
描述在简体的BSD许可证。
锤Lahav信息[1]
RFC 5849 OAuth的1.0 2010年4月
目录表
1。简介................................................. ... ... 3
1.1。术语................................................ 4
1.2。示例................................................. ... ... 5
1.3。符号约定..................................... 7
2。重定向为基础的授权................................. 8
2.1。临时全权证书...................................... 9
2.2。资源所有者的授权.............................. 10
2.3。令牌凭据......................................... 12
3。经过身份验证的请求......................................... 14
3.1。提出要求........................................... 14
3.2。验证要求........................................ 16
3.3。nonce和时间戳....................................... 17
3.4。签名................................................. 18
3.4.1。签名基本字符串.............................. 18
3.4.2。HMAC - SHA1算法.......................................... 25
3.4.3。RSA - SHA1 ........................................... 25
3.4.4。PLAINTEXT .......................................... 26
3.5。参数传递.................................... 26
3.5.1。Authorization头............................... 27
3.5.2。表单编码的机构.................................. 28
3.5.3。请求URI查询.................................. 28
3.6。百分比编码.......................................... 29
4。安全注意事项........................................ 29
4.1。RSA - SHA1签名方法................................. 29
4.2。保密性要求............................... 30
4.3。欺骗通过假冒服务器........................... 30
4.4。代理和缓存的验证内容............. 30
4.5。明文存储的凭据.......................... 30
4.6。保密客户端凭据......................... 31
4.7。钓鱼攻击.......................................... 31
4.8。划定范围的访问请求................................ 31
4.9。熵的秘密........................................ 32
4.10。拒绝服务/资源耗尽攻击.......... 32
4.11。SHA - 1加密攻击.............................. 33
4.12。签名基本字符串限制........................ 33
4.13。跨站点请求伪造（CSRF）........................ 33
4.14。用户界面申诉................................... 34
4.15。自动处理重复授权............ 34
5。致谢................................................ 35
附录A.从社区版的差异............... 36
6。参考文献................................................. .... 37
6.1。规范性引用文件...................................... 37
6.2。资料性参考文献.................................... 38
锤Lahav信息[第2页]
RFC 5849 OAuth的1.0 2010年4月
1。简介
OAuth协议最初创建一个小社区的Web
开发商从各种网站和其他互联网服务世界卫生组织
要解决使委派访问的常见问题
受保护的资源。由此产生的OAuth协议稳定在
1.0版在2007年10月，并于2009年6月修订（修订版A）
在<http://oauth.net/core/1.0a>出版。
本规范规定的OAuth的信息文档
核心1.0修订版A，地址，因为这几个勘误报告
时间，使众多的编辑澄清。虽然这
规范并不是IETF的OAuth的工作组，项目
在写作时是OAuth的版本，可以
适合在标准轨道上刊登，它已
转移到IETF变更控制原始作者
工作。
在传统的客户机 - 服务器的身份验证模型，客户端
使用其凭据来访问服务器托管其资源。
随着越来越多地使用分布式Web服务和云
计算，第三方应用程序需要访问这些服务器
托管资源。
OAuth的引入了第三个角色，以传统的客户机 - 服务器
身份验证模式：资源的所有者。在OAuth的模型，
客户端（这是不是资源的所有者，但代表其行事）
请求访问资源的所有者所控制的资源，但
由服务器托管。此外，OAuth的允许服务器验证
不仅是资源的所有者的授权，但也是身份
客户端提出请求。
OAuth的为客户提供了一个方法来访问服务器资源
资源所有者的代表（如不同的客户端或结束
用户）。它还提供了一个过程，为最终用户授权第三
党访问到他们的服务器资源不共享
凭据（通常情况下，对用户名和密码），使用用户
代理重定向。
例如，一个网络用户资源的所有者可以授予印刷服务
（客户端）访问她的私人照片存储在照片共享
服务（服务器），如果没有她的用户名和密码与共享
印刷服务。相反，她验证直接与照片
共享服务问题的印刷服务代表团
凭据。
锤Lahav信息[第3页]
RFC 5849 OAuth的1.0 2010年4月
在为客户端访问资源时，它首先必须获得
从资源所有者的许可。此权限表示
令牌的形式和配套共享秘密。的目的
令牌是不必要的资源所有者分享其
与客户端的凭据。不同的是资源的所有者凭证，
令牌可发出与一个受限制的范围和使用寿命有限，
撤销独立。
本规范由两部分组成。第一部分定义了一个
基于重定向用户代理进程，为最终用户授权
客户端访问自己的资源，通过直接与认证
服务器和客户端配置与使用令牌
身份验证方法。第二部分定义了一个制作方法
验证HTTP [RFC2616]的要求，使用两套全权证书，
确定客户端请求，第二个
标识上资源的所有者，其代表的请求被
作出。
与任何传输协议，比[RFC2616中的OAuth的其他用途
不确定的。
1.1。术语
客户端
HTTP客户端（每[RFC2616]）能够使OAuth的
身份验证的请求（第3）。
服务器
HTTP服务器（每[RFC2616]）能够接受OAuth的
身份验证的请求（第3）。
受保护的资源
可以从一个访问受限资源
服务器使用OAuth的身份验证的请求（第3）。
资源的所有者
一个实体能够访问和控制保护
资源使用证书进行身份验证的服务器。
凭据
凭据是对一个唯一的标识符匹配
共享的秘密。OAuth的定义了三个班的凭据：
客户端，暂时的，和令牌，用于识别和认证
客户端提出请求时，授权请求，
批的访问。
锤Lahav信息[第4页]
RFC 5849 OAuth的1.0 2010年4月
令牌
发出的服务器和客户端所使用的唯一标识符
联想到与资源拥有者进行身份验证的请求
其授权要求，或已获得
客户端。令牌有一个共享的秘密是使用匹配
客户端的记号，以确定其所有权，其
有权代表资源的所有者。
原有的社会规范使用略有不同
术语本规范地图如下（原
左侧提供的社会计算）：
消费者：客户端
服务提供商：服务器
用户名：资源的所有者
消费者密钥和秘密：客户端凭据
请求令牌和秘密：临时凭据
访问令牌和秘密：令牌的凭据
1.2。示例
简（资源的所有者）最近上传一些私人度假
照片（受保护的资源），以她的照片共享网站
“photos.example.net”（服务器）。她想使用
“printer.example.com”网站（客户端）来打印这些照片之一。
通常情况下，简成“photos.example.net”标志使用她的用户名
和密码。
但是，简不希望分享她的用户名和密码
“printer.example.com”网站，该网站需要访问照片的
为了打印出来。为了它的用户提供更好的
服务，“printer.example.com”已签署了一套
“photos.example.net”客户端凭据的时间提前：
客户端标识符
dpf43f3p2l4k3l03
客户端的共享秘密：
kd94hf93k423kf44
'printer.example.com“网站也配置及其应用
使用协议“photos.example.net的API中列出的端点
文档，它使用“HMAC - SHA1”签名的方法：
锤Lahav信息[第5页]
RFC 5849 OAuth的1.0 2010年4月
临时凭证请求
https://photos.example.net/initiate
资源所有者的授权URI：
https://photos.example.net/authorize
令牌请求的URI：
https://photos.example.net/token
之前，“printer.example.com'可以要求简授予访问
照片，它必须先建立一个临时凭据
'photos.example.net“，以确定该代表团的要求。要做到这一点，
客户端发送以下的HTTPS [RFC2818]请求到服务器：
POST /启动HTTP/1.1
主机：photos.example.net
授权：OAuth的境界=“照片”，
oauth_consumer_key =“dpf43f3p2l4k3l03”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131200”，
oauth_nonce =“wIjqoS”
oauth_callback =“HTTP％3A％2F％2Fprinter.example.com％2Fready”
oauth_signature =“74KNZJeDHnMBp0EMJ9ZHt％2FXKycU％3D”
服务器验证请求，并答复了一套临时
在HTTP响应体的凭据（换行符
显示仅供参考）：
HTTP/1.1 200 OK
内容类型：应用程序/ x - www的形式进行了urlencoded
oauth_token = hh5s93j4hdidpola＆oauth_token_secret = hdhd0244k9j7ao03＆
oauth_callback_confirmed = TRUE
客户端重定向简的用户代理服务器的资源的所有者
获得授权的端点简氏访问她的批准
私人照片：
https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
服务器请求简签署在使用自己的用户名和密码
如果成功的话，问她批准授予“printer.example.com”
访问她的私人照片。简批准的要求和她的
用户代理重定向到客户端所提供的回调的URI
在先前的请求（仅用于显示目的换行符）：
http://printer.example.com/ready？
oauth_token = hh5s93j4hdidpola oauth_verifier = hfdp7dh39dks9884
锤Lahav信息[6]
RFC 5849 OAuth的1.0 2010年4月
回调要求通知客户端，简完成
授权过程。然后，客户端请求的令牌
使用在一个安全的运输的临时凭据（凭据
层安全（TLS）通道）：
POST /令牌HTTP/1.1
主机：photos.example.net
授权：OAuth的境界=“照片”，
oauth_consumer_key =“dpf43f3p2l4k3l03”
oauth_token =“hh5s93j4hdidpola”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131201”，
oauth_nonce =“walatlh”
oauth_verifier =“hfdp7dh39dks9884”，
oauth_signature 2FIHF7IU％=“gKgrFCywp7rO0OXSjdot％3D”
服务器验证的令牌的请求和答复
在HTTP响应体的全权证书：
HTTP/1.1 200 OK
内容类型：应用程序/ x - www的形式进行了urlencoded
oauth_token = nnch734d00sl2jdk oauth_token_secret = pfkkdhi9sl3r4s00
客户端的令牌凭据，现在准备请求
私人照片：
GET /照片文件= vacation.jpg大小=原HTTP/1.1
主机：photos.example.net
授权：OAuth的境界=“照片”，
oauth_consumer_key =“dpf43f3p2l4k3l03”
oauth_token =“nnch734d00sl2jdk”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131202”，
oauth_nonce =“chapoH”
oauth_signature =“MdpQcU8iPSUjWoN％2FUDMsK2sui9I％3D”
“photos.example.net”服务器验证请求和响应
要求的相片。“printer.example.com”能够继续
使用同一组的令牌访问珍的私人照片
简的授权期限的凭据，或直至简
撤销访问。
1.3。符号约定
关键词“必须”，“MUST NOT”，“”，“应该”，“不得”，
“应该”，“不应该”，“建议”，“可能”，和“可选的”在此
文件[RFC2119]中描述的被解释为。
锤Lahav信息[7]
RFC 5849 OAuth的1.0 2010年4月
2。基于重定向的授权
OAuth的代表授予的授权使用令牌
客户端资源的所有者。通常情况下，令牌认证
服务器资源所有者的要求发出后，
验证资源所有者的身份（通常使用
用户名和密码）。
有许多方法，其中一台服务器可以方便的配置
令牌的凭据。本节定义了一个这样的方式，使用HTTP
重定向和资源所有者的用户代理。这种重定向 -
基于授权的方法包括三个步骤：
1。客户端从服务器获得一个临时凭据
（在标识符和共享秘密的形式）。临时
凭据用于识别访问请求，整个
授权的过程。
2。资源所有者授权服务器，给予客户的
访问请求（临时的凭据确定）。
3。客户端使用暂时的凭据，要求一套
从服务器的令牌凭证，这将使它能够访问
资源所有者的受保护资源。
该服务器后，必须撤销所使用的临时凭据
一旦获得令牌的凭据。这是建议
临时凭据有一个有限的生命周期。服务器应该启用
资源所有者后，他们已撤销令牌凭据
向客户发出。
为了为客户端执行这些步骤，服务器需要
做广告以下三个端点的URI：
临时凭证请求
用于获取客户端的临时端点
2.1节中所述的凭据。
资源所有者的授权
端点资源的所有者将被重定向到授予
授权2.2节中所述。
令牌的请求
客户端所使用的端点请求令牌
使用设置临时凭据的凭据描述
在第2.3节。
锤Lahav信息[8]
RFC 5849 OAuth的1.0 2010年4月
三个服务器发布的URI可能包括一个查询组件
所界定的[RFC3986]，第3，但如果存在的话，查询必须
不包含任何参数“oauth_”前缀开始，
避免冲突的协议参数的URI时
使用。
在该服务器的通告和文件，它的三个方法
端点超出本规范的范围。客户应
避免使有关的纪念品和其他大小的假设服务器
生成的值，这是左本规范未定义的。在
此外，协议参数可能包括需要的值
编码传输时。不应该使客户端和服务器
假设他们的价值可能范围。
2.1。临时全权证书
客户端获得一个临时凭据从服务器通过设置
经过身份验证（第3）HTTP“POST”的要求
临时凭证请求端点（除非服务器通告
另一个客户端使用的HTTP请求方法）。客户端
通过添加以下所需的参数，构造一个请求URI
请求（除了其他的协议参数，使用
相同的参数的传输方法）：
oauth_callback：回服务器将绝对URI
当资源的所有者重定向资源的所有者
完成授权的步骤（2.2节）。如果
客户端无法接收回调或
已通过其他手段建立回调的URI，
参数值必须设置为“OOB”（区分
敏感），以表明一个out - of -波段
配置。
服务器可以指定额外的参数。
提出请求时，客户端进行身份验证仅使用
客户端凭据。客户端可以省略空“oauth_token”
协议从请求参数，必须使用空字符串
令牌的秘密值。
由于纯文本传输的请求结果
在HTTP响应中的凭据，服务器必须要求使用
如TLS或安全套接字层（SSL）传输层机制
（或具有同等保护的安全通道）。
锤Lahav信息[9]
RFC 5849 OAuth的1.0 2010年4月
例如，客户端以下的HTTPS请求：
POST / request_temp_credentials HTTP/1.1
主机：server.example.com
授权：OAuth的境界=“范例”，
oauth_consumer_key =“jd83jd92dhsh93js”
oauth_signature_method =“明文”，
oauth_callback =“HTTP％3A％2F％2Fclient.example.net％2Fcb 3Fx％3D1％”，
oauth_signature =“ja893SD9 26％”
服务器必须验证（3.2节）的要求，如果有效，
回应一个临时凭据与客户端（在
标识符和共享秘密的形式）。临时
凭据是包含在HTTP响应体中使用
“应用程序/ X - WWW形式进行了urlencoded”的内容类型定义
[W3C.REC HTML40 - 19980424] 200状态码（确定）。
响应包含下列必需参数：
oauth_token
临时凭据标识符。
oauth_token_secret
共享秘密的临时凭据。
oauth_callback_confirmed
必须存在，并且设置为“true”。该参数是用来
区别于以前的版本的协议。
请注意，即使参数名称包括“令牌”一词，
这些凭据没有令牌的凭据，但在未来使用
两个步骤，以类似的方式令牌凭据。
例如（仅用于显示目的换行符）：
HTTP/1.1 200 OK
内容类型：应用程序/ x - www的形式进行了urlencoded
oauth_token = hdk48Djdsa oauth_token_secret = xyz4992k83j47x0b
oauth_callback_confirmed = TRUE
2.2。资源所有者的授权
在客户端请求从令牌凭据
服务器时，必须到服务器的用户发送授权请求。
加入以下所需客户端构造请求URI
资源所有者的授权端点URI查询参数：
锤Lahav信息[10]
RFC 5849 OAuth的1.0 2010年4月
oauth_token
在2.1节中获得临时凭据标识符
“oauth_token”参数。服务器可以宣布这一点
作为可选的参数，在这种情况下，他们必须提供一种方式
资源所有者表明通过其他标识符
手段。
服务器可以指定额外的参数。
使用客户端指示资源所有者的构造的URI
HTTP重定向响应，或可通过其他手段
资源所有者的用户代理。要求必须使用的HTTP“GET”
方法。
例如，客户端资源的所有者的用户代理重定向
以下的HTTPS请求：
GET / authorize_access？oauth_token = HTTP/1.1的hdk48Djdsa
主机：server.example.com
在该服务器的方式处理授权请求，
包括是否使用TLS / SSL的安全通道如超出
本规范的范围。然而，服务器必须首先
验证资源的所有者的身份。
当要求的资源所有者授权的访问请求，
服务器应提供有关的资源所有者信息
客户端请求访问的基础上，临时协会
凭据与客户端的身份。当显示任何此类
信息，服务器应说明信息已
验证。
接收从资源所有者的授权决定后，
服务器重定向资源的所有者，如果一个回调URI
在“oauth_callback”参数或以其他方式提供。
为了确保授予访问资源的所有者是相同的
资源的所有者返回到客户端来完成的过程，
服务器必须生成一个验证码：unguessable价值
通过资源的所有者，并传递给客户端要求完成
的过程。服务器结构中加入请求URI
回调URI查询组件所需的参数：
oauth_token
从客户端收到的临时凭据标识符。
锤Lahav信息[11]
RFC 5849 OAuth的1.0 2010年4月
oauth_verifier
验证码。
如果回调URI已经包含了查询组件，服务器
OAuth的参数必须附加到现有的查询结束。
例如，服务器资源所有者的用户代理重定向
下面的HTTP请求：
GET / CB？X = 1＆oauth_token = hdk48Djdsa＆oauth_verifier = 473f82d3 HTTP/1.1
主机：client.example.net
如果客户端没有提供一个回调URI，服务器应该
显示的验证码的值，并指示资源
所有者手动通知客户端，完成授权。
如果服务器知道客户端运行在一个有限的设备，它
应确保，验证值是适合于手工录入。
2.3。令牌的全权证书
客户端获得一个从服务器的令牌凭据通过设置
经过身份验证（第3）HTTP“POST”的请求令牌
请求端点（除非服务器通告另一个HTTP请求
客户端使用的方法）。客户端构造一个请求URI
通过添加下列所需的参数的要求（在
除了其他的协议参数，使用相同的参数
传输方法）：
oauth_verifier
在前面的，从服务器收到验证码
第一步。
提出请求时，客户端使用客户端进行身份验证
凭据以及临时凭据。临时
在令牌凭据的替代品被用作凭据
身份验证的请求和传送使用“oauth_token”
参数。
由于纯文本传输的请求结果
在HTTP响应中的凭据，服务器必须要求使用
如TLS或SSL（传输层的机制或一个安全通道
具有同等的保护）。
锤Lahav信息[12]
RFC 5849 OAuth的1.0 2010年4月
例如，客户端以下的HTTPS请求：
POST / request_token HTTP/1.1
主机：server.example.com
授权：OAuth的境界=“范例”，
oauth_consumer_key =“jd83jd92dhsh93js”
oauth_token =“hdk48Djdsa”
oauth_signature_method =“明文”，
oauth_verifier =“473f82d3”，
oauth_signature =“ja893SD9％26xyz4992k83j47x0b”
服务器必须验证（3.2节）的请求的有效性，
确保资源的所有者已授权供应
令牌凭据客户端，并确保临时
没有过期的凭据或使用过。服务器必须
也验证从客户端收到的验证码。如果
请求是有效的，并授权令牌的凭据
在使用HTTP响应体
“应用程序/ X - WWW形式进行了urlencoded”的内容类型定义
[W3C.REC HTML40 - 19980424] 200状态码（确定）。
响应包含下列必需参数：
oauth_token
令牌的标识符。
oauth_token_secret
令牌的共享秘密。
例如：
HTTP/1.1 200 OK
内容类型：应用程序/ x - www的形式进行了urlencoded
oauth_token = j49ddk933skd9dks oauth_token_secret = ll399dj47dskfjdk
服务器必须保留的范围，期限和其他属性
批准资源的所有者，并强制执行这些限制
接收客户端请求发出的令牌凭据。
一旦客户端接收和存储令牌的凭据，它可以
代表资源的所有者进行访问受保护资源
通过使用客户端的身份验证的请求（第3）
收到令牌的凭据凭据一起。
锤Lahav信息[13]
RFC 5849 OAuth的1.0 2010年4月
3。经过身份验证的请求
[RFC2617]使客户定义的HTTP身份验证方法
使身份验证的HTTP请求。使用这些方法的客户端
获得访问受保护资源，利用他们的凭据
（通常情况下，对用户名和密码），它允许服务器
验证其真实性。使用这些方法代表团
要求客户端资源的所有者承担的角色。
OAuth的方法提供了设计，包括两套全权证书
每个请求，识别客户端，而另一个
确定资源的所有者。在用户端可以验证
对资源的所有者代表的请求，它必须获得一个令牌
由资源的所有者授权。第2节提供了这样一个方法
通过该客户端即可获得授权令牌
资源的所有者。
客户端凭据采取的形式和一个唯一的标识符
相关的共享秘密或RSA密钥对。在作出
身份验证的请求，客户端建立一组凭据
与服务器。配置这些过程和要求
本规范的范围之外。实施者敦促
考虑使用客户端凭据的安全后果，
其中有些是在第4.6节。
身份验证的请求需要的先验知识
服务器的配置。OAuth的包括多种方法
传输协议参数的要求（3.5节），以及
为多个客户端的方法来证明其合法所有权
使用的凭据（3.4节）。，其中客户端的方式
发现所需的配置是此范围以外的
规范。
3.1。提出要求
经过身份验证的请求包括几项协议参数。每个
参数的名字开始与“oauth_”的前缀，参数
名称和值是大小写敏感的。客户端发出身份验证的
请求通过计算一个协议参数设置的值
并将它们添加到HTTP请求如下：
1。客户端分配这些必要的（除非
协议另有规定外）的参数：
锤Lahav信息[14]
RFC 5849 OAuth的1.0 2010年4月
oauth_consumer_key
客户端凭据的标识符部分（相当于
用户名）。参数的名称反映了过时的的术语
（消费密钥），用于在以前版本的规范，
并一直保留，以保持向后兼容性。
oauth_token
使用标记值与资源相关联的要求
所有者。如果请求是不相关的资源所有者
（可用任何标记），客户可以省略参数。
oauth_signature_method
客户端所使用的签名方式签署的名称
要求，在3.4节中定义。
oauth_timestamp
在3.3节中定义的时间戳值。该参数
使用“明文”签名的方法时，可以省略。
oauth_nonce
nonce值在3.3节中定义的。该参数可能
使用“明文”签名的方法时，可以省略。
oauth_version
可选的。如果存在，必须被设置为“1.0”。提供的
在这个定义的认证过程中的版本
规范。
2。协议参数被添加到使用一个请求
在3.5节中列出的传输方法。每个参数都必须
不会出现超过每请求一次。
3。客户端计算和分配的价值
“oauth_signature”参数描述在3.4节，并增加了
请求参数，在使用相同的方法
前面的步骤。
4。客户端发送到服务器的身份验证的HTTP请求。
例如，下面的HTTP请求进行身份验证（
“C2＆A3 = 2 + Q”字符串，在下面的例子是用来说明
的形式编码的实体主体的影响）：
B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？
主持人：example.com
内容类型：应用程序/ x - www的形式进行了urlencoded
C2＆A3 = 2 + Q
锤Lahav信息[15]
RFC 5849 OAuth的1.0 2010年4月
客户端分配值以下协议参数使用
它的客户端凭据，令牌认证，当前时间戳，
唯一产生的随机数，并表示，它将使用
“HMAC - SHA1”签名的方法：
oauth_consumer_key：9djdj82h48djs9d2
oauth_token：kkk9d7dh3k39sjv7
oauth_signature_method：HMAC - SHA1算法
oauth_timestamp：137131201
oauth_nonce：7d8f3e4a
客户端将使用请求的协议参数
OAuth的HTTP的“授权”标头字段：
授权：OAuth的境界=“范例”，
oauth_consumer_key =“9djdj82h48djs9d2”
oauth_token =“kkk9d7dh3k39sjv7”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131201”，
oauth_nonce =“7d8f3e4a”
然后，计算出“oauth_signature”参数值
（使用客户端的秘密“j49sk3j29djd”令牌的秘密“dh893hdasih9”），
将它添加到该请求，并发送HTTP请求到服务器：
B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？
主持人：example.com
内容类型：应用程序/ x - www的形式进行了urlencoded
授权：OAuth的境界=“范例”，
oauth_consumer_key =“9djdj82h48djs9d2”
oauth_token =“kkk9d7dh3k39sjv7”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131201”，
oauth_nonce =“7d8f3e4a”
oauth_signature =“bYT5CMsGcbgUdFHObYMEfcx6bsw％3D”
C2＆A3 = 2 + Q
3.2。验证要求
接收经过身份验证的请求的服务器必须验证：
Ø重新计算请求签名独立所述
从客户端收到第3.4节和它的价值进行比较
通过“oauth_signature”参数。
锤Lahav信息[16]
RFC 5849 OAuth的1.0 2010年4月
如果使用“的HMAC - SHA1”或“RSA - SHA1”签名方法，确保
结合的nonce /时间戳/令牌（如果存在）
从客户端收到尚未使用过的，在以前的
请求（服务器可能会拒绝陈旧的时间戳请求
在3.3节中所述）。
o如果一个记号目前，核查的范围和状态
客户端授权令牌（服务器可以代表
选择它是客户端的令牌的使用限制
印发）。
o如果“oauth_version”参数，确保其价值
“1.0”。
如果请求验证失败，服务器应与
适当的HTTP响应状态代码。该服务器可以包括
为何请求被拒绝响应的进一步细节
身体。
服务器应当返回一个400（错误请求）状态代码时
接受与不支持的参数，不支持请求
签名的方法，缺少的参数，或复制协议
参数。服务器应当返回一个401（未授权）状态
代码时，接收请求的，无效的客户端凭据
无效或过期的令牌，签名无效，或无效或使用
NONCE。
3.3。nonce和时间戳
时间戳值必须是一个正整数。除非另有
由该服务器的文档指定，表示时间戳
在1970年1月1日起，日00:00:00 GMT以来的秒数。
一个nonce是一个随机字符串，唯一由客户端生成，让
服务器来验证一个请求前，从未
有助于防止重放攻击，非安全请求时
通道。nonce值必须是唯一的与所有要求
相同的时间戳，客户端凭据，令牌组合。
为了避免需要保留一个无限数量的nonce值
以后的检查中，服务器可以选择限制一段时间后
这与旧的时间戳的请求被拒绝。请注意，这
限制意味着客户端之间的同步水平
与服务器的时钟。应用这种限制的服务器可提供
一个客户端与服务器的时钟同步方式;另外，
这两个系统可以同步一个值得信赖的时间服务。详情
时钟同步的战略已经超出此范围
规范。
锤Lahav信息[17]
RFC 5849 OAuth的1.0 2010年4月
3.4。签名
OAuth的身份验证的请求可以有两套全权证书：那些
通过“oauth_consumer_key”参数，并在通过
“oauth_token”参数。在为服务器，以验证
真实性的要求，并防止未经授权的访问，
客户的需求，以证明它是的合法所有者
凭据。这是通过使用共享秘密的（或RSA
键），每个组凭据的一部分。
OAuth的为客户提供了三种方法来证明其合法
所有权的凭据：“HMAC - SHA1算法”，“RSA - SHA1”，并
“明文”。这些方法一般简称为签名
方法，即使“明文”不涉及一个签名。在
此外，“RSA - SHA1”利用，而不是共享的RSA密钥
秘密相关的客户端凭据。
OAuth的不规定特定签名的方法，因为每个
实施可以有自己独特的要求。服务器是
免费实施和记录自己的自定义方法。
推荐任何特定的方法是超出了这个范围
规范。实施者应审查安全
注意事项“部分（第4），然后决定哪种方法
支持。
其中签名的方法是通过使用客户端声明
“oauth_signature_method”参数。然后生成一个签名
（或同等价值的字符串）和包括在
“oauth_signature”参数。服务器验证签名
指定为每个方法。
签名过程中不会改变的请求或参数，
除了“oauth_signature”参数。
3.4.1。签名基本字符串
签名基字符串是一致的，重复性的串联
几个成一个字符串的HTTP请求元素。“
字符串作为输入到“HMAC - SHA1算法”和“RSA - SHA1”
签名方法。
签名基字符串包含了以下组件
HTTP请求：
Ø HTTP请求方法（例如，“GET”，“POST”等）。
Ø的HTTP“主机”请求头字段声明的权力。
锤Lahav信息[18]
RFC 5849 OAuth的1.0 2010年4月
Ø请求资源的URI路径和查询组件。
Ø不包括“oauth_signature”协议参数。
o参数包括在请求实体主体，如果他们遵守
在3.4.1.3节中定义的严格限制。
签名的基本字符串，不包括整个HTTP请求。
最值得注意的是，它不包括在大多数请求的实体主体，
也不包括最HTTP实体头。重要的是要
请注意，服务器无法验证的排斥的真实性
不要求使用额外的保护，如SSL /组件
TLS或其他方法。
3.4.1.1。字符串建设
签名基字符串构造串连在一起，
为了下面的HTTP请求的内容：
1。以大写的HTTP请求方法。例如：“团长”，
“GET”，“POST”等，如果要求使用一个自定义的HTTP方法，
必须进行编码（第3.6节）。
2。一个“＆”字符（ASCII代码38）。
3。从第3.4.1.2基本字符串URI，被编码后
（3.6节）。
4。一个“＆”字符（ASCII代码38）。
5。第3.4.1.3.2请求参数正常化后，
被编码（第3.6节）。
例如，HTTP请求：
B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？
主持人：example.com
内容类型：应用程序/ x - www的形式进行了urlencoded
授权：OAuth的境界=“范例”，
oauth_consumer_key =“9djdj82h48djs9d2”
oauth_token =“kkk9d7dh3k39sjv7”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131201”，
oauth_nonce =“7d8f3e4a”
oauth_signature =“bYT5CMsGcbgUdFHObYMEfcx6bsw％3D”
C2＆A3 = 2 + Q
锤Lahav信息[19]
RFC 5849 OAuth的1.0 2010年4月
代表由以下签名的基本字符串（换行符
仅供显示）：
邮政的http％3A％2F％2Fexample.com％2Frequest A2％3DR％2520b％26a3％3D2％2520q
％26a3％3DA％26b5％3D％253D％25253D％26C％2540％26c2％3D％3D％26oauth_consumer_
关键26oauth_nonce％3D9djdj82h48djs9d2％％3D7d8f3e4a％26oauth_signature_m
ethod％3DHMAC - SHA1％26oauth_timestamp％3D137131201％26oauth_token％3Dkkk
9d7dh3k39sjv7
3.4.1.2。基本字符串URI
该计划的权威性，请求资源的路径的URI [RFC3986]
包括兴建一个“HTTP”或“https”的URI代表
请求资源（不包括查询或片段）如下：
1。该计划和主机必须是小写。
2。主机和端口值必须匹配的HTTP内容
要求“主机”头字段。
3。如果它不是默认端口为端口必须包括
如果它是默认的计划，必须排除。具体来说，
端口HTTP请求时，必须排除[RFC2616]
到80端口或HTTPS请求时，[RFC2818] 443端口。
必须包括所有其他非默认端口号。
例如，HTTP请求：
GET / R％20V / X吗？ID = 123 HTTP/1.1
主持人：EXAMPLE.COM：80
为代表的基本字符串的URI：“http://example.com/r％20V / X”。
在另一个例子中，HTTPS请求：
Q = 1 HTTP/1.1的的GET /？
主机：www.example.net:8080
为代表的基本字符串URI：
“https://www.example.net:8080/”。
3.4.1.3。请求参数
为了保证一个一致的和可重复性的代表性
请求参数，参数的收集和解码
其原始的解码形式。然后，他们排序，并在编码
特定的方式，往往是从原来的不同
编码方案，并串联成一个字符串。
锤Lahav信息[20]
RFC 5849 OAuth的1.0 2010年4月
3.4.1.3.1。参数源
从下列来源的参数都收集到一个单一的
列表中的名称/值对：
Ø所定义的HTTP请求的URI的查询组件
[RFC3986]，第3.4节。查询组件解析成一个列表
当作一个名称/值对
“应用程序/ X - WWW形式进行了urlencoded”字符串，分隔名称
和值和解码定义
[W3C.REC HTML40 - 19980424]，第17.13.4。
Ø了OAuth HTTP“授权”标头栏位（第3.5.1节）
目前。标题的内容解析为名称/值列表
对排除的“境界”的参数，如果目前。该参数
3.5.1节中定义的值解码。
Ø HTTP请求实体主体，但只有当所有下列
条件是：
*实体主体是单一的一部分。
*实体主体遵循的编码要求
“应用程序/ X - WWW形式进行了urlencoded”所界定的内容类型
[W3C.REC HTML40 - 19980424]。
* HTTP请求实体标题包括“内容类型”
头字段设置为“应用程序/ X - WWW形式进行了urlencoded”。
实体主体是解析成一个解码的名称/值对列表
[W3C.REC HTML40 - 19980424]，第17.13.4。
“oauth_signature”参数必须排除的签名
基本字符串（如果存在）。在没有明确包含的参数
销售的要求，必须排除从签名的基本字符串（例如，。
“oauth_version”参数省略时）。
锤Lahav信息[21]
RFC 5849 OAuth的1.0 2010年4月
例如，HTTP请求：
B5 =％3D％253D＆A3 = A＆C％40 =＆A2 = R％20B HTTP/1.1的POST /要求？
主持人：example.com
内容类型：应用程序/ x - www的形式进行了urlencoded
授权：OAuth的境界=“范例”，
oauth_consumer_key =“9djdj82h48djs9d2”
oauth_token =“kkk9d7dh3k39sjv7”
oauth_signature_method =“HMAC - SHA1算法”
oauth_timestamp =“137131201”，
oauth_nonce =“7d8f3e4a”
oauth_signature =“djosJKDKJSD8743243％2Fjdk33klY％3D”
C2＆A3 = 2 + Q
包含以下（全解码）中使用的参数
签名基地蜇：
+------------------------+------------------+
|名称|价值|
+------------------------+------------------+
| B5 | =％3D |
| A3 | Å |
| C @ | |
| A2 | RB |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC - SHA1算法|
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| C2 | |
| A3 | 2 Q |
+------------------------+------------------+
请注意，“B5”的价值是“=％3D”，而不是"==". 这两个“C”和
“C2”空值。虽然在这个指定的编码规则
规范签名基地建设的目的
字符串排除使用一个“+”字符（ASCII代码43）
代表编码的空格字符（ASCII代码32），这种做法
在“应用程序/ x - www的形式，进行了urlencoded”编码值中被广泛使用，
，必须正确解码，由“A3”一个证明
参数实例（“A3”的参数是用来在这两次
请求）。
锤Lahav信息[22]
RFC 5849 OAuth的1.0 2010年4月
3.4.1.3.2。参数正常化
第3.4.1.3收集到的参数归成
单个字符串如下：
1。首先，名称和每个参数的值编码
（3.6节）。
2。参数按名称进行排序，采用递增的字节值
订购。如果两个或多个参数有着相同的名字，他们
其价值排序。
3。每个参数的名称被连接到其相应的
价值作为分隔符使用一个“=”字符（ASCII代码61），即使
如果值是空的的。
4。排序的名称/值对串联在一起成
通过使用一个“＆”字符（ASCII代码38）的单个字符串
分隔符。
例如，从上一节的参数列表
被归为如下：
编码：
+------------------------+------------------+
|名称|价值|
+------------------------+------------------+
| B5 |％3D％253D |
| A3 | Å |
| C％40 | |
| A2 | R％20B |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC - SHA1算法|
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| C2 | |
| A3 | 2％20Q |
+------------------------+------------------+
锤Lahav信息[23]
RFC 5849 OAuth的1.0 2010年4月
排序方式：
+------------------------+------------------+
|名称|价值|
+------------------------+------------------+
| A2 | R％20B |
| A3 | 2％20Q |
| A3 | Å |
| B5 |％3D％253D |
| C％40 | |
| C2 | |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_nonce | 7d8f3e4a |
| oauth_signature_method | HMAC - SHA1算法|
| oauth_timestamp | 137131201 |
| oauth_token | kkk9d7dh3k39sjv7 |
+------------------------+------------------+
串联双：
+-------------------------------------+
|名称=值|
+-------------------------------------+
| A2 = R％20B |
| A3 = 2％20Q |
| A3 = Å |
| B5 =％3D％253D |
| C％40 = |
| C2 = |
| oauth_consumer_key = 9djdj82h48djs9d2 |
| oauth_nonce = 7d8f3e4a |
| oauth_signature_method = HMAC - SHA1 |
| oauth_timestamp = 137131201 |
| oauth_token = kkk9d7dh3k39sjv7 |
+-------------------------------------+
并连接成一个字符串（换行符
显示仅供参考）：
A2 = R％20B＆A3 = 2％20Q＆A3 = A＆B5 =％3D％253D＆C％40 =＆C2 =＆oauth_consumer_key = 9dj
dj82h48djs9d2＆oauth_nonce = 7d8f3e4a oauth_signature_method = HMAC - SHA1算法
＆oauth_timestamp = 137131201＆oauth_token = kkk9d7dh3k39sjv7
锤Lahav信息[24]
RFC 5849 OAuth的1.0 2010年4月
3.4.2。HMAC - SHA1算法
“HMAC - SHA1”签名的方法，使用HMAC - SHA1算法的签名
算法，在[RFC2104]中定义：
消化= HMAC - SHA1算法（键，文本）
HMAC - SHA1算法的函数变量用于下列方式：
文字签名基地字符串的值设置为从
第3.4.1.1。
关键是设置的串联值：
1。客户端的共享秘密，被编码后
（3.6节）。
2。“＆”字符（ASCII代码38），它必须被列入
甚至秘密时要么是空的。
3。令牌的共享秘密，被编码后
（3.6节）。
消化是用来设置“oauth_signature”协议的价值
参数后，结果字节串是base64编码
每[RFC2045]，第6.8节。
3.4.3。RSA - SHA1
“RSA - SHA1”签名方法使用RSASSA - PKCS1 - v1_5签名
算法定义在[RFC3447]，第8.2节（也称为
PKCS＃1），使用SHA - 1散列函数，EMSA - PKCS1 - v1_5。要
使用这种方法，客户端必须建立客户端凭据
与服务器的方式，包括RSA公钥（
本规范的范围之外）。
使用客户端的RSA私钥签名基字符串签署
每[RFC3447]键，第8.2.1节：
S = RSASSA - PKCS1 - V1_5 - SIGN（K，M）
其中：
K是设置客户端的RSA私钥，
M是设置签名基地字符串值
第3.4.1.1
锤Lahav信息[25]
RFC 5849 OAuth的1.0 2010年4月
S是用来设置值的结果签名
“oauth_signature”协议参数，结果八位字节后
字符串％[RFC2045]的6.8节是base64编码。
服务器验证％[RFC3447]第8.2.2节的签名：
RSASSA - PKCS1 - V1_5验证（（N，E），M，S）
其中：
（N，E）设置为客户端的RSA公钥，
M是设置签名基地字符串值
第3.4.1.1
S设置为字节串“oauth_signature”价值
从客户机接收协议参数。
3.4.4。PLAINTEXT
“明文”的方法，不采用的签名算法。它
必须使用传输层机制，如TLS或SSL（或
在一个相当于保护的安全通道发送）。它不
利用签名的基本字符串或“oauth_timestamp”和
“oauth_nonce”参数。
“oauth_signature”协议参数设置的串联
价值：
1。客户端的共享秘密被编码后，（第3.6节）。
2。“＆”字符（ASCII代码38），它必须被列入甚至
无论是秘密的时候是空的。
3。令牌的共享秘密，被编码后的（3.6节）。
3.5。参数传递
OAuth的身份验证的请求时，协议参数
以及任何其他参数，应使用“oauth_”前缀
包括在使用之一，下面只有一个请求
地点，偏好递减的顺序列出：
1。HTTP的“授权”标头字段中所述
第3.5.1节。
2。HTTP请求实体主体的第3.5.2节中所述。
锤Lahav信息[26]
RFC 5849 OAuth的1.0 2010年4月
3。在3.5.3节中描述的HTTP请求的URI查询。
除了这三种方法，在未来的扩展，可以定义
其他方法，包括请求的协议参数。
3.5.1。Authorization头
可以传输协议参数使用HTTP的“授权”
头字段[RFC2617]中定义的设置与验证计划名称
“OAuth的”（不区分大小写）。
例如：
授权：OAuth的境界=“范例”，
oauth_consumer_key =“0685bd9184jfhq22”
oauth_token =“ad180jjd733klru7”
oauth_signature_method =“HMAC - SHA1算法”
oauth_signature =“wOJIO9A2W5mFwDgiDvZbTSMK％2FPY％3D”
oauth_timestamp =“137131200”，
oauth_nonce =“4572616e48616d6d65724c61686176”
oauth_version =“1.0”
协议参数应包括在“授权”头
字段如下：
1。每个参数编码的编码参数名称和值
（3.6节）。
2。每个参数的名称后面紧跟着一个“=”字符
（ASCII代码61），“”字符（ASCII代码34），参数
值（可能为空），和另一个“”“字符（ASCII代码34）。
3。参数分离“，”字符（ASCII代码44）和
可选的线性空白每[RFC2617]。
4。可选的“境界”的参数可以补充和解释每
[RFC2617] 1.2节。
服务器可能表明他们为“OAuth的”验证计划的支持
返回的HTTP“的WWW - Authenticate”响应头字段后，
受保护的资源的客户端请求。由于每[RFC2617]，这样的
响应可能包括额外的HTTP“的WWW - Authenticate”头
专业领域：
例如：
WWW验证：OAuth的境界=“http://server.example.com/”
锤Lahav信息[27]
RFC 5849 OAuth的1.0 2010年4月
realm参数定义了一个保护领域，每[RFC2617]，第
1.2。
3.5.2。表单编码的身体
协议参数可以传送HTTP请求的实体
的身体，但只有如果满足下列要求的条件：
Ø实体主体是单一的一部分。
Ø实体主体遵循的编码要求
“应用程序/ X - WWW形式进行了urlencoded”所界定的内容类型
[W3C.REC HTML40 - 19980424]。
Ø HTTP请求实体标题包括“内容类型”的头
字段设置为“应用程序/ X - WWW形式进行了urlencoded”。
例如（仅用于显示目的换行符）：
oauth_consumer_key = 0685bd9184jfhq22 oauth_token = ad180jjd733klr
U7 oauth_signature_method = HMAC - SHA1算法oauth_signature = wOJIO9A2W5
mFwDgiDvZbTSMK％2FPY％3D＆oauth_timestamp = 137131200＆oauth_nonce = 4
572616e48616d6d65724c61686176＆oauth_version = 1.0
该实体的身体可能包括其他请求特定的参数，
这种情况下，应附加协议参数后
请求特定的参数，适当的“＆”字符隔开
（ASCII码38）。
3.5.3。请求URI查询
可以被添加到HTTP传输协议参数
请求URI [RFC3986]，第3节中定义一个查询参数。
例如（仅用于显示目的换行符）：
/例如/路径？oauth_consumer_key = 0685bd9184jfhq22＆
oauth_token = ad180jjd733klru7 oauth_signature_method = HM
AC - SHA1 oauth_signature = wOJIO9A2W5mFwDgiDvZbTSMK％2FPY％
3D＆oauth_timestamp = 137131200＆oauth_nonce = 4572616e48616
d6d65724c61686176 oauth_version = 1.0 HTTP/1.1
请求URI可能包括其他特定于请求的查询参数，
在这种情况下，应附加以下协议参数
请求特定的参数，由一个适当分离“及”
字符（ASCII代码38）。
锤Lahav信息[28]
RFC 5849 OAuth的1.0 2010年4月
3.6。百分比编码
现有的％编码方法不保证一以贯之
签名的基本字符串的建设。以下％
没有定义编码方法，以取代现有的编码
[RFC3986]中定义的方法和[W3C.REC HTML40 - 19980424]。这是
只在签名基地字符串的建设和使用
“授权”标头字段。
本规范定义了编码％以下方法
字符串：
1。文本值将被编码为UTF - 8％[RFC3629]八位字节，如果
他们是不是已经。这不包括的二进制值
不适合人类食用。
2。使用[RFC3986]％的编码的值，然后逃脱
（百分之二十）的机制如下：
*在毫无保留的字符的字符集定义
[RFC3986]，第2.3（字母，数字，“ - ”“，”_“，”〜“）
不进行编码。
*所有其他字符必须进行编码。
*用来表示编码的两个十六进制字符
字符必须是大写的。
此方法不同，所使用的编码方案
“应用程序/ X - WWW形式进行了urlencoded”的内容类型（例如，IT
空格字符的编码为“％20”，而不是使用“+”字符）。
它可能是从所提供的％编码功能的不同
Web开发框架（例如，不同的字符编码，使用
小写十六进制字符）。
4。安全注意事项
正如在[RFC2617]中指出，风险最大的来源通常是
在核心协议本身不符合，但在政策和程序
围绕它的使用。大力鼓励实施者评估
这个协议是如何满足其安全要求。
4.1。RSA - SHA1签名方法
“RSA - SHA1”签名的身份验证的请求不使用
令牌的共享秘密，或任何配置的客户端共享秘密。这
意味着要求完全依赖私钥的保密性
客户端使用的签名请求。
锤Lahav信息[29]
RFC 5849 OAuth的1.0 2010年4月
4.2。保密性要求
虽然这个协议提供了一个验证的完整性的机制
的请求，但它没有提供要求保密的保证。
除非采取进一步的预防措施，将有充分的窃听
访问请求的内容。服务器应该仔细考虑
种可能是这样的请求的一部分发送的数据，并应
采用传输层的安全机制来保护敏感
资源。
4.3。通过假冒服务器的欺骗
该协议并没有试图验证真伪
服务器。一个敌对的一方可以利用这一优势，通过拦截
客户机的请求，并返回误导或不正确的
反应。服务供应商应该考虑这样的攻击时
使用此协议的开发服务，并应要求
传输层安全性任何请求所在的真实性
请求响应的服务器，或者是一个问题。
4.4。代理和缓存的验证内容
HTTP身份验证计划（第3.5.1节）是可选的。然而，
[RFC2616]依靠的“授权”和“的WWW - Authenticate”头
领域，所以它可以区分身份验证的内容
保护。代理和缓存，特别是可能会失败，以充分
保护不使用这些头域的请求。
例如，可能是私人验证的内容存储在（从而
从检索）公开访问的缓存。服务器不使用
HTTP的“授权”标头字段应注意使用其他
机制，如“的Cache - Control”头字段，以确保
验证的内容是保护。
4.5。明文存储的凭据
客户端共享秘密共享秘密和令牌的功能相同
在传统的身份认证系统方式密码。为了
计算方法比“，RSA - SHA1”其他用途的签名，
服务器必须有明文形式获得这些机密。这是
相反，例如，现代操作系统，存储
用户凭据只是一个单向散列。
如果攻击者获得这些秘密 - 或者更糟，
服务器的数据库 - 所有这些秘密，他或她将能够
执行任何行动上的任何资源所有者的代表。因此，
关键是服务器，防止未经授权的这些秘密
访问。
锤Lahav信息[30]
RFC 5849 OAuth的1.0 2010年4月
4.6。保密客户端凭据
在许多情况下，客户端应用程序的控制下将
可能不受信任的政党。例如，如果客户端是一个
桌面应用程序或免费提供源代码
可执行二进制文件，攻击者可以下载一个副本
分析。在这种情况下，攻击者将能够恢复
客户端凭据。
因此，服务器不应该使用客户端凭据单独
验证客户的身份。在可能的情况下，其他因素
如IP地址，以及应使用。
4.7。钓鱼攻击
广泛部署和类似协议可能会导致资源
业主变得习惯于被重定向到实践
他们被要求输入自己的密码的网站。如果资源
业主不小心，以验证这些网站的真实性
才进入他们的凭据，这将是攻击者可能
利用这种做法，以窃取资源所有者密码。
服务器应该尝试教育资源所有者的风险
钓鱼式攻击的姿势，并应提供机制，使
资源所有者确认其网站的真伪。
客户端开发人员应该考虑如何安全的影响
它们与用户代理（如单独的窗口，嵌入式），
和最终用户的能力，以验证真伪
服务器的网站。
4.8。划定范围的访问请求
就其本身而言，这个协议不提供任何作用域的方法
授予客户端访问权限。然而，大多数应用程序
需要更大的访问权限粒度。例如，服务器
不妨使人们有可能授予访问一些受保护的
的资源，但不是别人，或给予只有有限的访问（如
只读访问）那些受保护的资源。
服务器执行这一议定书时，应考虑类型
访问资源所有者可能希望授予客户，并应提供
这样做的机制。服务器也应照顾，以确保
资源所有者了解他们授权的访问，以及
任何可能涉及的风险。
锤Lahav信息[31]
RFC 5849 OAuth的1.0 2010年4月
4.9。秘密熵
除非是用于传输层安全协议，窃听
将有充分的访问身份验证的请求和签名，并
从而能够安装脱机蛮力攻击收回
凭据使用。服务器应该小心地分配共享的秘密
足够长的时间，以及足够的随机，抵御此类攻击
至少时间的长短，共享秘密是有效的。
例如，如果共享机密的有效期为两个星期，服务器
应确保安装蛮力攻击，这是不可能
在不到两周的时间恢复共享的秘密。当然，
服务器敦促谨慎，并使用时间最长的
秘密合理。
同样重要的是，伪随机数发生器
（PRNG）的用于生成这些秘密足够高
质量。许多PRNG的实现产生数字序列
可能会出现是随机的，但是，然而表现出的图案或
其他的弱点，使密码分析或蛮力攻击
更容易。实施者应谨慎使用加密
安全PRNGs避免这些问题。
4.10。拒绝服务/资源耗尽攻击
本规范包含的功能，可能使
资源耗尽攻击的服务器可能。例如，
这个协议要求服务器跟踪使用的随机数。如果一个攻击者
能够使用许多随机数迅速，所需的资源来跟踪
他们可能会耗尽可用容量。再次，这个协议可以
需要服务器来执行潜在的昂贵的计算
为了验证传入的请求签名。攻击者可能会
利用此派遣一个由执行拒绝服务攻击
无效的请求到服务器的数量。
资源耗尽攻击，绝不是特定
规范。然而，实施者应慎重考虑
攻击这个协议公开，更多的渠道
相应地设计其实现。例如，熵
要么完全否定的服务通常会导致饥饿
同时系统等待新的熵或其他弱（容易
猜测的）秘密。执行本议定书时，服务器应
考虑这些，他们提出了更严重的风险
相应的应用和设计。
锤Lahav信息[32]
RFC 5849 OAuth的1.0 2010年4月
4.11。SHA - 1密码攻击
SHA - 1“HMAC - SHA1算法的哈希算法”使用和“RSA - SHA1”
签名的方法，已被证明有一个加密的数量
弱点，大大降低其耐碰撞
攻击。虽然这些弱点似乎不影响使用
基于散列的消息认证码（HMAC）和SHA - 1
应该不会影响“HMAC - SHA1”签名的方法，它可能会影响
使用“RSA - SHA1”签名方法。NIST已经宣布，它
由2010年的数字签名将淘汰使用SHA - 1
[NIST_SHA 1Comments]。
实事求是地讲，这些弱点是难以利用，
自己不构成重大风险，这个用户
协议。可能，但是，他们作出更有效的攻击，
和服务器时，应该考虑到这一点考虑是否
SHA - 1为他们的应用提供了充分的安全水平。
4.12。签名基本字符串限制
支持签名，签名设计已基本字符串
在本规范中定义的方法。那些设计额外
签名的方法，应该评估的兼容性
签名其安全要求的基本字符串。
自签名基字符串不覆盖整个HTTP
要求，如请求的实体体，大多数实体头，并
在其中的参数是发送的顺序，服务器应该采用
额外的机制来保护这些元素。
4.13。跨站点请求伪造（CSRF）
跨站点请求伪造（CSRF）是一个基于Web的攻击，即HTTP
请求从该网站信任的用户发送或有
身份验证。授权批准的CSRF攻击可以让一个
攻击者没有获得对受保护资源的授权
对用户的同意。服务器应该强烈考虑的最佳做法
CSRF的所有协议授权端点的预防。
CSRF的OAuth的回调URI的托管客户端的攻击也
可能。客户应防止对OAuth的回调URI的CSRF攻击
通过验证，在客户端站点资源的所有者打算
完成与服务器的OAuth的谈判。对方法
防止此类CSRF攻击范围超出了本
规范。
锤Lahav信息[33]
RFC 5849 OAuth的1.0 2010年4月
4.14。用户界面的申诉
服务器应该防止用户的授权过程
界面（UI）纠正攻击（又称常说的“clickjacking”）。作为
写这篇文章时，对用户界面没有完整的防御补救
可用。服务器可以减轻风险的UI纠正攻击使用
以下技术：
Ø的JavaScript框架破坏。
Ø的JavaScript框架的破坏，并要求浏览器
授权页面上启用JavaScript。
Ø浏览器特定的反成帧技术。
Ø要求之前发出OAuth的令牌密码折返。
4.15。重复授权的自动处理
服务器可能希望自动处理授权请求
（2.2节），从先前已授权的客户端
资源的所有者。当资源的所有者将被重定向到
授予访问服务器，服务器检测到资源的所有者
已经获得特定客户端的访问。而是
促使批准的资源所有者，服务器会自动
资源所有者重定向回客户端。
如果客户端凭据被泄露，自动处理
创建额外的安全风险。攻击者可以利用被盗
客户端凭据将与服务器资源的所有者
授权请求。然后，服务器将授予访问
资源所有者的数据资源所有者的明确批准的情况下，
甚至攻击意识。如果没有自动批准
实施，攻击者必须使用社会工程来说服
资源所有者批准的访问。
服务器可以减轻与自动处理相关的风险
通过自动获得的令牌认证的范围限制
批准。通过明确的资源获得的令牌认证
拥有人的同意，可以不受影响。客户可以降低风险
自动处理相关的保护他们的客户
凭据。
锤Lahav信息[34]
RFC 5849 OAuth的1.0 2010年4月
5。致谢
这个规范是直接基于OAuth的核心1.0修订版A
社会规范，这又是后，现有的建模
专有协议和已经独立的最佳做法
各公司实施。
社会规范被编辑伊兰锤Lahav
作者：马克阿特伍德，德克Balfanz，达伦界限，理查德M.
康兰，布莱恩库克，莉娅卡尔弗，布雷诺德门德洛斯，布赖恩伊顿，
Kellan埃利奥特马克瑞，拉里HALFF，伊兰锤Lahav，本劳丽
克里斯墨西拿，大卫Recordon，伊兰，奎格利山姆，约翰装甲
桑德勒，乔纳森Sergent，托德Sieling，布莱恩Slesinsky，和安迪
史密斯。
编辑想感谢他们的以下个人
这个版本的出版的宝贵贡献
协议：丽莎Dusseault，贾斯汀哈特，Avshalom Houri，克里斯墨西拿，
马克诺丁汉大学，，彼得圣安德烈添波尔克，约瑟夫斯马，和保罗
沃克。
锤Lahav信息[35]
RFC 5849 OAuth的1.0 2010年4月
附录A.从社区版的差异
本规范包括向以下变化
原有的社区文件[]以OAuthCore1.0_RevisionA
纠正错误和遗漏确定，因为该文件是
最初出版<http://oauth.net>。
Ø改变使用TLS / SSL当发送或请求纯文本
从应该必须凭据。这种变化会影响任何使用
“明文”的签名方法，以及要求临时
凭据（2.1节），并获得令牌的凭据
（2.3节）。
Ø调整nonce的语言，以表明它是每令牌独特/
时间戳/客户端的结合。
Ø删除时间戳的要求等于或大于
比以前的请求中使用时间戳。
Ø改变nonce和时间戳参数可选的，使用时
“明文”的签名方法。
O扩展签名基字符串覆盖，包括
“应用程序/ X - WWW形式进行了urlencoded”实体主体的参数，当
所使用的HTTP方法是“邮报”和URI查询参数以外
当所使用的HTTP方法以外的“GET”。
Ø公司在每个签名的说明的更正
的方法进行编码的签名值前插入
“oauth_signature”参数，消除错误，
造成双重编码值。
Ø允许省略“oauth_token”的参数为空时。
Ø允许发送一个空的临时凭据请求
“oauth_token”参数。
Ø定义额外的“oauth_删除”的限制
参数。
锤Lahav信息[36]
RFC 5849 OAuth的1.0 2010年4月
6。参考文献
6.1。规范性引用文件
[RFC2045]中解放出来，N. N.鲍仁斯坦，“多用途Internet邮件
扩展（MIME）第一部分：Internet邮件格式
团体“，RFC 2045，1996年11月。
[RFC2104] Krawczyk，H.，Bellare，研究和R.卡内蒂，“HMAC：键入
散列用于消息身份验证“，RFC 2104，
1997年2月。
[RFC2119]中布拉德纳，S.，“在RFC中主要使用的话来表示
要求水平“，BCP 14，RFC 2119，1997年3月。
[RFC2616]菲尔丁，河，Gettys，研究，莫卧儿研究，Frystyk，阁下，
Masinter，L.，利奇，P.和T伯纳斯 - 李，“超
传输协议 - HTTP/1.1“，2616，1999年6月。
[RFC2617]弗兰克斯，哈勒姆贝克，体育，霍斯泰特勒研究，劳伦斯，南，
利奇，P.，Luotonen，A.，和L.斯图尔特“HTTP
身份验证：基本和摘要访问认证“，
RFC 2617，1999年6月。
[RFC2818] Rescorla，E.，“TLS之上的HTTP”，RFC 2818，2000年5月。
[RFC3447]琼森，J. B. Kaliski，“公钥加密
标准（PKCS）＃1：RSA加密规格
2.1版“，RFC 3447，2003年2月。
[RFC3629] Yergeau，F.，“UTF - 8，ISO转换格式
10646“，STD 63，RFC 3629，2003年11月。
[RFC3986]伯纳斯 - 李，T.，菲尔丁和L Masinter，“统一。
资源标识符（URI）：通用语法“，性病66
RFC 3986，2005年1月。
[W3C.REC HTML40 - 19980424]
开胃，A.，Raggett，D.和一雅各布，“HTML 4.0的
规范“，万维网联盟
建议拍摄HTML40 - 19980424，1998年4月，
<http://www.w3.org/TR/1998/REC-html40-19980424>。
锤Lahav信息[37]
RFC 5849 OAuth的1.0 2010年4月
6.2。资料性参考文献
[NIST_SHA - 1Comments]
伯尔，W.，“NIST的密码分析攻击的评论
SHA - 1“，
<http://csrc.nist.gov/groups/ST/hash/statement.html>。
[OAuthCore1.0_RevisionA]
OAuth的社区，“OAuth的核心1.0修订版A”，
<http://oauth.net/core/1.0a>。
作者地址
伊兰锤Lahav（编辑）
电子邮件：eran@hueniverse.com
URI：http://hueniverse.com
锤Lahav信息[38]
浙公网安备 33010602011771号