互联网工程特别工作组（IETF）M.Jones征求意见：7519 Microsoft类别：标准轨道J.BradleyISSN:2070-1721 Ping身份N.Sakimura公司NRI公司2015年5月JSON Web令牌（JWT）摘要JSON Web Token（JWT）是一种紧凑、URL安全的表示方法双方之间转让的索赔。JWT中的索赔编码为用作JSON有效负载的JSON对象Web签名（JWS）结构或作为JSON Web的明文加密（JWE）结构，使索赔能够数字化使用消息身份验证代码进行签名或完整性保护（MAC）和/或加密。关于下段备忘这是一个互联网标准跟踪文档。本文件是互联网工程任务组的产品（IETF）。它代表了IETF社区的共识。它有已接受公众审查，并已由互联网工程指导小组（IESG）。关于的进一步信息RFC 5741第2节中提供了互联网标准。有关本文件当前状态的信息，任何勘误表，以及如何提供反馈，请访问http://www.rfc-editor.org/info/rfc7519。Jones等人，标准跟踪[第1页]RFC 7519 JSON Web令牌（JWT）2015年5月版权声明版权所有（c）2015 IETF Trust和被认定为文档作者。保留所有权利。本文件受BCP 78和IETF信托的法律约束IETF文件相关规定(http://trustee.ietf.org/license-info)于年月日生效本文件的出版。请审阅这些文件小心，因为他们尊重你的权利和限制添加到本文档中。从本文档中提取的代码组件必须包括简化的BSD许可证文本，如第4.e节所述信托法律条款和无担保如简化BSD许可证中所述。Jones等人。标准跟踪[第2页]RFC 7519 JSON网络令牌（JWT）2015年5月目录1.简介。41.1. 符号惯例。42.术语。43.JSON Web令牌（JWT）概述。63.1. 示例JWT。74.JWT索赔。84.1. 注册索赔名称。94.1.1. “iss”（发卡行）索赔。94.1.2. “子”（主题）索赔。94.1.3. “aud”（观众）索赔。94.1.4. “exp”（到期时间）索赔。94.1.5. “nbf”（不在之前）索赔。104.1.6. “iat”（签发地点）索赔。104.1.7. “jti”（JWT ID）索赔。104.2. 公共索赔名称。104.3. 私人索赔名称。105.JOSE标题。115.1. “typ”（类型）标题参数。115.2. “cty”（内容类型）标题参数。115.3. 复制声明作为标题参数。126.无担保JWT。126.1. 无担保JWT示例。127.创建和验证JWT。137.1. 创建JWT。137.2. 验证JWT。147.3. 字符串比较规则。158.实施要求。169.用于声明内容是JWT的URI。1710.IANA注意事项。1710.1. JSON Web令牌声明注册表。1710.1.1. 注册模板。1810.1.2. 初始注册表内容。1810.2. 子命名空间注册urn:ietf:params:oauth:token-type:jwt。1910.2.1. 注册表内容。1910.3. 媒体类型注册。2010.3.1. 注册表内容。2010.4. 标题参数名称注册。2010.4.1. 注册表内容。2111.安全注意事项。2111.1条。信托决策。2111.2. 签名和加密顺序。2112.隐私考虑。2213.参考文献。2213.1条。规范性引用文件。2213.2. 参考文献。23Jones等人，标准跟踪[第3页]RFC 7519 JSON Web令牌（JWT）2015年5月附录A.JWT示例。26A.1、。加密JWT示例。26A.2。嵌套JWT示例。26附录B.JWT与SAML断言的关系。28附录C.JWT与简单Web令牌（SWT）的关系。28确认。28作者地址。291.简介JSON Web Token（JWT）是一种紧凑的声明表示格式适用于空间受限的环境，如HTTP授权标头和URI查询参数。JWT对索赔进行编码作为JSON[RFC7159]对象传输，该对象用作JSON Web签名（JWS）[JWS]结构的有效负载或作为JSON Web加密（JWE）[JWE]结构的明文，启用使用数字签名或完整性保护的声明消息验证码（MAC）和/或加密。JWT总是使用JWS Compact序列化或JWE Compact表示序列化。JWT的建议发音与英语单词相同“jot”。1.1. 符号约定关键词“必须”、“不得”、“必需”、“应”、“不应”、，“SHOULD”、“SHOUULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和本文件中的“可选”应解释为“RFC中用于指示需求级别的关键字”[RFC2119]。只有当术语出现在所有大写字母。2.术语术语“JSON Web签名（JWS）”、“Base64url编码”、“标头参数“，”JOSE头“，”JWS Compact Serialization“，”JWS有效负载”、“JWS签名”和“无担保JWS”由JWS定义规范[JWS]。术语“JSON Web加密（JWE）”、“内容加密密钥“（CEK）”、“JWE压缩序列化”、“JWE加密密钥”和“JWE初始化向量”由JWE规范[JWE]定义。术语“密文”、“数字签名”、“消息认证”“代码（MAC）”和“明文”由“互联网安全”定义词汇表，第2版“[RFC4949]。Jones等人标准轨道[第4页]RFC 7519 JSON Web令牌（JWT）2015年5月这些术语由本规范定义：JSON Web令牌（JWT）将一组声明表示为JSON对象的字符串编码在JWS或JWE中，使索赔能够数字化签名或MACed和/或加密。JWT索赔集包含JWT传递的声明的JSON对象。索赔关于一个主题的信息。索赔是表示为由Claim name和索赔价值。索赔名称索赔表示的名称部分。索赔名称是总是一个字符串。索赔金额索赔表示的价值部分。索赔值可以是任何JSON值。嵌套JWT使用嵌套签名和/或加密的JWT。在嵌套JWT，JWT用作分别封闭JWS或JWE结构。无担保JWT声明不受完整性保护或加密的JWT。防撞名称命名空间中的一个名称，允许在以使它们极不可能与其他物体碰撞名称。抗冲突名称空间的示例包括：域ITU-T X.660和X.670推荐系列和通用唯一标识符（UUID）[RFC4122]。使用管理委托时名称空间，名称的定义者需要采取合理的预防措施，以确保他们能够控制他们用来定义名称的命名空间。字符串或URIJSON字符串值，附加要求是可以使用任意字符串值，任何包含“：”的值字符必须是URI[RFC3986]。StringOrURI值为比较为不带转换的区分大小写字符串或应用了规范化。Jones等人，标准跟踪[第5页]RFC 7519 JSON Web令牌（JWT）2015年5月数字日期JSON数值，表示从1970-01-01T00:00:00Z UTC直到指定的UTC日期/时间，忽略闰秒。这相当于IEEE标准1003.1，2013年版[POSIX.1]定义“世纪以来的秒数”每天都有86400秒可以表示非整数值。参见RFC 3339[RFC3339]有关一般日期/时间和UTC的详细信息特别是。3.JSON Web Token（JWT）概述JWT将一组声明表示为JSON对象，该对象在JWS和/或JWE结构。此JSON对象是JWT声明集。根据RFC 7159[RFC7159]第4节，JSON对象包括零个或多个名称/值对（或成员），其中名称为字符串和值是任意JSON值。这些成员是JWT所代表的权利要求。此JSON对象可能包含任何JSON值前后的空格和/或换行符，或结构字符，符合RFC 7159第2节[RFC7159]。JWT Claims Set中的成员名称称为Claim姓名。相应的值称为Claim values。JOSE头的内容描述了加密操作适用于JWT索赔集合。如果JOSE标头用于JWS，则JWT表示为JWS，并且索赔经过数字签名或MACed，其中JWT索赔集是JWS有效载荷。如果JOSE标题表示JWE，JWT表示为JWE和索赔加密，JWT声明集为明文加密JWE。JWT可以封闭在另一个JWE或JWS结构中，以创建嵌套JWT，使嵌套签名和加密已执行。JWT表示为一系列URL安全部件，由句点（“.”）字符。每个部分都包含一个base64url编码值。JWT中的零件数量取决于使用JWS Compact表示结果JWS序列化或使用JWE压缩序列化的JWE。Jones等人，标准跟踪[第6页]RFC 7519 JSON Web令牌（JWT）2015年5月3.1. 示例JWT以下示例JOSE Header声明编码对象为JWT，JWT是使用HMAC SHA-256的MACed的JWS算法：{“典型”：“JWT”，“alg”：“HS256”｝消除JSON表示中的潜在歧义对象，实际UTF-8表示的八位字节序列本例中还包括上述JOSE标题如下所示。（请注意，由于平台不同，可能会产生歧义换行符的表示（CRLF与LF），在行的开头和结尾，最后一行是否有是否终止断线等原因。在在本例中使用的表示法，第一行没有前导或尾随空格，第一个字符之间出现CRLF换行符（13，10和第二行，第二行有一个前导空格（32），没有尾随空格，最后一行没有终止行中断。）表示JOSE的UTF-8表示的八位字节本例中的标头（使用JSON数组表示法）为：[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]对JOSE的UTF-8表示的八位字节进行Base64url编码标头生成此编码的JOSE标头值：eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9以下是JWT索赔集的示例：{“iss”：“joe”，“出口”：1300819380，"http://example.com/is_root“：true}以下八位字节序列是使用的UTF-8表示在上述JWT索赔集的示例中，是JWS有效载荷：[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,111, 116, 34, 58, 116, 114, 117, 101, 125]Jones等人，标准跟踪[第7页]RFC 7519 JSON Web令牌（JWT）2015年5月对JWS Payload进行Base64url编码会产生此编码的JWS Paiload（换行符仅用于显示目的）：eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly公司9leGFtcGxlLmNvbS9pc19yb290Ijp0nValfQ型计算编码JOSE报头和编码JWS有效负载的MAC使用HMAC SHA-256算法和base64url编码HMAC值以[JWS]中指定的方式生成此编码的JWS签名：dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk公司将这些编码部分按此顺序与句点（“.”）连接起来各部分之间的字符生成完整的JWT（带行仅用于显示目的的打断）：eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk公司该计算在[JWS]。有关加密JWT的示例，请参见附录A.1。4.JWT索赔JWT声明集表示一个JSON对象，其成员为JWT传达的索赔。JWT索赔集中的索赔名称必须是唯一的；JWT解析器必须拒绝重复的JWT声明名称或使用仅返回词法最后一个的JSON解析器重复的成员名称，如第15.12节（“JSONECMAScript 5.1[ECMAScript]的对象“）。JWT必须包含一组声明才能被视为有效上下文相关，不在本规范的范围内。JWT的具体应用需要实现以特定的方式理解和处理一些索赔。然而，在没有此类要求，所有不理解的主张必须忽略by实现。JWT索赔名称分为三类：注册索赔名称、，公共声明名称和私有声明名称。Jones等人，标准跟踪[第8页]RFC 7519 JSON Web令牌（JWT）2015年5月4.1. 注册索赔名称以下索赔名称在IANA“JSON Web令牌中注册根据第10.1条建立的索赔登记处。没有任何索赔以下定义旨在强制使用或实施案例，但它们为一组有用的，可互操作的声明。使用JWT的应用程序应定义他们使用的特定声明以及何时需要或可选。全部名字很短，因为JWT的核心目标是表示要紧凑。4.1.1. “iss”（发卡行）索赔“iss”（发行人）索赔确定了发行JWT公司。此索赔的处理通常是特定于应用程序的。“iss”值是包含StringOrURI的区分大小写的字符串值。此声明的使用是可选的。4.1.2. “sub”（主题）索赔“子”（主题）索赔确定的是JWT主题。JWT中的声明通常是声明关于主题。主题值的范围必须为发行人上下文中的本地唯一或全局唯一。此索赔的处理通常是特定于应用程序的。这个“sub”值是包含StringOrURI的区分大小写的字符串值。此声明的使用是可选的。4.1.3. “aud”（观众）索赔“aud”（受众）声明确定了JWT是用于。每个打算处理JWT MUST的负责人在观众诉求中确定自己的价值。如果委托人处理声明时不会使用如果出现“aud”索赔，则JWT必须拒绝。在一般情况下，“aud”值是一个case数组-敏感字符串，每个字符串都包含一个StringOrURI值。在特殊情况下，当JWT只有一个受众时，“aud”值可能是包含StringOrURI值的区分大小写的单个字符串。这个观众价值观的解释通常是特定于应用的。此声明的使用是可选的。4.1.4. “exp”（到期时间）索赔exp（过期时间）声明确定了或者在此之后，不得接受JWT进行处理。这个处理“exp”索赔要求当前日期/时间必须在“exp”索赔中列出的到期日期/时间之前。Jones等人，标准跟踪[第9页]RFC 7519 JSON Web令牌（JWT）2015年5月实施者可以提供一些较小的余地，通常不超过几分钟，以解释时钟偏差。其值必须是数字包含NumericDate值。使用此声明是可选的。4.1.5. “nbf”（非之前）索赔“nbf”（非之前）声明确定了JWT之前的时间不得接受处理。“nbf”的处理索赔要求当前日期/时间必须晚于或等于“nbf”索赔中列出的非提前日期/时间。实施者可能提供一些小的回旋余地，通常不超过几分钟解释了时钟偏差。其值必须是包含NumericDate值。此声明的使用是可选的。4.1.6. “iat”（签发时间）索赔“iat”（于发布）索赔确定了JWT发布。该声明可用于确定JWT的年龄。它值必须是包含NumericDate值的数字。这个的使用索赔是可选的。4.1.7. “jti”（JWT ID）索赔“jti”（JWT ID）声明为JWT提供了一个唯一的标识符。标识符值的分配方式必须确保相同值的概率可以忽略不计意外分配给不同的数据对象；如果应用程序使用多个颁发者，必须防止值之间的冲突由不同发行人制作。可以使用“jti”声明以防止重播JWT。“jti”值就是一个例子-敏感字符串。此声明的使用是可选的。4.2. 公共索赔名称使用JWT的用户可以随意定义索赔名称。然而，在为了防止冲突，任何新的Claim Name都应该是在IANA“JSON Web令牌声明”注册中心注册根据第10.1节或成为公共名称：包含防碰撞名称。在每种情况下，名称的定义者或价值观需要采取合理的预防措施以确保他们处于控制用于定义Claim的命名空间部分姓名。4.3. 私人索赔名称JWT的生产商和消费者可能同意使用索赔名称are Private Names：非注册索赔名称的名称（第4.1节）或公共索赔名称（第4.2节）。与公众不同Jones等人，标准跟踪[第10页]RFC 7519 JSON Web令牌（JWT）2015年5月索赔名称、私人索赔名称可能发生冲突，应小心使用。5.JOSE收割台对于JWT对象，JSON对象的成员由JOSE头描述应用于JWT的加密操作以及JWT的其他属性（可选）。取决于无论JWT是JWS还是JWE，JOSE的相应规则标题值适用。本规范进一步规定了以下标题的使用JWT是JWS和JWS是JWE公司。5.1. “typ”（类型）标题参数使用由[JWS]和[JWE]定义的“typ”（类型）标头参数由JWT应用程序声明的媒体类型[IANA.MediaTypes]这个完整的JWT。这是JWT应用程序使用的当应用程序中也可能存在非JWT的值时可以包含JWT对象的数据结构；应用程序可以使用此值用于消除不同类型对象之间的歧义可能存在。在以下情况下，应用程序通常不会使用它众所周知，该对象是JWT。此参数是JWT的实施方式忽略了这一点；此参数的任何处理都是由JWT应用程序执行。如果存在，建议其值为“JWT”，表示此对象是JWT。While期间媒体类型名称不区分大小写，建议使用“JWT”始终使用大写字符拼写，以便与兼容遗留实现。此标题参数的使用是可选的。5.2. “cty”（内容类型）标题参数由[JWS]和[JWE]定义的“cty”（内容类型）标头参数本规范用于传达有关JWT。在嵌套签名或加密操作的正常情况下不使用，则不使用此标题参数推荐。如果嵌套签名或加密采用时，此标题参数必须存在；在这种情况下值必须为“JWT”，以表示此中包含嵌套JWTJWT公司。虽然媒体类型名称不区分大小写，但它是建议始终使用大写字符拼写“JWT”以与传统实现兼容。参见附录A.2嵌套JWT的示例。Jones等人，标准跟踪[第11页]RFC 7519 JSON Web令牌（JWT）2015年5月5.3. 复制声明作为标题参数在一些使用加密JWT的应用程序中一些索赔的未加密表示。这可能用于实例，在应用程序处理规则中确定是否和如何在解密JWT之前处理它。本规范允许JWT索赔集中的索赔作为JWE的JWT中的头参数复制，根据需要应用程序。如果存在此类重复声明接收它们的应用程序应该验证它们的值相同，除非应用程序定义了其他特定处理这些索赔的规则。这是应用程序的责任确保只有在未加密的方式在JWT公司。本规范第10.4.1节注册了“iss”（发行人），的“sub”（主题）和“aud”（观众）标题参数名称目的是在为需要它们的应用程序加密JWT。其他规范也可以将其他注册为索赔名称的名称注册为标题参数名称（根据需要）。6.无担保JWT支持通过某种方式保护JWT内容的用例JWT中包含的签名和/或加密除外（例如包含JWT的数据结构上的签名）、JWT也可以在没有签名或加密的情况下创建。无担保JWT是一个JWS，使用“alg”头参数值“none”，并带有其JWS-Signature值的空字符串，如JWA中定义的规范[JWA]；它是具有JWT声明集的无担保JWS作为其JWS有效负载。6.1. 示例无担保JWT以下示例JOSE Header声明编码对象为无担保JWT：{“alg”：“无”}对JOSE的UTF-8表示的八位字节进行Base64url编码标头生成此编码的JOSE标头值：EybGciOi25lIn0年Jones等人，标准跟踪[第12页]RFC 7519 JSON Web令牌（JWT）2015年5月以下是JWT索赔集的示例：{“iss”：“joe”，“出口”：1300819380，"http://example.com/is_root“：true}对JWT的UTF-8表示的八位字节进行Base64url编码索赔集产生此编码JWS有效载荷（带有换行符仅用于显示目的）：eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ编码的JWS签名是空字符串。将这些编码部分按此顺序与句点（“.”）连接起来部件之间的字符生成完整的JWT（带行仅用于显示目的的打断）：eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.7.创建和验证JWT7.1. 创建JWT要创建JWT，请执行以下步骤。的顺序在没有依赖项的情况下，步骤并不重要在步骤的输入和输出之间。1.创建包含所需索赔的JWT索赔集。请注意表示中显式允许空白，并且不允许编码之前需要执行规范化。2.让消息是JWT索赔集。3.创建一个包含所需标题集的JOSE标题参数。JWT必须符合[JWS]或[JWE]规范。请注意，在之前不需要执行表示和规范化编码。Jones等人标准轨道[第13页]RFC 7519 JSON Web令牌（JWT）2015年5月4.根据JWT是JWS还是JWE，有两种案例：*如果JWT是JWS，则使用消息作为JWS创建JWS有效载荷；[JWS]中指定的创建JWS MUST的所有步骤请遵循。*否则，如果JWT是JWE，则使用消息创建JWEJWE的明文；[JWE]中规定的所有步骤必须遵循创建JWE。5.如果要执行嵌套签名或加密操作，将消息设为JWS或JWE，并使用新JOSE标题中“JWT”的“cty”（内容类型）值在该步骤中创建。6.否则，将结果JWT设为JWS或JWE。7.2. 验证JWT验证JWT时，将执行以下步骤。订单在没有步骤的输入和输出之间的依赖关系。如果有任何列出的步骤失败，则必须拒绝JWT，即，应用程序将其视为无效输入。1.验证JWT是否至少包含一个句点（“.”）字符。2.将编码的JOSE头作为JWT的一部分第一个句点（'.'）字符。3.Base64url根据无换行符、空白或其他附加限制字符已被使用。4.验证生成的八位字节序列是UTF-8编码的完全有效的JSON对象的表示，符合RFC 7159[RFC7159]；让JOSE头成为这个JSON对象。5.验证生成的JOSE Header仅包含参数以及语法和语义都被理解的值支持或指定为在不支持时忽略的理解。6.确定JWT是JWS还是JWE，使用[JWE]第9节中描述的方法。Jones等人，标准跟踪[第14页]RFC 7519 JSON Web令牌（JWT）2015年5月7.根据JWT是JWS还是JWE，有两种案例：*如果JWT是JWS，请按照[JWS]中为验证JWS。让消息成为base64url的结果对JWS有效载荷进行解码。*否则，如果JWT是JWE，请遵循中指定的步骤[JWE]用于验证JWE。让信息成为结果纯文本。8.如果JOSE标头包含的“cty”（内容类型）值为“JWT”，则消息是嵌套主题的JWT签名或加密操作。在这种情况下，返回步骤1，使用消息作为JWT。9.否则，base64url将在无换行符、空白或其他附加限制字符已被使用。10.验证生成的八位字节序列是UTF-8编码的表示完全有效的JSON对象，符合RFC 7159[RFC7159]；让JWT声明集成为这个JSON对象。最后，请注意，哪些算法可以在给定的上下文中使用。即使JWT能够成功验证，除非JWT中使用的算法可以接受则应拒绝JWT。7.3. 字符串比较规则处理JWT不可避免地需要将已知字符串与JSON对象中的成员和值。例如，在检查算法是，Unicode[Unicode]字符串编码“alg”将是对照JOSE标题中的成员名称检查是否存在是匹配的标头参数名称。中描述了用于进行成员名称比较的JSON规则RFC 7159[RFC7159]第8.3节。因为只有字符串比较执行的操作是等式和不等式，相同规则可用于比较成员名称和成员值针对已知字符串。这些比较规则必须用于所有JSON字符串比较除非成员的定义显式调用指出要对该成员使用不同的比较规则值。在本规范中，只有“typ”和“cty”成员值不要使用这些比较规则。Jones等人，标准跟踪[第15页]RFC 7519 JSON Web令牌（JWT）2015年5月一些应用程序可能在案例中包含区分大小写的信息-敏感值，例如将DNS名称作为“iss”的一部分（发行人）索赔价值。在这些情况下，应用程序可能需要定义用于表示的规范案例的约定大小写敏感的部分，如小写，如果大于一方可能需要产生相同的价值，以便相比。（然而，如果所有其他方消费任何价值制作方发出了逐字逐句的声音，但没有尝试将其与独立产生的价值，然后是生产者使用的案例无所谓。）8.实施要求本节定义了此操作的哪些算法和功能规范是必须实现的。使用此的应用程序规范可以对实现施加额外的要求他们使用的。例如，一个应用程序可能需要支持用于加密JWT和嵌套JWT，而另一个可能需要支持使用椭圆曲线数字签名对JWT进行签名使用P-256曲线和SHA-256散列的算法（ECDSA）算法（“ES256”）。JSON Web算法中指定的签名和MAC算法[JWA]，只有HMAC SHA-256（“HS256”）和“none”必须由实现符合JWT实施。建议：实现还支持带有SHA-256散列的RSASSA-PKCS1-v1_5算法（“RS256”）和ECDSA，使用P-256曲线和SHA-256散列算法（“ES256”）。支持其他算法和密钥大小可选。对加密JWT的支持是可选的。如果实现提供加密算法的加密功能在[JWA]中指定，仅RSAES-PKCS1-v1_5具有2048位密钥（“RSA1_5”），AES密钥包装，带有128位和256位密钥（“A128KW”和“A256KW”），以及使用AES-CBC和HMAC SHA-2（“A128CBC-HS256”和“A256CBC-HS512”）必须通过一致的实现来实现。建议：实现还支持使用椭圆曲线Diffie-Hellman临时静态（ECDH-ES）以商定用于包装内容加密密钥（“ECDH-ES+A128KW”和“ECDH-ES+A256KW”）和具有128位和256位密钥的伽罗瓦/计数器模式（GCM）AES（“A128GCM”和“A256GCM”）。支持其他算法和密钥尺寸可选。支持嵌套JWT是可选的。Jones等人，标准跟踪[第16页]RFC 7519 JSON Web令牌（JWT）2015年5月9.用于声明内容是JWT的URI本规范注册URN“urn:ietf:params:oauth:token-type:jwt”用于使用URI（而不是媒体）声明内容类型类型）以指示引用的内容是JWT。10.IANA注意事项10.1。JSON Web令牌声明注册表本节建立IANA“JSON Web令牌声明”注册表用于JWT索赔名称。注册表记录索赔名称和参考定义它的规范。本节注册第4.1节中定义的索赔名称。根据规范要求[RFC5226]注册值在对jwt-reg-review@ietf.org邮件列表，根据一名或多名指定专家的建议。然而，为了在发布之前分配价值，指定专家可以批准注册对将发布此类规范感到满意。发送到邮件列表供审查的注册请求应使用适当的主题（例如，“请求注册索赔：示例”）。在审查期间，指定专家将批准或拒绝注册请求，将此决定告知审查清单和IANA。拒绝应包括解释，如果适用，关于如何使请求成功的建议。超过以下时间段未确定的注册请求可以提请IESG注意21天（使用iesg@ietf.org邮件列表）进行解析。指定专家应采用的标准包括确定拟议注册是否与现有注册重复功能，无论它是否可能具有通用性或它是否仅对单个应用程序有用，以及注册描述清晰。IANA只能接受指定专家的注册更新并应将所有注册请求发送至审查邮件列表。建议任命多名指定专家能够使用本规范，以便对注册决定。如果登记决定可以Jones等人，标准跟踪[第17页]RFC 7519 JSON网络令牌（JWT）2015年5月被视为为特定的人制造利益冲突专家，该专家应服从其他专家的判断专家。10.1.1. 注册模板索赔名称：请求的名称（例如“iss”）。因为这是一个核心目标规范是为了使结果表示紧凑，建议名称简短，即不要超过8个字符，没有令人信服的理由。这个名称是区分大小写。名称可能与除非指定专家声明允许一个例外是有充分理由的。索赔说明：索赔的简要描述（例如，“发卡行”）。更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方名称。其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。规范文件：对指定参数的一个或多个文档的引用，最好包括可用于检索副本的URI文件。相关章节的指示也可以是包括但不是必需的。10.1.2. 初始注册表内容o索赔名称：“iss”o索赔说明：发卡行o变更控制器：IESGo规范文件：RFC 7519第4.1.1节o索赔名称：“sub”o索赔说明：主题o变更管理员：IESGo规范文件：RFC 7519第4.1.2节o索赔名称：“aud”o索赔说明：受众o变更控制器：IESGo规范文件：RFC 7519第4.1.3节Jones等人，标准轨道[第18页]RFC 7519 JSON Web令牌（JWT）2015年5月o索赔名称：“exp”o索赔说明：到期时间o变更控制器：IESGo规范文件：RFC 7519第4.1.4节o索赔名称：“nbf”o索赔说明：不早于o变更控制器：IESGo规范文件：RFC 7519第4.1.5节o索赔名称：“iat”o索赔说明：签发日期o变更控制器：IESGo规范文件：RFC 7519第4.1.6节o索赔名称：“jti”o索赔说明：JWT IDo变更控制器：IESGo规范文件：RFC 7519第4.1.7节10.2. 子命名空间注册urn:ietf:params:oauth:token-type:jwt10.2.1. 注册表内容本节在IANA“OAuth”中注册值“token-type:jwt”URI“由“OAuth的IETF URN子命名空间”建立的注册表”[RFC6755]，可用于指示内容是JWT。o URN:URN:ietf:params:oauth:token-type:jwto通用名称：JSON Web令牌（JWT）令牌类型o变更控制器：IESGo规范文件：RFC 7519Jones等人，《标准跟踪》[第19页]RFC 7519 JSON Web令牌（JWT）2015年5月第10.3条。媒体类型注册10.3.1. 注册表内容本节在中注册“application/jwt”媒体类型[RFC2046]“媒体类型”注册表[IANA.MediaTypes]在RFC 6838[RFC6838]中，可用于指示内容是JWT。o类型名称：应用o子类型名称：jwto所需参数：不适用o可选参数：不适用o编码注意事项：8位；JWT值编码为序列base64url编码值的字符串）由句点（“.”）字符分隔。o安全注意事项：请参阅“安全注意事项”部分RFC 7519的o互操作性注意事项：不适用o发布规范：RFC 7519o使用此媒体类型的应用程序：OpenID Connect、MozillaPersona、Salesforce、Google、Android、Windows Azure、Amazon Web服务和众多其他o片段标识符注意事项：不适用o其他信息：幻数：不适用文件扩展名：不适用Macintosh文件类型代码：不适用o联系人和电子邮件地址，以获取更多信息：迈克尔·琼斯，mbj@microsoft.como预期用途：通用o使用限制：无o作者：Michael B.Jones，mbj@microsoft.como变更控制器：IESGo临时注册？不10.4. 标题参数名称注册本节登记了第4.1节中定义的特定索赔名称IANA“JSON Web签名和加密头参数”由[JWS]建立的注册表，供复制为Header的索赔使用JWE中的参数，见第5.3节。Jones等人，标准跟踪[第20页]RFC 7519 JSON Web令牌（JWT）2015年5月10.4.1。注册表内容o标题参数名称：“iss”o标题参数说明：发卡行o标头参数使用位置：JWEo变更控制器：IESGo规范文件：RFC 7519第4.1.1节o标题参数名称：“sub”o标题参数说明：主题o表头参数使用位置：JWEo变更控制器：IESGo规范文件：RFC 7519第4.1.2节o标题参数名称：“aud”o标题参数说明：受众o标头参数使用位置：JWEo变更控制器：IESGo规范文件：RFC 7519第4.1.3节11.安全注意事项与任何加密相关的所有安全问题申请必须由JWT/JWS/JWE/JWK代理处理。其中包括问题是保护用户的非对称私有和对称密钥和针对各种攻击的对策。JWS规范中的所有安全注意事项也适用对于JWT，加密时的JWE安全注意事项雇佣。特别是第10.12节（“JSON安全注意事项”）和10.13（“Unicode比较安全性[JWS]的“注意事项”）同样适用于与JOSE Header相同。11.1. 信任决策信托决定不能依赖JWT的内容除非其内容已加密并绑定到信托决策所需的上下文。特别是用于签名和/或加密JWT的密钥通常需要可验证地处于确定为发行人的一方的控制之下JWT的。11.2. 签名和加密顺序在语法上，Nested的签名和加密操作如果签名和加密都是必要时，通常生产者应该签署消息，然后Jones等人，《标准跟踪》[第21页]RFC 7519 JSON Web令牌（JWT）2015年5月加密结果（从而加密签名）。这样可以防止攻击中，签名被剥离，只留下一个加密的消息，以及为签名者提供隐私。此外，加密文本上的签名在许多情况下被认为是无效的司法管辖区。请注意，与签名和加密操作的顺序已经由解决基本JWS和JWE规范；尤其是因为JWE仅支持使用经过身份验证的加密算法，密码技术对签名后的潜在需求的关注适用于许多上下文的加密不适用于此规范。12.隐私考虑JWT可能包含隐私敏感信息。当这是在这种情况下，必须采取措施防止泄露向非预期方提供信息。实现这一点的一种方法是使用加密的JWT并对收件人进行身份验证。另一种方法是确保JWT包含未加密的隐私敏感信息仅使用使用加密的协议传输支持端点身份验证，如传输层安全（TLS）。从JWT中省略隐私敏感信息是最大限度地减少隐私问题的最简单方法。13.参考文献13.1. 规范性引用文件[ECMAScript]Ecma International，“ECMAScript语言规范，5.1版”，ECMA标准2622011年6月，.[IANA.媒体类型]IANA，“媒体类型”，.[JWA]Jones，M.，“JSON Web算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月，.[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月，.Jones等人，标准跟踪[第22页]RFC 7519 JSON Web令牌（JWT）2015年5月[JWS]Jones，M.、Bradley，J.和N.Sakimura，“JSON Web签名（JWS）”，RFC 7515，DOI 10.17487/RFC，2015年5月，.[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月，.[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC20461996年11月，.[RFC2119]Bradner，S.，“RFC中使用的关键词需求级别”，BCP 14，RFC 2119，DOI 10.17487/RFC21192997年3月，.[RFC3986]Berners-Lee，T.、Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法“，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月，.[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC49492007年8月，.[RFC7159]Bray，T.，Ed.，“JavaScript对象符号（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，3月2014年，.[UNICODE]UNICODE联盟，“UNICODE标准”，.13.2. 资料性引用[画布应用程序]Facebook，“画布应用程序”，2010年，.[JSS]Bradley，J.和N.Sakimura（编辑），“JSON简单签名”，2010年9月，.Jones等人，《标准跟踪》[第23页]RFC 7519 JSON Web令牌（JWT）2015年5月[魔术签名]Panzer，J.，Ed.，Laurie，B.和D.Balfanz，“魔法签名”，2011年1月，.[OASIS.saml-core-2.0-os]坎托·S·、坎普·J·、菲尔波特·R·和E·马勒，“OASIS安全断言的断言和协议标记语言（SAML）V2.0”，OASIS标准saml-core-2.0-os，2005年3月，.[POSIX.1]IEEE，“开放组基本规范第7期”，IEEE标准1003.12013年版，2013年，.[RFC3275]Eastlake 3rd，D.、Reagle，J.和D.Solo，“（可扩展标记语言）XML-Signature语法和处理“，RFC 3275，DOI 10.17487/RFC3275，2002年3月，.[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC33392002年7月，.[RFC4122]Leach，P.、Mealling，M.和R.Salz，“普遍性唯一标识符（UUID）URN命名空间“，RFC 4122，DOI 10.17487/RFC41222005年7月，.[RFC5226]Narten，T.和H.Alvestrand，“编写RFC中的IANA考虑部分”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月，.[RFC6755]Campbell，B.和H.Tschofenig，“IETF URN子命名空间对于OAuth”，RFC 6755，DOI 10.17487/RFC6755，2012年10月，.[RFC6838]Freed，N.、Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月，.Jones等人，标准跟踪[第24页]RFC 7519 JSON Web令牌（JWT）2015年5月[SWT]Hardt，D.和Y.Goland，“简单网络令牌（SWT）”，版本2009年11月0.9.5.1日，.[W3C.CR-xml11-20060816]Cowan，J.，“可扩展标记语言（XML）1.1（第二版版本）”，万维网联盟建议REC-xml11-20060816，2006年8月，.[W3C.REC-xml-c14n-20010315]Boyer，J.，“规范XML版本1.0”，万维网联合体建议REC-xml-c14n-20010315，3月2001,.Jones等人标准轨道[第25页]RFC 7519 JSON Web令牌（JWT）2015年5月附录A.JWT示例本节包含JWT的示例。有关其他JWT示例，请参见本文件第6.1节和[JWS]附录A.1-A.3。A.1。加密JWT示例该示例对第3.1节中使用的相同权利要求进行加密收件人使用RSAES-PKCS1-v1_5和AES_128_CBC_HMAC_SHA_256。以下示例JOSE Header声明：o使用RSAES-PKCS1-v1_5算法生成JWE加密密钥。o使用AES_128_CBC_HMAC_SHA_256算法生成JWE密码以及JWE认证标签。{“alg”：“RSA1_5”，“enc”：“A128CBC-HS256”}除了使用JWT的UTF-8表示的八位字节第3.1节中的权利要求集作为明文值，计算此JWT的计算与中JWE的计算相同[JWE]的附录A.2，包括使用的钥匙。本例中的最终结果（带有换行符以供显示仅用于）是：eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0。QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM公司oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG公司TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDzjAD26ima公司sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52YCitxoQVPzjbl7WBuB7AOhdBoZOdZ24WlN11VIIeh8v1K4krB8xgKvRU8kgFrEn_a1rZgN5TiysnmzTROF869lQ公司。AxY8DCtDaGlsbGljb3RoZQ。MKOle7UQrG6nSxTLX6Mqwt0或HvAKeWnDYvpIAeZ72deHxz3roJDXQyhxxx0wKaMHDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8。fiK51VwhsxJ-siBMR-YFiAA.2、。嵌套JWT示例此示例显示了如何将JWT用作JWE或JWS创建嵌套JWT。在这种情况下，JWT索赔集是先签名，然后加密。Jones等人，标准跟踪[第26页]RFC 7519 JSON Web令牌（JWT）2015年5月内部签名JWT与附录A.2中的示例相同[JWS]。因此，此处不再重复其计算。这个然后，使用RSAES-PKCS1-v1_5和AES_128_CBC_HMAC_SHA_256。以下示例JOSE Header声明：o使用RSAES-PKCS1-v1_5算法生成JWE加密密钥。o使用AES_128_CBC_HMAC_SHA_256算法生成JWE密码和JWE身份验证标签。o明文本身就是JWT。{“alg”：“RSA1_5”，“enc”：“A128CBC-HS256”，“cty”：“JWT”}对JOSE的UTF-8表示的八位字节进行Base64url编码标头生成此编码的JOSE标头值：eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0此JWT的计算与[JWE]附录A.2中的JWE，不同的JOSE标题除外，明文、JWE初始化向量和内容加密密钥使用值。（使用的RSA密钥相同。）使用的明文是ASCII[RFC20]表示的八位字节JWS]附录A.2.1末尾的JWT（所有空白删除换行符），这是458个八位字节的序列。使用的JWE初始化向量值（使用JSON数组表示法）是：[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,50]此示例使用由base64url编码值如下：GawgguFyGrWKav7AX4VKUg公司Jones等人，标准跟踪[第27页]RFC 7519 JSON Web令牌（JWT）2015年5月此嵌套JWT的最终结果（带换行符以便显示仅用于）是：eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldU输入0。g_hEwksO1Ax8Qn7HoN-BVeBoa8FXe0kpyk_XdcSmxvcM5_P296JXX到HISr_DD_MqewaQSH4dZOQHoUgKLeFly-9RI11TG-_Ge1bZFazBPwKC5lJ6OLANLMd0QSL4fYEb9ERe-epKYE3xb2jfY1AltHqBO-PM6j23Guj2yDKnFv6WO72tteVzm_2n17SBFvhDuR9a2nHTE67pe0XGBUS_TK7ecA-iVq5COeVdJR4U4VZGGlxRGPLRHvolVLEHx6DYyLpw30Ay9R6d68YCLi9FYTq3hIXPK_-dmPloulKvPr1GJzRoeC9G5qCvdcHWSq公司JGTO_z3适用于5zsqwkxruxwA。UmVkbW9uZCBXQSA5ODA1Mg。VwHERHPvCNcHHpTjkoigx3_ExK0Qc71RME商标0X_qpg-w8kozSjfNIPPXiTBBLXR65CIPkFqz4l1Ae9w_uowKiwyi9acgVztAi-pSL8GQSXnaamh9kX1mdh3M_TT型-FZGQFQsFhu0Z72gJKGdfGE-OE7hS1zuBD5oEUfk0Dmb0VzWEzpxxiSSBbBAzP10l56pPfAtrjEYw-7ygeMkwBl6Z_mLS6w6xUgKlvW6ULmkV-uLC4FUiyKECK4e3WZYKw1bpgIqGYsw2v_grHjszJZ-_I5uM-9RA8ycX9KqPRp9gc6pXmoU_-27ATs9XCvrZXUtK2902AUzqpeEUJYjWWxSNsS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb28Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe_nNJgNliWtWpJ_ebuOpEl8jdhehdcnRMIwAmU1n7SPkmhIl1HlSOpvcvDfhUN5wuqU955vOBvfkBOh5A11UzBuo2WlgZ6hYi9-e3w29bR0C2-pp3jbqxEDw3iWaf2dc5b-LnR0FEYXvI_tYk5rd型_J9N0mg0tQ6RbpxNEMNoA9QWk5lgdPvbh9BaO195abQ。AVO9iT5AV4CvDJCdhSFlQ型附录B.JWT与SAML断言的关系安全断言标记语言（SAML）2.0[OASIS.saml-core-2.0-os]提供了创建安全性的标准具有比由JWT支持。然而，这种灵活性和表现力既是规模又是复杂性。SAML对XML的使用[W3C.CR-xml11-20060816]和XML数字签名（DSIG）[RFC3275]影响SAML断言的大小；它使用XML和特别是XML规范化[W3C.REC-XML-c14n-20010315]导致了它们的复杂性。JWT旨在提供一种简单的安全令牌格式足够小，可以放入URI中的HTTP标头和查询参数。它通过支持比SAML更简单的令牌模型和使用JSON[RFC7159]对象编码语法。它还支持使用消息验证码（MAC）和数字保护令牌使用比XMLDSIG更小（且不太灵活）的格式的签名。因此，虽然JWT可以做SAML断言所做的一些事情，JWT并不打算完全替代SAML断言，但而不是作为易于实现或紧凑性是需要考虑的因素。Jones等人，标准跟踪[第28页]RFC 7519 JSON网络令牌（JWT）2015年5月SAML断言总是由实体对主题。JWT通常与实体以相同的方式使用作出“iss”（发行人）声明所代表的声明，以及“子”（主题）权利要求所代表的主题。然而，由于这些声明是可选的，JWT的其他用途也允许使用格式。附录C.JWT与简单Web令牌（SWT）的关系JWT和SWT[SWT]的核心都使一组索赔能够在应用程序之间进行通信。对于SWT，两个索赔名称和声明值是字符串。对于JWT，索赔名称为字符串，声明值可以是任何JSON类型。两种令牌类型都提供内容的加密保护：带有HMAC SHA-256和可选择算法的JWT，包括签名、MAC和加密算法。致谢作者承认JWT的设计是有意的受SWT的设计和简单性以及Dick Hardt在OpenID社区中讨论的JSON令牌。Magic之前探讨了签署JSON内容的解决方案签名[MagicSignatures]、JSON简单签名[JSS]和画布应用程序[CanvasApp]，所有这些都影响了本文档。本规范是OAuth工作组的工作，该工作组包括数十名积极且专注的参与者。特别地，以下人员提供了想法、反馈和措辞影响本规范的因素：德克·巴尔范兹、理查德·巴恩斯、布莱恩·坎贝尔、艾莉莎·库珀、布伦诺·德梅德罗斯、斯蒂芬·法雷尔、亚龙·Y·戈兰、迪克·哈德、乔希尔德布兰德、杰夫·霍奇斯、埃德蒙·杰伊、沃伦·库马里、本·劳里、巴里Leiba、Ted Lemon、James Manger、Prateek Mishra、Kathleen Moriarty、，托尼·纳达林（Tony Nadalin）、阿克塞尔·内克尔（Axel Nennker）、约翰·帕泽尔（John Panzer）、伊曼纽尔·拉维亚特（Emmanuel Raviart）、大卫（David）Recordon、Eric Rescorla、Jim Schaad、Paul Tarjan、Hannes Tschofenig、，肖恩·特纳和汤姆·余。Hannes Tschofenig和Derek Atkins担任OAuth工作组主席Sean Turner、Stephen Farrell和Kathleen Moriarty担任创建本规范期间的安全区域控制器。Jones等人，标准跟踪[第29页]RFC 7519 JSON Web令牌（JWT）2015年5月作者地址迈克尔·琼斯微软电子邮件：mbj@microsoft.comURI（URI）：http://self-issued.info/约翰·布拉得利Ping标识电子邮件：ve7jtb@ve7jtc.comURI（URI）：http://www.thread-safe.com/Nat Sakimura公司野村综合研究所电子邮件：n-sakimura@nri.co.jpURI（URI）：http://nat.sakimura.org/Jones等人，标准跟踪[第30页]