Financial-grade Security

The Curity Identity Server supports a number of features and functionality that allows administrators and developers to setup financial-grade API security that follows the OAuth working group’s and OpenID Foundation’s specifications, including the Financial-grade API (FAPI) profile of OpenID Connect. It also supports protocols and specifications that lend themselves to advanced security scenarios defined by other working groups (like the Brazilian Open Banking association). Some of these are described in this section of the manual.

JWT Secured Authorization Request (JAR)

The Curity Identity Server supports the client to send request parameters in a JSON Web Token (JWT), which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained based on JWT secured authorization requests specification and the OpenID Connect core specification.

The request can be sent by value using request parameter or by reference using the request_uri parameter. The supported signing and encryption algorithms are exposed in metadata endpoint

The metadata also has require_signed_request_object that tells if a client must use a signed request object. This can be configured in the server by allowing asymmetric signing algorithm for request objects and not having none as one of the supported signing algorithm. Additionally, which signing algorithms, encryption algorithms, and content key encryption ciphers are allowed is also published in the metadata. This facilitates Dynamic Client Registration.

Pushed Authorization Requests

Clients can use pushed requests as defined in pushed authorization request specification The endpoint used for pushing requests is always the configured authorization endpoint with a /par suffix.

A client with the code flow can always use PAR. All clients in a particular profile can be required to use PAR initiate the code flow. This is not the default. To change this, configure the setting require-pushed-authorization-requests in the client capabilities of the profile. In a XML configuration, the presence of <require-pushed-authorization-requests> would mean this setting is enabled and all clients must use PAR.

It is also possible to allow clients that require PAR to send per-request redirect URIs. When this is enabled, a client can push an authorization request where the redirect_uri parameter is valid if its origin (i.e. scheme://host:port) matches one of the redirect URIs that is configured for the client. This allows for variations in the path of the redirect_uri, as long as there is a match based on the origin. This can be set in client capabilities page of profile configuration or by setting <allow-per-request-redirect-uris>true</allow-per-request-redirect-uris> under <require-pushed-authorization-requests> element in XML configuration.

Request Object Handling

Request parameters can be passed as by-value or by-reference request object claims for a variety of reasons including additional security and integrity protection.

Request Object JWT Support in Token Service Profile, when enabled, provides a variety of settings that can be configured.

Configuration Description
Asymmetrically Signed JWT Enables asymmetrically signed request objects
Signature Algorithm Set of algorithms that is allowed for signing request objects
Maximum Lifetime The maximum time (from the nbf claims to the exp claim) that a request object should be valid for
Required Claim The list of claims that must be inside the request object
Encrypted JWT Keys and algorithms that can used for encryption as defined in JWE settings
Request Object Parameter Handling How claims in request objects and (form or query string) parameters are combined

When enabling request object support in the admin UI, the wizard helps choose a pre-defined combination of configurations suitable for different needs:

  • Standards Compliant - Comply with OpenID connect core specification
  • More Secure But Still Easy to Implement Compliant - Comply with financial-grade standards (i.e., FAPI)
  • Very Secure - Adhere to FAPI and requires PAR
  • Other - Customizable individually

The following configuration is used to resolve parameters when they are found in both request object and query or form parameters.

Configuration Description
merge-outside-parameters-preferring-inside Merge the claims in the request object with the request parameters, preferring the ones in the request object. This is the normal OpenID Connect behavior.
ignore-outside-parameters Ignore any (form or query string) parameters (except client ID) that are outside the request object
error-if-outside-parameters Reject any request that includes (form or query string) parameters (besides client ID) outside of the request object. This is the normal PAR/JAR behavior.
must-be-inside-and-match-if-outside Reject any request if (form or query string) parameters are given and they differ from the claims in the request object. This is the normal FAPI 1 behavior.

The following is an example configuration of request objects:

Listing 160 Example configuration of a request object
    <request-object>
      <asymmetrically-signed-jwt>
        <signature-algorithm>PS256</signature-algorithm>
        <signature-algorithm>PS384</signature-algorithm>
        <signature-algorithm>PS512</signature-algorithm>
        <signature-algorithm>ES256</signature-algorithm>
        <signature-algorithm>ES384</signature-algorithm>
        <signature-algorithm>ES512</signature-algorithm>
      </asymmetrically-signed-jwt>
      <maximum-lifetime>60</maximum-lifetime>
      <required-claim>exp</required-claim>
      <required-claim>nbf</required-claim>
      <request-object-parameter-handling>must-be-inside-and-match-if-outside</request-object-parameter-handling>
    </request-object>

JWT Security Authorization Response Mode (JARM)

The Curity Identity Server supports the protection of authorization response messages according to the JWT Secured Authorization Response Mode (JARM) specification, namely the following secure response modes: query.jwt, fragment.jwt, form_post.jwt, and jwt.

When one of these secure response modes is defined in an authorization request, the associated authorization response message will be encoded inside a JWT. This JWT will be signed using the profile’s default token issuer, as long as JWT issuance is enabled on that issuer. Note that this is always true if OIDC support is enabled in the profile. There aren’t any additional configuration settings required to support JARM, other than having JWT issuance configured on the default token issuer.

The cryptographic settings for the response JWT, namely the keys and algorithms, are the ones defined on the profile’s default token issuer.

It is possible to configure the Curity Security Token Server so that secured authorization response messages are required. This can be done at different scopes:

When secured authorization responses are required on the configuration, any OAuth 2.0 authorization request that doesn’t ask for a secure response mode will be rejected.