idnits 2.17.1 draft-ietf-oauth-jwsreq-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5246' is defined on line 628, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-2' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group N. Sakimura, Ed. 3 Internet-Draft Nomura Research Institute 4 Intended status: Standards Track J. Bradley 5 Expires: April 16, 2016 Ping Identity 6 October 14, 2015 8 OAuth 2.0 JWT Authorization Request 9 draft-ietf-oauth-jwsreq-06 11 Abstract 13 The authorization request in RFC6749 utilizes query parameter 14 serialization. This specification defines the authorization request 15 using JWT serialization. The request is sent by value through 16 "request" parameter or by reference through "request_uri" parameter 17 that points to the JWT, allowing the request to be optionally signed 18 and encrypted. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 16, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 4 59 3. Request Object . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Passing a Request Object by Value . . . . . . . . . . . . 7 62 4.2. Passing a Request Object by Reference . . . . . . . . . . 8 63 4.2.1. URL Referencing the Request Object . . . . . . . . . 10 64 4.2.2. Request using the "request_uri" Request Parameter . . 10 65 4.2.3. Authorization Server Fetches Request Object . . . . . 11 66 5. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 11 67 5.1. Encrypted Request Object . . . . . . . . . . . . . . . . 11 68 5.2. Signed Request Object . . . . . . . . . . . . . . . . . . 11 69 5.3. Request Parameter Assembly and Validation . . . . . . . . 12 70 6. Authorization Server Response . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 11.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 The parameters "request" and "request_uri" are introduced as 83 additional authorization request parameters for the OAuth 2.0 84 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) 85 [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 86 authorization request parameters. The JWT [RFC7519] can be passed to 87 the authorization endpoint by reference, in which case the parameter 88 "request_uri" is used instead of the "request". 90 Using JWT [RFC7519] as the request encoding instead of query 91 parameters has several advantages: 93 1. The request can be signed so that an integrity check can be 94 implemented. If a suitable algorithm is used for the signing, 95 then it will provide verification of the client making the 96 request. 98 2. The request may be encrypted so that end-to-end confidentiality 99 may be obtained even if in the case TLS connection is terminated 100 at a gateway or a similar device. 102 3. The request may be signed by a third party attesting that the 103 authorization request is compliant to certain policy. For 104 example, a request can be pre-examined by a third party that all 105 the personal data requested is strictly necessary to perform the 106 process that the end-user asked for, and statically signed by 107 that third party. The client would then send the request along 108 with dynamic parameters such as state. The authorization server 109 then examines the signature and show the conformance status to 110 the end-user, who would have some assurance as to the legitimacy 111 of the request when authorizing it. In some cases, it may even 112 be desirable to skip the authorization dialogue under such 113 circumstances. 115 There are a few cases that request by reference are useful such as: 117 1. When it is detected that the User Agent does not support long 118 URLs: Some extensions may extend the URL. For example, the 119 client might want to send a public key with the request. 121 2. Static signature: The client can make a signed Request Object and 122 put it at a place that the Authorization Server can access. This 123 may just be done by a client utility or other process, so that 124 the private key does not have to reside on the client, 125 simplifying programming. 127 3. When the server wants the requests to be cacheable: The 128 request_uri may include a SHA-256 hash of the file, as defined in 129 FIPS180-2 [FIPS180-2], the server knows if the file has changed 130 without fetching it, so it does not have to re-fetch a same file, 131 which is a win as well. 133 4. When the client wants to simplify the implementation without 134 compromising the security. If the request parameters go through 135 the browser, they may be tampered in the browser even if TLS was 136 used. This implies we need to have signature on the request as 137 well. However, if HTTPS "request_uri" was used, it is not going 138 to be tampered, thus we now do not have to sign the request. 139 This simplifies the implementation. 141 This capability is in use by OpenID Connect [OpenID.Core]. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2. Terminology 151 For the purposes of this specification, the following terms and 152 definitions apply. 154 2.1. Request Object 156 JWT [RFC7519] that holds an OAuth 2.0 authorization request as JWT 157 Claims Set 159 2.2. Request Object URI 161 Absolute URI from which the Request Object (Section 2.1) can be 162 obtained 164 3. Request Object 166 A Request Object (Section 2.1) is used to provide authorization 167 request parameters for an OAuth 2.0 authorization request. It 168 contains OAuth 2.0 [RFC6749] authorization request parameters 169 including extension parameters. It is a JSON Web Signature (JWS) 170 [RFC7515] signed JWT [RFC7519] . The parameters are represented as 171 the JWT claims. Parameter names and string values MUST be included 172 as JSON strings. Numerical values MUST be included as JSON numbers. 173 It MAY include any extension parameters. This JSON [RFC7159] 174 constitutes the JWT [RFC7519] Claims Set. 176 The Request Object MAY be signed or be an Unsecured JWS. When it is 177 an unsecured JWS, this is indicated by use of the "none" algorithm 178 JWA [RFC7518] in the JWS header. If signed, the Authorization 179 Request Object SHOULD contain the Claims "iss" (issuer) and "aud" 180 (audience) as members, with their semantics being the same as defined 181 in the JWT [RFC7519] specification. 183 The Request Object MAY also be encrypted using JWE [RFC7516] and MAY 184 be encrypted without also being signed. If both signing and 185 encryption are performed, it MUST be signed then encrypted, with the 186 result being a Nested JWT, as defined in JWT [RFC7519]. 188 The Authorization Request Object MAY alternatively be sent by 189 reference using the "request_uri" parameter. 191 REQUIRED OAuth 2.0 Authorization Request parameters that are not 192 included in the Request Object MUST be sent as a query parameter. If 193 a required parameter is not present in neither the query parameter 194 nor the Request Object, it forms a malformed request. 196 "request" and "request_uri" parameters MUST NOT be included in 197 Request Objects. 199 If the parameter exists in both the query string and the 200 Authorization Request Object, the values in the Request Object takes 201 precedence. This means that if it intends to use a cached request 202 object, it cannot include such parameters like "state" that is 203 expected to differ in every request. It is fine to include them in 204 the request object if it is going to be prepared afresh every time. 206 The following is a non-normative example of the Claims in a Request 207 Object before base64url encoding and signing. Note that it includes 208 extension variables such as "nonce", "userinfo", and "id_token". 210 { 211 "iss": "s6BhdRkqt3", 212 "aud": "https://server.example.com", 213 "response_type": "code id_token", 214 "client_id": "s6BhdRkqt3", 215 "redirect_uri": "https://client.example.org/cb", 216 "scope": "openid", 217 "state": "af0ifjsldkj", 218 "nonce": "n-0S6_WzA2Mj", 219 "max_age": 86400, 220 "claims": 221 { 222 "userinfo": 223 { 224 "given_name": {"essential": true}, 225 "nickname": null, 226 "email": {"essential": true}, 227 "email_verified": {"essential": true}, 228 "picture": null 229 }, 230 "id_token": 231 { 232 "gender": null, 233 "birthdate": {"essential": true}, 234 "acr": {"values": ["urn:mace:incommon:iap:silver"]} 235 } 236 } 237 } 239 Signing it with the "RS256" algorithm results in this Request Object 240 value (with line wraps within values for display purposes only): 242 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 243 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 244 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 245 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 246 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 247 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 248 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 249 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 250 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 251 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 252 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 253 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 254 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 255 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 256 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 257 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 258 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 259 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 260 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 262 The following RSA public key, represented in JWK format, can be used 263 to validate the Request Object signature in this and subsequent 264 Request Object examples (with line wraps within values for display 265 purposes only): 267 { 268 "kty":"RSA", 269 "kid":"k2bdc", 270 "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P 271 7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF 272 I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa 273 ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR 274 adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV 275 W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", 276 "e":"AQAB" 277 } 279 4. Authorization Request 281 The client constructs the authorization request URI by adding the 282 following parameters to the query component of the authorization 283 endpoint URI using the "application/x-www-form-urlencoded" format: 285 request REQUIRED unless "request_uri" is specified. The Request 286 Object (Section 3) that holds authorization request parameters 287 stated in the section 4 of OAuth 2.0 [RFC6749]. 289 request_uri REQUIRED unless "request" is specified. The absolute 290 URL that points to the Request Object (Section 3) that holds 291 authorization request parameters stated in the section 4 of OAuth 292 2.0 [RFC6749]. 294 state RECOMMENDED. OAuth 2.0 [RFC6749] state. 296 The client directs the resource owner to the constructed URI using an 297 HTTP redirection response, or by other means available to it via the 298 user-agent. 300 For example, the client directs the end-user's user-agent to make the 301 following HTTPS request (line breaks are for display purposes only): 303 GET /authorize?request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 304 Host: server.example.com 306 The authorization request object MAY be signed AND/OR encrypted. 308 When the "request" parameter is used, the OAuth 2.0 request parameter 309 values contained in the JWT supersede those passed using the OAuth 310 2.0 request syntax. However, parameters MAY also be passed using the 311 OAuth 2.0 request syntax even when a Request Object is used; this 312 would typically be done to enable a cached, pre-signed (and possibly 313 pre-encrypted) Request Object value to be used containing the fixed 314 request parameters, while parameters that can vary with each request, 315 such as state and nonce, are passed as OAuth 2.0 parameters. 317 4.1. Passing a Request Object by Value 319 The Client sends the Authorization Request as a Request Object to the 320 Authorization Endpoint as the "request" parameter value. 322 The following is a non-normative example of an Authorization Request 323 using the "request" parameter (with line wraps within values for 324 display purposes only): 326 https://server.example.com/authorize? 327 response_type=code%20id_token 328 &client_id=s6BhdRkqt3 329 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 330 &scope=openid 331 &state=af0ifjsldkj 332 &nonce=n-0S6_WzA2Mj 333 &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA 334 iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN 335 vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV 336 udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8 337 vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA 338 ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo 339 iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN 340 lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw 341 iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo 342 geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ 343 lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw 344 NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo 345 gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN 346 yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0 347 NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H 348 h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2 349 GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC 350 UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz 351 jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il 352 zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 354 4.2. Passing a Request Object by Reference 356 The "request_uri" Authorization Request parameter enables OAuth 357 authorization requests to be passed by reference, rather than by 358 value. This parameter is used identically to the "request" 359 parameter, other than that the Request Object value is retrieved from 360 the resource at the specified URL, rather than passed by value. 362 When the "request_uri" parameter is used, the OAuth 2.0 authorization 363 request parameter values contained in the referenced JWT supersede 364 those passed using the OAuth 2.0 request syntax. However, parameters 365 MAY also be passed using the OAuth 2.0 request syntax even when a 366 "request_uri" is used; this would typically be done to enable a 367 cached, pre-signed (and possibly pre-encrypted) Request Object value 368 to be used containing the fixed request parameters, while parameters 369 that can vary with each request, such as "state" and "nonce", are 370 passed as OAuth 2.0 parameters. 372 Servers MAY cache the contents of the resources referenced by Request 373 URIs. If the contents of the referenced resource could ever change, 374 the URI SHOULD include the base64url encoded SHA-256 hash as defined 375 in FIPS180-2 [FIPS180-2] of the referenced resource contents as the 376 fragment component of the URI. If the fragment value used for a URI 377 changes, that signals the server that any cached value for that URI 378 with the old fragment value is no longer valid. 380 The entire Request URI MUST NOT exceed 512 ASCII characters. There 381 are three reasons for this restriction. 383 1. Many WAP / feature phones do not accept large payloads. The 384 restriction are typically either 512 or 1024 ASCII characters. 386 2. The maximum URL length supported by Internet Explorer is 2083 387 ASCII characters. 389 3. On a slow connection such as 2G mobile connection, a large URL 390 would cause the slow response and using such is not advisable 391 from the user experience point of view. 393 The contents of the resource referenced by the URL MUST be a Request 394 Object. The scheme used in the "request_uri" value MUST be "https", 395 unless the target Request Object is signed in a way that is 396 verifiable by the Authorization Server. The "request_uri" value MUST 397 be reachable by the Authorization Server, and SHOULD be reachable by 398 the Client. 400 The following is a non-normative example of the contents of a Request 401 Object resource that can be referenced by a "request_uri" (with line 402 wraps within values for display purposes only): 404 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 405 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 406 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 407 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 408 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 409 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 410 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 411 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 412 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 413 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 414 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 415 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 416 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 417 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 418 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 419 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 420 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 421 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 422 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 424 4.2.1. URL Referencing the Request Object 426 The Client stores the Request Object resource either locally or 427 remotely at a URL the Server can access. This URL is the Request 428 URI, "request_uri". 430 If the Request Object includes requested values for Claims, it MUST 431 NOT be revealed to anybody but the Authorization Server. As such, 432 the "request_uri" MUST have appropriate entropy for its lifetime. It 433 is RECOMMENDED that it be removed if it is known that it will not be 434 used again or after a reasonable timeout unless access control 435 measures are taken. 437 The following is a non-normative example of a Request URI value (with 438 line wraps within values for display purposes only): 440 https://client.example.org/request.jwt# 441 GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 443 4.2.2. Request using the "request_uri" Request Parameter 445 The Client sends the Authorization Request to the Authorization 446 Endpoint. 448 The following is a non-normative example of an Authorization Request 449 using the "request_uri" parameter (with line wraps within values for 450 display purposes only): 452 https://server.example.com/authorize? 453 response_type=code%20id_token 454 &client_id=s6BhdRkqt3 455 &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt 456 %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 457 &state=af0ifjsldkj 459 4.2.3. Authorization Server Fetches Request Object 461 Upon receipt of the Request, the Authorization Server MUST send an 462 HTTP "GET" request to the "request_uri" to retrieve the referenced 463 Request Object, unless it is already cached, and parse it to recreate 464 the Authorization Request parameters. 466 Note that the client SHOULD use a unique URI for each request 467 utilizing distinct parameters, or otherwise prevent the Authorization 468 Server from caching the "request_uri". 470 The following is a non-normative example of this fetch process: 472 GET /request.jwt HTTP/1.1 473 Host: client.example.org 475 5. Validating JWT-Based Requests 477 5.1. Encrypted Request Object 479 The Authorization Server MUST decrypt the JWT in accordance with the 480 JSON Web Encryption [RFC7516] specification. The result MAY be 481 either a signed or unsigned (plaintext) Request Object. In the 482 former case, signature validation MUST be performed as defined in 483 Section 5.2. 485 The Authorization Server MUST return an error if decryption fails. 487 5.2. Signed Request Object 489 To perform Signature Validation, the "alg" Header Parameter in the 490 JOSE Header MUST match the value of the "request_object_signing_alg" 491 set during Client Registration or a value that was pre-registered by 492 other means. The signature MUST be validated against the appropriate 493 key for that "client_id" and algorithm. 495 The Authorization Server MUST return an error if signature validation 496 fails. 498 5.3. Request Parameter Assembly and Validation 500 The Authorization Server MUST assemble the set of Authorization 501 Request parameters to be used from the Request Object value and the 502 OAuth 2.0 Authorization Request parameters (minus the "request" or 503 "request_uri" parameters). If the same parameter exists both in the 504 Request Object and the OAuth Authorization Request parameters, the 505 parameter in the Request Object is used. Using the assembled set of 506 Authorization Request parameters, the Authorization Server then 507 validates the request as specified in OAuth 2.0 [RFC6749]. 509 6. Authorization Server Response 511 Authorization Server Response is created and sent to the client as in 512 Section 4 of OAuth 2.0 [RFC6749] . 514 In addition, this document defines additional error values as 515 follows: 517 invalid_request_uri The "request_uri" in the Authorization Request 518 returns an error or contains invalid data. 520 invalid_request_object The request parameter contains an invalid 521 Request Object. 523 request_not_supported The Authorization Server does not support the 524 use of the "request" parameter. 526 request_uri_not_supported The Authorization Server does not support 527 use of the "request_uri" parameter. 529 7. IANA Considerations 531 The request_object_signing_alg OAuth Dynamic Client Registration 532 Metadata is pending registration by OpenID Connect Dynamic 533 Registration specification. 535 8. Security Considerations 537 In addition to the all the security considerations discussed in OAuth 538 2.0 [RFC6819], the following security considerations SHOULD be taken 539 into account. 541 When sending the authorization request object through "request" 542 parameter, it SHOULD be signed with then considered appropriate 543 algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such 544 a case. 546 If the request object contains personally identifiable or sensitive 547 information, the "request_uri" MUST be of one-time use and MUST have 548 large enough entropy deemed necessary with applicable security 549 policy. For higher security requirement, using [RFC7516] is strongly 550 recommended. 552 9. Acknowledgements 554 Follwoing people contributed to the creation of this document in 555 OAuth WG. 557 Michael B. Jones (Microsoft), Axel Nenker(DT), Sergey Beryozkin, Jim 558 Manico, (add yourself). 560 Following people contributed to creating this document through the 561 OpenID Connect 1.0 [OpenID.Core]. 563 Breno de Medeiros (Google), Hideki Nara (TACT), Ryo Itou (Yahoo! 564 Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund Jay 565 (Illumila), Michael B. Jones (Microsoft), (add yourself). 567 In addition following people contributed to this and previous 568 versions through The OAuth Working Group. 570 David Recordon (Facebook), Luke Shepard (Facebook), James H. Manger 571 (Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk 572 Balfanz (Google), (add yourself). 574 10. Revision History 576 -06 578 o Added explanation on the 512 chars URL restriction. 580 o Updated Acknowledgements. 582 -05 584 o More alignment with OpenID Connect. 586 -04 588 o Fixed typos in examples. (request_url -> request_uri, cliend_id -> 589 client_id) 591 o Aligned the error messages with the OAuth IANA registry. 593 o Added another rationale for having request object. 595 -03 597 o Fixed the non-normative description about the advantage of static 598 signature. 600 o Changed the requirement for the parameter values in the request 601 itself and the request object from 'MUST MATCH" to 'Req Obj takes 602 precedence. 604 -02 606 o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. 608 -01 610 o Copy Edits. 612 11. References 614 11.1. Normative References 616 [FIPS180-2] 617 U.S. Department of Commerce and National Institute of 618 Standards and Technology, "Secure Hash Signature 619 Standard", FIPS 180-2, August 2002. 621 Defines Secure Hash Algorithm 256 (SHA256) 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 629 (TLS) Protocol Version 1.2", RFC 5246, 630 DOI 10.17487/RFC5246, August 2008, 631 . 633 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 634 RFC 6749, DOI 10.17487/RFC6749, October 2012, 635 . 637 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 638 Threat Model and Security Considerations", RFC 6819, 639 DOI 10.17487/RFC6819, January 2013, 640 . 642 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 643 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 644 2014, . 646 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 647 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 648 2015, . 650 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 651 RFC 7516, DOI 10.17487/RFC7516, May 2015, 652 . 654 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 655 DOI 10.17487/RFC7518, May 2015, 656 . 658 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 659 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 660 . 662 11.2. Informative References 664 [OpenID.Core] 665 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 666 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 668 Authors' Addresses 670 Nat Sakimura (editor) 671 Nomura Research Institute 672 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 673 Chiyoda-ku, Tokyo 100-0005 674 Japan 676 Phone: +81-3-5533-2111 677 Email: n-sakimura@nri.co.jp 678 URI: http://nat.sakimura.org/ 679 John Bradley 680 Ping Identity 681 Casilla 177, Sucursal Talagante 682 Talagante, RM 683 Chile 685 Phone: +44 20 8133 3718 686 Email: ve7jtb@ve7jtb.com 687 URI: http://www.thread-safe.com/