Passing parameters through JWT in a request to /authorize

Security Verify Access OIDC Providers support passing request parameters by way of a JWT in a request to /authorize.

The support satisfies the requirements in Section 6.1 of the OpenID Connect Core specification https://openid.net/specs/openid-connect-core-1_0.html.

Deployments such as web banking applications require integration with strong authentication as offered by a third party. This scenario requires that clients avoid providing claims directly in a query string. By sending the claims in a JSON Web Token (JWT), the client proves that it signed them with an established secret. ISAM supports this function by providing decryption of OIDC ID tokens that are received with the authorization code grant flow from a third-party OpenID Provider. The received tokens are signed (for example, by presenting a JWT that uses the JWS algorithm RS256) and encrypted (for example, by use of the content encryption algorithm AES128CBC-HS256 and key agreement algorithm of RSA-OEAP). See https://tools.ietf.org/html/rfc7518.

A request JWT can be used to provide incoming request parameters. The specification requires the OAuth request parameters must still contain client_id and response_type, but all other parameters, such as redirect_uri, and scope, can be provided only in the request JWT. The client_id and response_type can also be presented in the request JWT, but the values of each must match those that are provided in the OAuth request parameters.

To configure an STS chain that is compatible with incoming JWT request parameters, the chain must meet the same requirements as required for handling client assertions:

1. No token type is set.
2. RequestType of Validate is accepted.

Examples of ISSUER and APPLIESTO fields that handle all presented client assertions are as follows:

ISSUER="REGEXP:(urn:ibm:ITFIM:oauth20:client_request:.*)"
APPLIESTO=https://localhost/sps/oauth/oauth20

In the example above, all clients match with this chain. (Note the .* value in the regexp for the Issuer.) If a particular chain is needed, then use the issuer:urn:ietf:params:oauth:client-assertion-type:jwt-bearer:myClient where myClient is the client_id of the interested client.

• The APPLIESTO is the federation ID.
• The ISSUER must be the string "urn:ibm:ITFIM:oauth20:client_request:", and the clientId that is included in the request.

The claims are mapped into the request. Validation occurs on request_type and client_id, as required by the specification:

• Validating JWT-based Requests

  When the request authorization parameter is used, the JWT is passed to the auxiliary chain, and the returned claims are mapped back into the request STSUU. The response type of the auxiliary chain must be STSUU. If signature validation fails, the request is rejected.

• Request Parameter Assembly and Validation

  The Authorization Server must assemble the set of Authorization Request parameters to be used from the Request Object value and the OAuth 2.0 Authorization Request parameters (minus the request parameters). If the same parameter exists both in the Request Object and the OAuth Authorization Request parameters, the parameter in the Request Object is used. Using the assembled set of Authorization Request parameters, the Authorization Server then validates the request in the normal manner for the flow being used.

Parent topic: OAuth 2.0 and OIDC support