idnits 2.17.1 draft-ietf-oauth-jwsreq-05.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 (July 22, 2015) is 3191 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 610, 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: January 23, 2016 Ping Identity 6 July 22, 2015 8 OAuth 2.0 JWT Authorization Request 9 draft-ietf-oauth-jwsreq-05 11 Abstract 13 The authorization request in OAuth 2.0 utilizes query parameter 14 serialization. This specification defines the authorization request 15 using JWT serialization. The request is sent through "request" 16 parameter or by reference through "request_uri" parameter that points 17 to the JWT, allowing the request to be optionally signed and 18 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 January 23, 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 . . . . . 10 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 . . . . . . . . 11 70 6. Authorization Server Response . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 a good evidence of the approver. 97 2. The request may be encrypted so that end-to-end confidentiality 98 may be obtained even if in the case TLS connection is terminated 99 at a gateway or a similar device. 101 3. The request may be signed by a third party attesting that the 102 authorization request is compliant to certain policy. For 103 example, a request can be pre-examined by a third party that all 104 the personal data requested is strictly necessary to perform the 105 process that the end-user asked for, and statically signed by 106 that third party. The client would then send the request along 107 with dynamic parameters such as state. The authorization server 108 then examines the signature and show the end-user the conformance 109 status to the end-user, who would have some assurance as to the 110 legitimacy of the request when authorizing it. In some cases, it 111 may even be desirable to skip the authorization dialogue under 112 such circumstances. 114 There are a few cases that request by reference are useful such as: 116 1. When it is detected that the User Agent does not support long 117 URLs: Some extensions may extend the URL. For example, the 118 client might want to send a public key with the request. 120 2. Static signature: The client can make a signed Request Object and 121 put it at a place that the Authorization Server can access. This 122 may just be done by a client utility or other process, so that 123 the private key does not have to reside on the client, 124 simplifying programming. 126 3. When the server wants the requests to be cacheable: The 127 request_uri may include a SHA-256 hash of the file, as defined in 128 FIPS180-2 [FIPS180-2], the server knows if the file has changed 129 without fetching it, so it does not have to re-fetch a same file, 130 which is a win as well. 132 4. When the client wants to simplify the implementation without 133 compromising the security. If the request parameters go through 134 the browser, they may be tampered in the browser even if TLS was 135 used. This implies we need to have signature on the request as 136 well. However, if HTTPS "request_uri" was used, it is not going 137 to be tampered, thus we now do not have to sign the request. 138 This simplifies the implementation. 140 This capability is in use by OpenID Connect [OpenID.Core]. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. Terminology 150 For the purposes of this specification, the following terms and 151 definitions apply. 153 2.1. Request Object 155 JWT [RFC7519] that holds an OAuth 2.0 authorization request as JWT 156 Claims Set 158 2.2. Request Object URI 160 Absolute URI from which the Request Object (Section 2.1) can be 161 obtained 163 3. Request Object 165 A Request Object (Section 2.1) is used to provide authorization 166 request parameters for an OAuth 2.0 authorization request. It 167 contains OAuth 2.0 [RFC6749] authorization request parameters 168 including extension parameters. It is a JSON Web Signature (JWS) 169 [RFC7515] signed JWT [RFC7519] . The parameters are represented as 170 the JWT claims. Parameter names and string values MUST be included 171 as JSON strings. Numerical values MUST be included as JSON numbers. 172 It MAY include any extension parameters. This JSON [RFC7159] 173 constitutes the JWT [RFC7519] Claims Set. 175 The Request Object MAY be signed or be an Unsecured JWS. When it is 176 an unsecured JWS, this is indicated by use of the "none" algorithm 177 JWA [RFC7518] in the JWS header. If signed, the Authorization 178 Request Object SHOULD contain the Claims "iss" (issuer) and "aud" 179 (audience) as members, with their semantics being the same as defined 180 in the JWT [RFC7519] specification. 182 The Request Object MAY also be encrypted using JWE [RFC7516] and MAY 183 be encrypted without also being signed. If both signing and 184 encryption are performed, it MUST be signed then encrypted, with the 185 result being a Nested JWT, as defined in JWT [RFC7519]. 187 The Authorization Request Object MAY alternatively be sent by 188 reference using the "request_uri" parameter. 190 REQUIRED OAuth 2.0 Authorization Request parameters that are not 191 included in the Request Object MUST be sent as a query parameter. If 192 a required parameter is not present in neither the query parameter 193 nor the Request Object, it forms a malformed request. 195 "request" and "request_uri" parameters MUST NOT be included in 196 Request Objects. 198 If the parameter exists in both the query string and the 199 Authorization Request Object, the values in the Request Object takes 200 precedence. This means that if it intends to use a cached request 201 object, it cannot include such parameters like "state" that is 202 expected to differ in every request. It is fine to include them in 203 the request object if it is going to be prepared afresh every time. 205 The following is a non-normative example of the Claims in a Request 206 Object before base64url encoding and signing. Note that it includes 207 extension variables such as "nonce", "userinfo", and "id_token". 209 { 210 "iss": "s6BhdRkqt3", 211 "aud": "https://server.example.com", 212 "response_type": "code id_token", 213 "client_id": "s6BhdRkqt3", 214 "redirect_uri": "https://client.example.org/cb", 215 "scope": "openid", 216 "state": "af0ifjsldkj", 217 "nonce": "n-0S6_WzA2Mj", 218 "max_age": 86400, 219 "claims": 220 { 221 "userinfo": 222 { 223 "given_name": {"essential": true}, 224 "nickname": null, 225 "email": {"essential": true}, 226 "email_verified": {"essential": true}, 227 "picture": null 228 }, 229 "id_token": 230 { 231 "gender": null, 232 "birthdate": {"essential": true}, 233 "acr": {"values": ["urn:mace:incommon:iap:silver"]} 234 } 235 } 236 } 238 Signing it with the "RS256" algorithm results in this Request Object 239 value (with line wraps within values for display purposes only): 241 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 242 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 243 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 244 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 245 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 246 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 247 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 248 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 249 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 250 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 251 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 252 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 253 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 254 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 255 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 256 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 257 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 258 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 259 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 261 The following RSA public key, represented in JWK format, can be used 262 to validate the Request Object signature in this and subsequent 263 Request Object examples (with line wraps within values for display 264 purposes only): 266 { 267 "kty":"RSA", 268 "kid":"k2bdc", 269 "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P 270 7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF 271 I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa 272 ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR 273 adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV 274 W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", 275 "e":"AQAB" 276 } 278 4. Authorization Request 280 The client constructs the authorization request URI by adding the 281 following parameters to the query component of the authorization 282 endpoint URI using the "application/x-www-form-urlencoded" format: 284 request REQUIRED unless "request_uri" is specified. The Request 285 Object (Section 3) that holds authorization request parameters 286 stated in the section 4 of OAuth 2.0 [RFC6749]. 288 request_uri REQUIRED unless "request" is specified. The absolute 289 URL that points to the Request Object (Section 3) that holds 290 authorization request parameters stated in the section 4 of OAuth 291 2.0 [RFC6749]. 293 state RECOMMENDED. OAuth 2.0 [RFC6749] state. 295 The client directs the resource owner to the constructed URI using an 296 HTTP redirection response, or by other means available to it via the 297 user-agent. 299 For example, the client directs the end-user's user-agent to make the 300 following HTTPS request (line breaks are for display purposes only): 302 GET /authorize?request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 303 Host: server.example.com 305 The authorization request object MAY be signed AND/OR encrypted. 307 When the "request" parameter is used, the OAuth 2.0 request parameter 308 values contained in the JWT supersede those passed using the OAuth 309 2.0 request syntax. However, parameters MAY also be passed using the 310 OAuth 2.0 request syntax even when a Request Object is used; this 311 would typically be done to enable a cached, pre-signed (and possibly 312 pre-encrypted) Request Object value to be used containing the fixed 313 request parameters, while parameters that can vary with each request, 314 such as state and nonce, are passed as OAuth 2.0 parameters. 316 4.1. Passing a Request Object by Value 318 The Client sends the Authorization Request as a Request Object to the 319 Authorization Endpoint as the "request" parameter value. 321 The following is a non-normative example of an Authorization Request 322 using the "request" parameter (with line wraps within values for 323 display purposes only): 325 https://server.example.com/authorize? 326 response_type=code%20id_token 327 &client_id=s6BhdRkqt3 328 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 329 &scope=openid 330 &state=af0ifjsldkj 331 &nonce=n-0S6_WzA2Mj 332 &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA 333 iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN 334 vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV 335 udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8 336 vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA 337 ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo 338 iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN 339 lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw 340 iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo 341 geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ 342 lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw 343 NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo 344 gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN 345 yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0 346 NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H 347 h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2 348 GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC 349 UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz 350 jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il 351 zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 353 4.2. Passing a Request Object by Reference 355 The "request_uri" Authorization Request parameter enables OAuth 356 authorization requests to be passed by reference, rather than by 357 value. This parameter is used identically to the "request" 358 parameter, other than that the Request Object value is retrieved from 359 the resource at the specified URL, rather than passed by value. 361 When the "request_uri" parameter is used, the OAuth 2.0 authorization 362 request parameter values contained in the referenced JWT supersede 363 those passed using the OAuth 2.0 request syntax. However, parameters 364 MAY also be passed using the OAuth 2.0 request syntax even when a 365 "request_uri" is used; this would typically be done to enable a 366 cached, pre-signed (and possibly pre-encrypted) Request Object value 367 to be used containing the fixed request parameters, while parameters 368 that can vary with each request, such as "state" and "nonce", are 369 passed as OAuth 2.0 parameters. 371 Servers MAY cache the contents of the resources referenced by Request 372 URIs. If the contents of the referenced resource could ever change, 373 the URI SHOULD include the base64url encoded SHA-256 hash as defined 374 in FIPS180-2 [FIPS180-2] of the referenced resource contents as the 375 fragment component of the URI. If the fragment value used for a URI 376 changes, that signals the server that any cached value for that URI 377 with the old fragment value is no longer valid. 379 The entire Request URI MUST NOT exceed 512 ASCII characters. 381 The contents of the resource referenced by the URL MUST be a Request 382 Object. The scheme used in the "request_uri" value MUST be "https", 383 unless the target Request Object is signed in a way that is 384 verifiable by the Authorization Server. The "request_uri" value MUST 385 be reachable by the Authorization Server, and SHOULD be reachable by 386 the Client. 388 The following is a non-normative example of the contents of a Request 389 Object resource that can be referenced by a "request_uri" (with line 390 wraps within values for display purposes only): 392 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 393 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 394 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 395 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 396 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 397 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 398 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 399 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 400 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 401 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 402 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 403 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 404 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 405 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 406 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 407 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 408 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 409 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 410 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 412 4.2.1. URL Referencing the Request Object 414 The Client stores the Request Object resource either locally or 415 remotely at a URL the Server can access. This URL is the Request 416 URI, "request_uri". 418 If the Request Object includes requested values for Claims, it MUST 419 NOT be revealed to anybody but the Authorization Server. As such, 420 the "request_uri" MUST have appropriate entropy for its lifetime. It 421 is RECOMMENDED that it be removed if it is known that it will not be 422 used again or after a reasonable timeout unless access control 423 measures are taken. 425 The following is a non-normative example of a Request URI value (with 426 line wraps within values for display purposes only): 428 https://client.example.org/request.jwt# 429 GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 431 4.2.2. Request using the "request_uri" Request Parameter 433 The Client sends the Authorization Request to the Authorization 434 Endpoint. 436 The following is a non-normative example of an Authorization Request 437 using the "request_uri" parameter (with line wraps within values for 438 display purposes only): 440 https://server.example.com/authorize? 441 response_type=code%20id_token 442 &client_id=s6BhdRkqt3 443 &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt 444 %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 445 &state=af0ifjsldkj 447 4.2.3. Authorization Server Fetches Request Object 449 Upon receipt of the Request, the Authorization Server MUST send an 450 HTTP "GET" request to the "request_uri" to retrieve the referenced 451 Request Object, unless it is already cached, and parse it to recreate 452 the Authorization Request parameters. 454 Note that the client SHOULD use a unique URI for each request 455 utilizing distinct parameters, or otherwise prevent the Authorization 456 Server from caching the "request_uri". 458 The following is a non-normative example of this fetch process: 460 GET /request.jwt HTTP/1.1 461 Host: client.example.org 463 5. Validating JWT-Based Requests 465 5.1. Encrypted Request Object 467 The Authorization Server MUST decrypt the JWT in accordance with the 468 JSON Web Encryption [RFC7516] specification. The result MAY be 469 either a signed or unsigned (plaintext) Request Object. In the 470 former case, signature validation MUST be performed as defined in 471 Section 5.2. 473 The Authorization Server MUST return an error if decryption fails. 475 5.2. Signed Request Object 477 To perform Signature Validation, the "alg" Header Parameter in the 478 JOSE Header MUST match the value of the "request_object_signing_alg" 479 set during Client Registration or a value that was pre-registered by 480 other means. The signature MUST be validated against the appropriate 481 key for that "client_id" and algorithm. 483 The Authorization Server MUST return an error if signature validation 484 fails. 486 5.3. Request Parameter Assembly and Validation 488 The Authorization Server MUST assemble the set of Authorization 489 Request parameters to be used from the Request Object value and the 490 OAuth 2.0 Authorization Request parameters (minus the "request" or 491 "request_uri" parameters). If the same parameter exists both in the 492 Request Object and the OAuth Authorization Request parameters, the 493 parameter in the Request Object is used. Using the assembled set of 494 Authorization Request parameters, the Authorization Server then 495 validates the request as specified in OAuth 2.0 [RFC6749]. 497 6. Authorization Server Response 499 Authorization Server Response is created and sent to the client as in 500 Section 4 of OAuth 2.0 [RFC6749] . 502 In addition, this document defines additional error values as 503 follows: 505 invalid_request_uri The "request_uri" in the Authorization Request 506 returns an error or contains invalid data. 508 invalid_request_object The request parameter contains an invalid 509 Request Object. 511 request_not_supported The Authorization Server does not support the 512 use of the "request" parameter. 514 request_uri_not_supported The Authorization Server does not support 515 use of the "request_uri" parameter. 517 7. IANA Considerations 519 The request_object_signing_alg OAuth Dynamic Client Registration 520 Metadata is pending registration by OpenID Connect Dynamic 521 Registration specification. 523 8. Security Considerations 525 In addition to the all the security considerations discussed in OAuth 526 2.0 [RFC6819], the following security considerations SHOULD be taken 527 into account. 529 When sending the authorization request object through "request" 530 parameter, it SHOULD be signed with then considered appropriate 531 algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such 532 a case. 534 If the request object contains personally identifiable or sensitive 535 information, the "request_uri" MUST be of one-time use and MUST have 536 large enough entropy deemed necessary with applicable security 537 policy. For higher security requirement, using [RFC7516] is strongly 538 recommended. 540 9. Acknowledgements 542 Follwoing people contributed to the creation of this document in 543 OAuth WG. 545 John Bradley (Ping Identity), Michael B. Jones (Microsoft), Nat 546 Sakimura (NRI), (add yourself). 548 Following people contributed to creating this document through the 549 OpenID Connect 1.0 [OpenID.Core]. 551 Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley ( Ping 552 Identity) , Nat Sakimura (NRI) , Ryo Itou 553 (Yahoo! Japan), George Fletcher (AOL), Justin Richer (MITRE), Edmund 554 Jay (Illumila), Michael B. Jones (Microsoft), (add yourself). 556 In addition following people contributed to this and previous 557 versions through The OAuth Working Group. 559 David Recordon (Facebook), Luke Shepard (Facebook), James H. Manger 560 (Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk 561 Balfanz (Google), (add yourself). 563 10. Revision History 565 -05 567 o More alignment with OpenID Connect. 569 -04 571 o Fixed typos in examples. (request_url -> request_uri, cliend_id -> 572 client_id) 574 o Aligned the error messages with the OAuth IANA registry. 576 o Added another rationale for having request object. 578 -03 580 o Fixed the non-normative description about the advantage of static 581 signature. 583 o Changed the requirement for the parameter values in the request 584 itself and the request object from 'MUST MATCH" to 'Req Obj takes 585 precedence. 587 -02 589 o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. 591 -01 593 o Copy Edits. 595 11. References 596 11.1. Normative References 598 [FIPS180-2] 599 U.S. Department of Commerce and National Institute of 600 Standards and Technology, "Secure Hash Signature 601 Standard", FIPS 180-2, August 2002. 603 Defines Secure Hash Algorithm 256 (SHA256) 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 611 (TLS) Protocol Version 1.2", RFC 5246, 612 DOI 10.17487/RFC5246, August 2008, 613 . 615 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 616 RFC 6749, DOI 10.17487/RFC6749, October 2012, 617 . 619 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 620 Threat Model and Security Considerations", RFC 6819, 621 DOI 10.17487/RFC6819, January 2013, 622 . 624 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 625 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 626 2014, . 628 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 629 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 630 2015, . 632 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 633 RFC 7516, DOI 10.17487/RFC7516, May 2015, 634 . 636 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 637 DOI 10.17487/RFC7518, May 2015, 638 . 640 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 641 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 642 . 644 11.2. Informative References 646 [OpenID.Core] 647 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 648 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 650 Authors' Addresses 652 Nat Sakimura (editor) 653 Nomura Research Institute 654 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 655 Chiyoda-ku, Tokyo 100-0005 656 Japan 658 Phone: +81-3-5533-2111 659 Email: n-sakimura@nri.co.jp 660 URI: http://nat.sakimura.org/ 662 John Bradley 663 Ping Identity 664 Casilla 177, Sucursal Talagante 665 Talagante, RM 666 Chile 668 Phone: +44 20 8133 3718 669 Email: ve7jtb@ve7jtb.com 670 URI: http://www.thread-safe.com/