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
request
request_uri
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.
require_signed_request_object
none
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.
/par
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.
require-pushed-authorization-requests
<require-pushed-authorization-requests>
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.
redirect_uri
<allow-per-request-redirect-uris>true</allow-per-request-redirect-uris>
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.
nbf
exp
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
More Secure But Still Easy to Implement Compliant
Very Secure
Other
The following configuration is used to resolve parameters when they are found in both request object and query or form parameters.
The following is an example configuration of request objects:
<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>
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.
query.jwt
fragment.jwt
form_post.jwt
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:
require-secured-authorization-response
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.
The Curity Identity Server supports issuing signed then encrypted ID tokens, as defined in OpenID Connect. For details refer to Issuing OAuth and OpenId Connect Tokens.