Skip to main content

Clients configuration | Security

Client attributes help to manage the authorization capabilities for OAuth 2.0 and satellites flows. They provide a high level of customization helping the server to be integrated within infrastructures seamlessly. Those configuration help the flows to be both business and technically adapted for the addressed use case.

Parameters sections

OAuth clients can be customized through either the Administration API or the user interface providing 4 categories of settings:

  • General configuration
  • Authentication
  • Security
  • Grant types

Cryptographic Signatures​

boruta gives means to implement and connect signature adapters which provide means for signing the authorization artifacts both from the federated identity (ID Tokens) and the decentralized identity (Verifiable Credentials). Out of the box, an internal (boruta provided) and an Universal adapter are implemented and ready to use. Those support cryptographic material generation and use along side with Decentralized IDentifiers support. Public and Private Keys are the base for enabling signatures and the public part of the keys is exposed through the jwks OpenID endpoint. Those keys will be used for the signature of ID Tokens, Userinfo (if needed) and Verifiable Credentials. This enables to connect boruta to Hardware Security Modules (HSM) with low effort, enabling them to store cryptographic keys in a secure enclave.

Key pair types

The type of the generated key pairs is tied to the signature algorithm used for JWTs signature:

  • RSA keys enforce the JWTs signature algorithm to be of the RS algorithm class
  • Elliptic curve keys enforce the JWTs signature algorithm to be of the ES algorithm class
  • Universal keys enforce the JWTs signature algorithm to be of the EdDSA algorithm class

Security parameters​

ID token signature algorithm is the algorithm used to sign ID Token JWTs. It have to be in correspondance with the key pair type.

Userinfo response signature algorithm is the algorithm used to sign userinfo response JWTs, the response being possibily not encoded and signed. It have to be in correspondance with the key pair type.

Authorization​

Enforce Demonstration Proof-of-Possession (DPoP) enables the client to only support DPoP requests.

Enforce pre-authorized code transaction code enforces the presentation of a tx_code while issuing verifiable credentials.

Authorize scope would determine if the client defines the specific public and private scopes to be authorized.

Authorized scopes would be the list of scopes that can be granted with this client.

Check public client id enforces the check of the presentation vp_token against the client_id parameter in OpenID 4 Verifiable Presentations flows.

Proof Key for Code Exchange​

PKCE would determine if Proof Key for Code Exchange flow is enforced using this client.

Public refresh token allow refreshing tokens without providing a client_secret

Public revoke allow to revoke tokens without providing a client_secret

User interface​

client form