Both OAuth and OpenID Connect give you an opportunity to use Request Objects to initiate a flow. When a request is sent this way, all the parameters which would normally be present in the query string, are encoded in a JWT. You can read more about this technique in the Request Objects article. This tutorial presents the configuration of the Curity Identity Server required to use Request Objects.
Make sure that you’re running the Curity Identity Server in version 6.3.0 or later. If running a clean instance of the Curity Identity Server, make sure to configure it at least with the basic configuration.
To enable support for Request Objects, in the admin UI, go to Profiles -> Token Service -> General and select the tab Request Object JWT Support. Enabling this feature allows clients to send Request Objects in the authorization request. You can require clients to use Request Objects through a client setting (see below).
In this section you can also allow clients to sign Request Objects with an asymmetrical key and limit the algorithms which can be used for signing. You can also add claims which will be required in the Request Object. The Curity Identity Server requires the request to have at least
response_type claims. Other authorization request parameters aren’t required to be present in the request JWT, unless they’re added to the list in the configuration.
aud claim value
If the Request Object contains the
aud claim, then it must have the value of the Curity Identity Server’s issuer.
If you want to allow clients to use unsigned JWTs as Request Objects, then the Asymmetrically Signed JWT option must be enabled, and the algorithm
none added to the list of allowed algorithms. Remember though that allowing clients to send unsigned JWTs does not protect from request tampering.
Once the Request Object support is enabled in the system, it can be enabled for concrete clients. To do that, go to Profiles -> Token Service -> Clients and edit the client for which you want to enable JAR support. Scroll down to Client Application Settings and open the Advanced tab. Enable the option Request Object JWT Support.
Either a signature verification key must be selected, or the option Allow Unsigned for By-value enabled. The signature verification key is the key that will be used to verify the incoming request JWT’s signature. This can either be a public key or a symmetric secret key. The key can be added in the Facilities -> Crypto -> Signature Verification Keys tab.
By default, if the
iss claim is present in the request, it must have the value of the client ID. You can override the value which should be required in the
iss claim by entering your own value in the Issuer field.
If you require a client to use Proof-Key for Code Exchange, then PKCE will be enforced even if you don’t require the Request Object to contain
code_challenge_method claims. On the other hand, if you require these claims in the Request Object, then PKCE will effectively be required, even if the client has the Require Proof Key option disabled. This is because the Curity Identity Server will expect the token request to contain
code_verifier, because the authorization request contained a
If you want to allow a client to send By-reference Request Objects (through the
request_uri parameter), you can enable the option By reference in the client’s Request Objects settings.
To properly handle Request Objects sent by reference, an HTTP client must be provided. It will be used to fetch the Request Object. Also, the URL from which the Request Object will be downloaded from, must be whitelisted, in order to avoid any abuses of this mechanism. You can use a wildcard character to allow any URL (
*), or you can use the wildcard character at the end of the URL, so that requests can have dynamic paths. For example, if a Request Object would be reachable with the URL
https://example.com/request-jwts/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM, then use the value
To test the flow you will first need to create a JWT containing request parameters needed to initialize the authorization flow. You can do that using OAuth.tools with the Create JWT Flow. In the JWT creation form, in the body section add at least the claims
redirect_uri. You will have to add any other claims that you marked as mandatory in the Curity Identity Server. At the bottom, choose the signing algorithm
RS256 and click on Generate Key. Remember to enable this algorithm in the Curity Identity Server.
Take the generated public key and add it in your Curity Identity Server as a Signature Verification Key, then configure your client to use this key to verify incoming Request Objects.
Next click at the button Create JWT, and copy the resulting JWT.
In a browser start the authorization flow by navigating to:
idsvr.example.com/authorize points to the authorization endpoint of your instance of the Curity Identity Server and
clientID is the ID of the client used to perform authorization.
client_id in the request
client_id is present in the query string, not in the Request Object. This is because the OAuth specification requires the parameter
client_id to be present in the query string. You can include that parameter also in the Request Object. If you do, then the Curity Identity Server will validate if these two values match - the client ID from the query string and from the Request Object.
If you need to protect the privacy of authorization request parameters, then one way is to use encrypted JWTs (JWE) as Request Objects. The Curity Identity Server supports JWE, but to enable a client to use them in an authorization request you will need to edit the configuration using CLI or RESTConf. Currently, it can’t be set using the admin UI.
To enable support for encrypted Request Objects for a client, follow these steps. First, enter the configuration CLI by typing in your shell:
Next, set these three settings, by typing these commands
set profiles profile token-service oauth-service settings authorization-server request-object encrypted-jwt allowed-algorithms RSA-OAEP set profiles profile token-service oauth-service settings authorization-server request-object encrypted-jwt allowed-content-encryption-algorithms A256CBC-HS512 set profiles profile token-service oauth-service settings authorization-server request-object encrypted-jwt decryption-key decryptionKeyID
Remember to change the
token-service name in path, if your Token Profile has a different name. Set the
decryptionKeyID to an ID of a private key used for decryption. This key can be added in the admin UI, in Facilities -> Crypto -> Decryption keys. Adjust the allowed key encryption algorithms and allowed content encryption algorithms accordingly to what will be used by your client.
Commit the changes by calling the
commit command and exit the shell. You can now use encrypted JWTs as Request Objects.
The encrypted JWT used as a Request Object should be a nested JWT. This means than in the JWE header there should be a claim
cty with value
jwt, and the payload of the JWE should be the signed JWT containing the request parameters.
Using signed Request Objects can help you in situations, where request parameters get too large to send them in the query string or where there is a need of guarding the consistency of request parameters. Where you also need to safeguard privacy, Request Objects can additionally be encrypted. These functionalities will prove useful especially in setups which require high levels of security, such as financial-grade APIs. With the Curity Identity Server you can easily implement solutions which use Request Objects.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.