Request Object Support

1. Request Object by Value (as request parameter)

• The request authorization request parameter enables OpenID Connect requests to be passed in a single, self-contained parameter and has to be optionally signed and/or encrypted. It represents the request as a JWT whose claims are the request parameters. This JWT is called a Request Object.

• IS-5.5.0 has inbuilt support for passing Request Object by value.

  
  

2. Request Object by Reference (as request_uri parameter )

• The request_uri authorization request parameter enables OpenID Connect requests to be passed by reference, rather than by value. This parameter is used identically to the request parameter, other than that the Request Object value is retrieved from the resource at the specified URL.

• WSO2 Identity Server 5.5.0 does not support passing Request Object by Reference. However, an extension point is provided which can be extended to provide support for understanding Request Object from reference URI specified by request_uri.

  
  

https://localhost:9443/oauth2/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
    iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN
    vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV
    udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8
    vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA
    ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo
    iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN
    lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw
    iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo
    geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ
    lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw
    NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo
    gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN
    yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
    NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
    h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
    GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
    UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
    jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
    zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

The payload of the above sample Request Object is as follows:

{
  "iss": "s6BhdRkqt3",
  "aud": "https://server.example.com",
  "response_type": "code id_token",
  "client_id": "s6BhdRkqt3",
  "redirect_uri": "https://client.example.org/cb",
  "scope": "openid",
  "state": "af0ifjsldkj",
  "nonce": "n-0S6_WzA2Mj",
  "max_age": 86400,
  "claims": {
    "userinfo": {
      "given_name": {
        "essential": true
      },
      "nickname": null,
      "email": {
        "essential": true
      },
      "email_verified": {
        "essential": true
      },
      "picture": null
    },
    "id_token": {
      "gender": null,
      "birthdate": {
        "essential": true
      },
      "acr": {
        "values": [
          "urn:mace:incommon:iap:silver"
        ]
      }
    }
  }
}

If the above request is sent, it requests some claims from both the members userinfo endpoint and id_token. For example, 'given_name' and 'email' are marked as essential claims from user info endpoint and 'brithdate' is requested as an essential claim from id token. 

Usually, in OpenID Connect, the returning claims will be filtered from the requested scopes that are passed to the server as a query parameter with the authorization request. When it comes to WSO2 Identity Server, it filters the requested claims both from the requested scopes defined with the authorization request and the requested claims that can be configured in service provider configurations. But if the Request Object is associated with the authorization request, the server returns the essential request object claims in the response of userinfo endpoint and id_token accordingly.

1. The client_id and response_type of the request object (if present) should be equal to the client_id and the response_type of the authorization request.
2. The authorization request query parameters will be overridden from the Request Object values if they are present in the Request Object.
3. Both the request and request_uri parameters cannot be associated with the same authorization request.
4. Even if a scope parameter is present in the Request Object value, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate the underlying OAuth 2.0 logic that this is an OpenID Connect request. (For further validation information, refer OIDC specification)
   
   

Signature Validation

Decryption

 <OpenIDConnect>
  <RequestObjectBuilders>
     <RequestObjectBuilder>
        <Type>request_param_value_builder</Type>
  		<ClassName>org.wso2.carbon.identity.openidconnect.RequestParamRequestObjectBuilder</ClassName>
     </RequestObjectBuilder>
  </RequestObjectBuilders>
  <RequestObjectValidator>org.wso2.carbon.identity.openidconnect.RequestObjectValidatorImpl</RequestObjectValidator>
  </OpenIDConnect>

 <OpenIDConnect>
  <RequestObjectBuilders>
   ....
  <RequestObjectBuilder>
     <Type>request_uri_param_value_builder</Type>
     <ClassName>xxx.CustomRequestObjectBuilder</ClassName>
  </RequestObjectBuilder>
  ...
  </OpenIDConnect>