Create a Consumer

Create a Consumer (Authenticated access).

A Consumer represents an application that uses the Open Bank Project API. Each Consumer has:

• A unique key (40 character random string) - used as the client ID for authentication
• A unique secret (40 character random string) - used for secure authentication
• An app_type (Confidential or Public) - determines OAuth2 flow requirements
• Metadata like app_name, description, developer_email, company, etc.

How it works (for comprehension flow):

1. Extract authenticated user: Retrieves the currently logged-in user who is creating the consumer
2. Parse and validate JSON request: Extracts the CreateConsumerRequestJsonV510 from the request body
3. Determine app_type: Converts the string "Confidential" or "Public" to the AppType enum
4. Generate credentials: Creates random 40-character key and secret for the new consumer
5. Create consumer record: Calls createConsumerNewStyle with all parameters:
   • Auto-generated key and secret
   • enabled flag (controls if consumer is active)
   • app_name, description, developer_email, company
   • redirect_url (for OAuth flows)
   • client_certificate (optional, for certificate-based auth)
   • logo_url (optional)
   • createdByUserId (the authenticated user's ID)
6. Return response: Returns the newly created consumer with HTTP 201 Created status

Client Certificate (Optional but Recommended for PSD2/Berlin Group):

The client_certificate field provides enhanced security through X.509 certificate validation.

IMPORTANT SECURITY NOTE:

• This endpoint does NOT validate the certificate at creation time - any certificate can be provided
• The certificate is simply stored with the consumer record without checking if it's from a trusted CA
• For PSD2/Berlin Group compliance with certificate validation, use the Dynamic Registration endpoint instead
• Dynamic Registration validates certificates against registered Regulated Entities and trusted CAs

How certificates are used (after creation):

• Certificate is stored in PEM format (Base64-encoded X.509) with the consumer record
• On subsequent API requests, the certificate from the PSD2-CERT header is compared against the stored certificate
• If certificates don't match, access is denied even with valid OAuth2 tokens
• First request populates the certificate if not set; subsequent requests must match that certificate

Certificate validation process (during API requests, NOT at consumer creation):

1. Certificate from PSD2-CERT header is compared to stored certificate (simple string match)
2. Certificate is parsed from PEM format to X.509Certificate object
3. Validated against a configured trust store (PKCS12 format) containing trusted root CAs
4. Certificate chain is verified using PKIX validation
5. Optional CRL (Certificate Revocation List) checking if enabled via use_tpp_signature_revocation_list
6. Public key from certificate can verify signed requests (Berlin Group requirement)

Note: Steps 3-6 only apply during API request validation, NOT during consumer creation via this endpoint.

Security benefits (when properly configured):

• Certificate binding: Links consumer to a specific certificate (prevents token reuse with different certs)
• Request verification: Certificate's public key can verify signed requests
• Non-repudiation: Certificate-based signatures prove request origin

Security limitations of this endpoint:

• No validation at creation: Any certificate (even self-signed or expired) can be stored
• No CA verification: Certificate is not checked against trusted root CAs during creation
• No Regulated Entity check: Does not verify the TPP is registered
• Use Dynamic Registration instead for proper PSD2/Berlin Group compliance with full certificate validation

For proper PSD2 compliance: Use the Dynamic Consumer Registration endpoint (POST /obp/v5.1.0/dynamic-registration/consumers) which:

• Requires JWT-signed request using the certificate's private key
• Validates certificate against Regulated Entity registry
• Checks certificate is from a trusted CA using the configured trust store
• Ensures proper QWAC/eIDAS compliance for EU TPPs

Configuration properties (for runtime validation):

• truststore.path.tpp_signature - Path to trust store for certificate validation during API requests
• truststore.password.tpp_signature - Trust store password
• use_tpp_signature_revocation_list - Enable/disable CRL checking during requests (default: true)
• consumer_validation_method_for_consent - Set to "CONSUMER_CERTIFICATE" for cert-based validation
• bypass_tpp_signature_validation - Emergency bypass (default: false, use only for testing)

Important: The key and secret are only shown once in the response. Save them securely as they cannot be retrieved later.

redirect_url must meet the redirect URL rules (https; http only for localhost; or an app scheme in reverse-domain form; no wildcard, user information or fragment). On this instance a redirect URL may point to any host that meets the redirect URL rules. See here

If this Consumer is for an app your installation runs itself (such as the Portal, the API Manager, Opey or a monitoring service like OBP-Sentinel) and the app calls OBP with its own application token (OAuth2 client credentials, no User), those calls need Roles granted to the Consumer as Scopes. Have an administrator mark the Consumer as a Platform App (POST /obp/v7.0.0/management/platform-apps); the app then declares the Scopes it needs (PUT /obp/v7.0.0/consumers/current/platform-app), retrying until it is marked, and the administrator grants the missing ones. See here

Please note: Your consumer may be disabled as a result of this action.

User Authentication is Required. The User must be logged in. The Application must also be authenticated.

This endpoint supports User OR Application authentication. You can authenticate either as a logged-in User (with Entitlements) or as an Application using a Consumer Key (with Scopes). See here for more information.

This endpoint supports User OR Application authentication. You can authenticate either as a logged-in User (with Entitlements) or as an Application using a Consumer Key (with Scopes). See here for more information.

This endpoint supports User OR Application authentication. You can authenticate either as a logged-in User (with Entitlements) or as an Application using a Consumer Key (with Scopes). See here for more information.