OpenID认证协议20中文版教案资料.doc
Good is good, but better carries it.精益求精，善益求善。OpenID认证协议20中文版-OpenIDAuthentication2.0ImplementorsDraft12OpenID认证协议2.0草案12TableofContents1.符号惯例42.术语53.协议概要64.数据格式64.1协议消息64.1.1键-值表单编码64.1.2HTTP编码74.1.3例子74.2整数的表示85.通信类型85.1直接通信85.1.1直接通信请求85.1.2直接通信响应85.1.2.1成功响应95.1.2.1失败响应95.2间接通信95.2.1HTTP重定向95.2.2HTML表单重定向95.2.3间接通信失败响应106.产生签名106.1步骤106.2签名算法107.初始化及自动发现117.1初始化117.2规格化117.3自动发现117.3.1自动发现的信息117.3.2基于XRDS的自动发现127.3.2.1OpenID服务条目127.3.3基于HTML的自动发现138.创建Association138.1Association会话请求148.1.1通用请求参数148.1.2Diffie-Hellman请求参数148.2Association会话响应148.2.1通用响应参数158.2.2非加密响应参数158.2.3Diffie-Hellman响应参数158.2.4不成功响应参数158.3Association类型168.3.1HMAC-SHA1168.3.2HMAC-SHA256168.4Association会话类型168.4.1No-EncryptionAssociation会话168.4.2Diffie-HellmanAssociation会话169.请求认证179.1请求参数179.2Realms189.2.1域189.2.2使用域对返回URL确认199.3即时请求（ImmediateRequests）1910.响应认证请求2010.1肯定断言2010.2否定断言2210.2.1响应即时请求2210.2.2响应非即时请求2211.验证断言2311.1验证返回URL2311.2验证发现的信息2311.3检查随机序列2411.4验证签名2511.4.1利用Association验证2511.4.2同OP直接验证2511.5标识用户2611.5.1标识回收2611.5.2HTTP和HTTPSURL标识2612.扩展2713.RP发现2814.与OpenID认证协议1.1版本兼容性2914.1自1.1版变更2914.1.1初始化与发现过程的更新2914.1.2安全改进2914.1.3扩展3014.2实现与1.1版兼容3014.2.1依赖方(RelyingParty)3014.2.2OpenID提供方(OpenIDProviders)3115.安全考虑3215.1预防攻击3215.1.1窃听攻击(EavesdroppingAttacks)3215.1.2中间人攻击(Man-in-the-MiddleAttacks)3215.2用户代理3315.3用户界面考虑3315.4HTTP和HTTPSURL标识3415.5拒绝服务攻击3415.6协议变量34附录A.示例35附录A.1规范化35附录A.2OP-Local标识36附录A.3XRDS36附录A.4HTML标识记号36附录A.5XRICanonicalID37附录B.Diffie-Hellman密匙交换默认值37AppendixC. Acknowledgements3716. NormativeReferences38对照词汇表英文中文MUST必须MUSTNOT必须不REQUIRED需要的SHALL应该SHALLNOT不应该SHOULD应该SHOULDNOT不应该RECOMMENDED推荐MAY可以OPTIONAL可选的Identifier标识User-AgentUARelyingPartyRPOpenIDProviderOPOPEndpointURLOP终点URL地址OPIdentifierOP标识User-SuppliedIdentifierUser-Supplied标识ClaimedIdentifierClaimed标识OP-LocalIdentifierOP-Local标识element条目tag标签Non-normative非正式example示例section节parameter参数assertiion断言user,enduesr用户associationassociationassociationsessionassociation会话associationsessiontypeassociation会话类型nonce随机序列realm域form表单request请求response响应Key-Value键-值Name-Value名-值message消息information信息MessageAuthenticationCodeMACcontext上下文normalization规格化sharedsecret共享密匙note注意stateless无状态initiation初始化discovery自动发现field字段文档历史版本日期撰写人备注0.12007-09-18XuxiChenxchenttg.ccZheZhangzzhangttg.ccSichuanLislittg.ccDennyWangdwangttg.cc内容合并，初步校对0.22007-09-19DennyWangdwangttg.cc复查至第8章0.32007-09-20ZheZhangzzhangttg.cc复查9-16章，并调整格式0.42007-09-21DennyWangdwangttg.cc复查全文0.52007-9-22ZheZhangzzhangttg.cc修改9-12章部分翻译1.符号惯例本文档中的下面这些关键字在RFC2119(Bradner,B.,“KeywordsforuseinRFCstoIndicateRequirementLevels,”.)标准中都有描述。MUST必须MUSTNOT必须不REQUIRED需要的SHALL应该SHALLNOT不应该SHOULD应该SHOULDNOT不应该RECOMMENDED推荐MAY可以OPTIONAL可选的在文档中，有些值是用引号引起来的，用来精确表示，在实际的协议消息中必须不用引号。2.术语Identifier标识标识为HTTP或HTTPS形式的URI（本文中一般地指URL）或XRI(eXtensibleResourceIdentifier)（可扩展的资源标识符，是一套与URI兼容的抽象标识符体系）。本文有不同类型的标识，是考虑不同的环境情景设计。User-Agent用户代理(简写为UA)一般为用户的浏览器，要实现HTTP/1.1RFC2616协议。RelyingParty依赖方（简写为RP）是一个WEB应用程序，它需要证实某用户确拥有一个标识。OpenIDProviderOpenId提供方（简写为OP）是一个提供验证OpenID标识的服务器，它能为RP提供断言，证实用户拥有某个标识。OPEndpointURLOpenId提供方(OP)终点URL是一个用来接收OpenID认证请求的URL，它是通过用户提供的标识而找到的，这个URL必须是绝对地址。OPIdentifierOpenId提供方标识是一个OpenIDProvider的标识。User-SuppliedIdentifierUser-Supplied标识是用户出示给RP的标识，或者是用户在OP那里选择的标识，用户可以敲入自己的标识也可以敲入OP标识，如果是OP标识，那OP要让用户选择一个标识给RP。ClaimedIdentifierClaimed标识是一个标识，用户声明自己拥有，本协议的目标就是查证他真的拥有该标识。这个标识可以是：如果是一个URL，是一个规格化后的User-Supplied标识。如果是一个XRI，则是一个CanonicalID。OP-LocalIdentifierOP-Local标识为用户提供的替代标识，定位到某一个OP，并不是由用户控制的。3.协议概要1. 用户通过UA(用户代理，通常为浏览器)向RP（依赖方）提供一个User-Supplied标识，初始化认证过程。2. 在规格化User-Supplied标识之后，RP执行自动发现来获取认证所需的OP终点URL地址。需要注意的是用户提供的标识也可以是OP标识(将在7.3.1节中讨论),这允许用户在OP上选择一个Claimed标识，或者如果通过其它的一些扩展将容许没有Claimed标识。3. （可选的）在RP和OP之间建立一个association通过Diffie-HellmanRFC2631密钥交换协议协商共享密钥。OP用association对消息签名，同时RP验证这些消息。这就可省略在每次请求/响应后续验证签名的直接请求。4. RP让用户的浏览器重定向到OP，并带上认证请求参数。5. OP确定这个用户是否有权并且愿意接受OpenID认证。至于用户如何鉴别OP和其它的鉴别策略不是这个文档讲的范围。6. OP让用户的浏览器重定向返回RP，参数中指明Authentication是认证通过还是认证失败。7. RP校验从OP收到的信息。检查ReturnURL，验证自动发现信息，检查nonce（随机序列），并用asscociation验证签名或发一个直接请求来验证。4.数据格式4.1协议消息OpenIDAuthentication（OpenID认证）协议消息全部是映射为文本的键值形式，这些键值允许是Unicode字符集（UCS），当它们转换成字节的时候，必须按照UTF-8形式编码RFC3629。消息必须不能有同名的参数。在这篇文档中，所有的OpenID消息都是必须的，除非特别申明为可选的。4.1.1键-值表单编码键-值表单组成的消息是由一系列的行组成，每行开始是一个键名,后跟一个冒号，然后是该参数的值，结束于一个换行符（”n”,UCS代码是10）。参数名和值都必须不包含换行符，参数名也必须不包含冒号。额外的字符，包括空白符，必须不出现在冒号前后或换行符的前后。消息必须编码成UTF-8形式的字节串。键-值表单编码会用于签名计算和给RP的直接响应中。4.1.2HTTP编码发送给HTTP服务器的消息，必须用规范HTML401中第17.13.4节的规格编码。如果“Content-Type”包含在请求头（RequestHeader）中，那么的报文体也必须这样编码。所有的请求消息的名都必须以“openid.”作前缀。这样可防止与认证消息中的其它参数冲突。当消息以“POST”方式发送时，OpenID参数必须只在Post报文体中。所有的消息请求（Get或Post）都必须包含下面的这些字段：l openid.ns值:”对于一个OpenID认证2.0版的请求,该值必须在请求中存在。将来的版本可能会定义其它的值来标识它的请求。如果这个值被省略或是"l opened.mode值:参照消息类型的不同而不同。参数openid.mode让消息接受者知道被处理的是什么类型的消息。如果没有openid.mode参数，我们应该假设这不是一个OpenID消息。该参数用于通过用户浏览器发送给依赖方RP和供应方OP，也用于从RP发给OP的消息。4.1.3例子非正式下面是要编码的消息：Key|值-+-mode|errorerror|Thisisanexamplemessage用键值表单的编码：mode:errorerror:Thisisanexamplemessage用x-www-urlencoded形式，也就是在HTTPPOST体中或URL地址的查询串中（RFC3986第3节）：openid.mode=error&openid.error=This%20is%20an%20example%20message4.2整数的表示任意精度的整数必须被表示为big-endian的补码（btwoc），Base64编码。换句话说，btwoc是一个函数，输入bigint并返回shortestbig-endian补码。所有用于Diffie-Hellman密钥交换的整数皆为正数。这意味着双字节的最左边位必须为零，如果不是，程序必须在这个串的前面加零。非正式例子：10进制数|btwoc字符串表示-+-0|"x00"127|"x7F"128|"x00x80"255|"x00xFF"32768|"x00x80x00"5.通信类型5.1直接通信直接通信由RP初始化，用于向OP终点URL提出申请，主要用于创建Association和验证认证断言。5.1.1直接通信请求请求消息必须按照POST方式编码，参见4.1.2节。所有直接通信请求都是HTTPPOST，并且含有4.1.2节列出的所需字段。5.1.2直接通信响应响应的主体由HTTP响应主体，即键-值组成。响应中的content-type应该设为"text/plain"。所有键-值应该包含如下字段：l ns值："一个有效的OpenID2.0响应必须包含这个特值。因为以后的标准可能为请求定义不同的值，这样设定才能使消息接受方恰当地解释请求消息。如不指定该值或指定为以下两者之一，"5.1.2.1成功响应当服务器接收到有效请求时，必须返回HTTP状态码为200的成功响应。5.1.2.1失败响应如果请求消息格式不正确，或者包含无效参数，服务器必须返回HTTP状态码为400的失败响应。响应主体必须包含下列键-值信息：l ns参见5.1.2节。l error值：人可理解的消息，指出错误原因。l contact值：(可选)服务管理员的联系地址。该地址可以以任何形式表达。l reference值：(可选)参考标记，如支持代号或新闻blog的URL链接等。OP可以给响应添加额外字段。5.2间接通信在间接通信中，消息通过UA来传递。RP和OP都可以初始化间接通信。它可用于认证请求和认证响应。该通信方式有两种方法：HTTP重定向和HTML表单提交。两者都要求发送方指定接收方的URL，并且接收方URL可接受间接消息到来，如4.1.2。通信的初始化选择哪种方法接受视能力而定，比如消息大小或者其他外在因素。所有间接消息以HTTP请求形式传送，并且包含4.1.2列出的需要的字段。5.2.1HTTP重定向可以通过对用户UA发出302,303,307HTTP重定向请求，进行数据传输。重定向URL是接收方的URL，并携带OpenID认证信息作为请求参数，如4.1.2指定。5.2.2HTML表单重定向通过返回包含了HTML表单条目的HTML页面给UA，可以传输键-值表。表单提交可以是自动完成的，比如使用JavaScript。<form>条目的"action"属性值必须是接收方的URL。每个键-值必须包含在表单的<input>条目中。键必须按照"name"属性编码，值必须以"value"属性编码，当提交表单时UA会生成如4.1.2指定的信息。表单必须包含提交按钮。5.2.3间接通信失败响应如果请求信息格式不正确或包含无效参数，OP必须重定向UA到"openid.return_to"URL，前提是该值已给出且是有效值。l openid.ns参见4.1.2l openid.mode值："error"l openid.error值：人可理解的消息，指出错误原因l openid.contact值：(可选)服务管理员的联系地址。该地址可以以任何形式表达(由人来读)。l openid.reference值：(可选)参考标记，如支持代号或新闻blog的URL链接等OP可以给响应添加额外字段。如果RP接收了错误格式的或者无效信息，或者"openid.return_to"未指定或无效，服务器应该返回响应给用户，指出连接失误无法继续通信。6.产生签名Association常以消息认证码(MAC)密钥的形式，来签署OpenID认证消息。产生MAC密钥时，应该遵守RFC1750给出的建议。6.1步骤产生消息签名需如下步骤：1. 根据需要签名的消息(10.1节)，决定签名的键列表。签名的键列表必须是消息的一部分。列表存储于键"openid.signed"中，值是以逗号分隔的键名列表，这些键名需以"openid."为前缀。这个方法仅用于以"openid."开头的签名键。2. 按照键在"openid.signed"列表中出现的顺序，在消息中找到每个键的对应值。3. 按照键-值表单编码，转换待签名的键-值为字节串。4. 在Association类型中选择签名算法，对已转换的字节串执行该算法。6.2签名算法OpenID认证支持两种签名算法：l HMAC-SHA1-160位(RFC2104(Krawczyk,H.,Bellare,M.,andR.Canetti,“HMAC:Keyed-HashingforMessageAuthentication,”.)和RFC3174(Eastlake,D.andP.Jones,“USSecureHashAlgorithm1(SHA1),”.)l HMAC-SHA256-256位(RFC2104(Krawczyk,H.,Bellare,M.,andR.Canetti,“HMAC:Keyed-HashingforMessageAuthentication,”.)和FIPS1802(U.S.DepartmentofCommerceandNationalInstituteofStandardsandTechnology,“SecureHashSignatureStandard,”.)一般推荐使用HMAC-SHA256算法。7.初始化及自动发现7.1初始化为了初始OpenID认证过程，RP应该给用户一个表格，该表格中需包含可以输入User-Supplied标识的字段。该表格字段中"name"属性应该包含"openid_identifier"，这样UA才能自动的识别这是一个OpenID表格。如果该属性未恰当设置，即使是支持OpenID认证的浏览器插件或其他软件，也可能检测不到该RP是支持OpenID的。7.2规格化用户输入必须被规格化为如下所示标识：1. 如果用户输入以"xri:/"开始，必须将其去掉，以便XRI能够以标准型使用。2. 如果结果字符串的第一个字符是XRI全局上下文符号（"=","","+","$","!")或(",2.2.1XRI_Syntax_2.0(Reed,D.andD.McAlpin,“ExtensibleResourceIdentifier(XRI)SyntaxV2.0,”.)中定义），应该以XRI处理。3. 除此之外，输入应该以HTTPURL处理；如果输入的标识中不包含"http"或"https"，必须添加http:/前缀。如果URL包含一个碎片(#后部分)，必须除去。查看11.5.2了解更多信息。4. 当检索其内容，和对最终目的（finaldestination）URL应用RFC3986(Berners-Lee,T.,“UniformResourceIdentifiers(URI):GenericSyntax,”.)第六部分的规则时，URL标识必须进一步规格化。最终URL必须经RP鉴定（benotedas）为Claimed标识，然后用于请求认证。参考规格化样例。7.3自动发现自动发现是指RP用标识来自动发现("discover")初始化请求的必要信息的过程。OpenID认证有三种途径实现自动发现：1. 如果标识是XRI形式，XRI_Resolution_2.0(Wachob,G.,Reed,D.,Chasen,L.,Tan,W.,andS.Churchill,“ExtensibleResourceIdentifier(XRI)ResolutionV2.0-WorkingDraft10,”.)将调用XRDS文档，该文档中包含必要信息。需要指出的是，RP可以利用XRI代理解释器（XRIProxyResolvers），如XDI.org在上提供的，这样RP就可以不用本地分解XRI了。2. 如果输入为一个URL，应该尝试Yadisprotocol(Miller,J.,“YadisSpecification1.0,”.)Yadis。如果成功，再检索XRDS文档。3. 如果Yadis协议失败并无有效XRDS文档可供检索，或文档中没有服务条目，则对URL(Miller,J.,“YadisSpecificati进行检索，并尝试基于HTML的自动发现。7.3.1自动发现的信息在成功完成自动发现的基础上，RP会得到一个或多个信息集（参考Terminologysection(Terminology)中定义），如下所示。如果多于一个信息集被自动发现，需应用XRI_Resolution_2.0(Wachob,G.,Reed,D.,Chasen,L.,Tan,W.,andS.Churchill,“ExtensibleResourceIdentifier(XRI)ResolutionV2.0-WorkingDraft10,”.)中定义的时间顺序规则。l OP终点URLl 协议版本如果用户未输入OP标识，应该同时给出以下信息：l Claimed标识l OP-Local标识如果用户输入了OP标识，则没有Claimed标识。为了产生OpenID认证请求，当输入OP标识时，必须把值"7.3.2基于XRDS的自动发现如果使用XRI或者Yadis自动发现，得到的结果是XRDS文档。这是一种XML文档，它包含标识中相关的服务条目，定义参见XRI_Resolution_2.0的第三部分，到附录A.3查看XRDS文档示例。7.3.2.1OpenID服务条目7.3.2.1.1OP标识条目一个OP标识是包含了下列信息的<xrd:Service>条目：l <xrd:Type>："l <xrd:URI>：OP终点URL7.3.2.1.2Claimed标识条目一个Claimed标识是包含如下信息的<xrd:Service>条目：l <xrd:Type>："l <xrd:URI>：OP终点URLl <xrd:LocalID>（可选）：OP-Local标识7.3.2.2抽取认证数据一旦RP得到了XRDS文档，必须先按照XRI_Resolution_2.0(Wachob,G.,Reed,D.,Chasen,L.,Tan,W.,andS.Churchill,“ExtensibleResourceIdentifier(XRI)ResolutionV2.0-WorkingDraft10,”.)的描述，搜索该文档得到OP标识条目。如果没有找到，RP将搜索Claimed标识条目。7.3.2.3XRI和CanonicalID条目当标识是XRI形式时，包含了OpenID认证<xrd:Service>的<xrd:XRD>条目必须也包含<CanonicalID>，该条目的值必须被用作Claimed标识(参考11.5(Identifyingtheenduser).这些是出于灵活和安全考虑的，因为CanonicalID条目的最初目的是断言一个不会被重分配的永久标识，这样可以阻止XRI被新注册者接管的可能。RP必须确认包含了<CanonicalID>条目的XRD的提供者对于CanonicalID具有权威性，并且XRDS文档对于OpenID服务条目具有权威性。RP应该手动确认，或者保证他们的解释器（resolver）作这件事。当使用XRI解释时，CanonicalID必须作为Claimed标识使用。要使XRI成为有效的标识，<ProviderID>和<CanonicalID>必须在自动发现的XRDS文档中给出。当使用URL标识时，如果给出CanonicalID条目，也要忽略才行。7.3.2.4附加信息在OpenID认证2.0中，"openid"命名空间不再被使用，而"xrd"命名空间是"xri:/$xrd*($v*2.0)"。考虑到代码兼容性，一般推荐RP也接受<xrd:Type>的值是""和"如果OP支持扩展(节 12(Extensions)，这些扩展应该作为附加的<xrd:Type>列出，同时这些<xrd:Type>作为<xrd:Service>的子条目。7.3.3基于HTML的自动发现基于HTML的自动发现必须被RP所支持，它只有在发现Claimed标识时有用。OP标识必须是支持XRDS自动发现的XRI或URL。使用基于HTML的自动发现，作为Claimed标识的这个URL上的HTML文档必须可访问，文档HEAD中需包含：l LINK，必须有属性"rel"指定为"openid2.provider"，"href"指定为OP终点URL；l LINK，可以有属性"rel"指定为"openid2.local_id"，"href"指定为OP-Local标识。执行HTML自动发现时，协议版本应该为"HTML文档的主机可以与用户OP主机不同。"openid2.provider"和"openid2.local_id"的URL必须不包含除了"&","<",">",和"""以外的实体，其他在HTML文档中是无效的字符，或文档字符编码不能表达的字符，则必须以百分号-编码(%xx)机制编码，RFC3986(Berners-Lee,T.,“UniformResourceIdentifiers(URI):GenericSyntax,”.)中描述了该机制。如OpenID认证1.1兼容模式中的讨论，这里提到的自动发现标签不同于以前的协议，即使表达相同的数据，名字却改变了，这样就允许RP来决定使用的协议版本。RP可以遇到同时发现1.1和2.0两种版本的OP的Claimed标识，这种标识也使用基于HTML的自动发现。 TOC 8.创建AssociationRP和OP的Association建立了它们之间的共享密钥，利用此密钥可以检验随后的协议消息，并减少交互次数。如果可能，推荐RP形成Association，如果RP不能创建或存储Association，11.4.2提供另一可用验证机制，即无状态模式(StatelessMode)。(VerifyingDirectlywiththeOpenIDProvider)8.1Association会话请求一个Association会话由从RP到OP终点URL的直接请求初始化，在该请求中将"openid.mode"的值设为"associate"。8.1.1通用请求参数下列参数为所有Association请求通用：l openid.ns见4.1.2(HTTP编码).l openid.mode值:"associate"l openid.assoc_typeAssociation类型定义了后续信息的签名算法.值:有效的Association类型8.3(Association类型)l openid.session_type定义传输中使用的加密AssociationMAC密钥的方法.值:有效Association会话类型8.4(Association会话类型).注:除非使用了传输层加密，"no-encryption"必须不使用.8.1.2Diffie-Hellman请求参数请求参数中Association会话类型（openid.session_type）为"DH-SHA1"或"DH-SHA256"时，下列参数必须给出：l openid.dh_modulus值:base64(btwoc(p)默认值:附录B(Diffie-HellmanKey交换默认值)l openid.dh_gen值:base64(btwoc(g)默认值:g=2l openid.dh_consumer_public值:base64(btwoc(gxamodp)参见8.4.2(Diffie-HellmanAssociation会话)，查看这些参数信息.注:'btwoc'方法的定义在4.2.8.2Association会话响应一个Association会话应当是从OP到RP的直接响应，这些响应为键-值形式。8.2.1通用响应参数l ns参见5.1.2.l assoc_handleAssociationhandle被用作在后续信息中检索该Association的关键词.值:少于等于255个字符的串，必须且仅能由33-126的ASCII字符（可打印非空格）组成。l session_type请求中"openid.session_type"的参数值，如果OP不愿或不能支持该Association类型，必须返回unsuccessfulresponse。l assoc_type请求中"openid.assoc_type"的参数值，如果OP不愿或不能支持该Association类型，必须返回unsuccessfulresponse。l expires_in秒级别的Association生命周期，过了这个时间RP必须不能使用该Association。值：base10ASCII表示的整数。8.2.2非加密响应参数l mac_key此Association的MAC密钥（共享密钥），Base64RFC3548编码。8.2.3Diffie-Hellman响应参数l dh_server_public值:base64(btwoc(gxbmodp)描述:OPDiffie-Hellman公钥.l enc_mac_key值:base64(H(btwoc(g(xa*xb)modp)XORMACkey)描述:MAC密钥（共享密钥），用secretDiffie-Hellman值加密.由会话类型决定H是"SHA1"还是"SHA256"。注:'btwoc'方法的定义在4.2.8.2.4不成功响应参数如果OP不支持会话类型或Association类型，它必须直接返回一个错误信息，指出Association请求失败。如果有其他支持的Association会话类型或者Association类型，OP应该在响应中包含如下信息：l ns参见5.1.2.l error值:人可理解的消息，指出错误原因.l error_code值:"unsupported-type"l session_type值:(可选)OP支持的有效Association会话类型8.4(Association会话类型).l assoc_type值:(可选)OP支持的有效Association类型8.3(Association类型).在收到"unsupported-type"响应时，RP可以用给出的Association会话类型和Association类型创建另一个请求。如果未创建Association，RP可以使用直接验证继续认证过程.8.3Association类型8.3.1HMAC-SHA1类型为"HMAC-SHA1"的Association，应使用HMAC-SHA1签名算法。8.3.2HMAC-SHA256类型为"HMAC-SHA256"的Association，应使用HMAC-SHA256签名算法。8.4Association会话类型OpenID认证定义了有效Association会话类
