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.
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.
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 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
When enabling request object support in the admin UI, the wizard helps choose a pre-defined combination of configurations suitable
for different needs:
More Secure But Still Easy to Implement Compliant
The following configuration is used to resolve parameters when they are found in both request object and query or
The following is an example configuration of request objects:
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.