Security
API Authentication standards
All server-side REST APIs require API keys for authentication, whereas the Klarna Web SDK uses Client IDs. Ensure all API requests are transmitted over HTTPS using TLS 1.2 protocol at a minimum. Attempts to connect without valid credentials or via plain HTTP will not succeed.
API keys are sensitive; handle them with utmost care.
The TLS certificates at API endpoints are issued by AWS Certificate Manager and are subject to automatic renewal as expiration approaches. We advise against reliance on specific certificate details, recommending instead trust in the root CA as outlined in the documentation.
Global authentication for Partner product API
For Klarna Partners working with multiple account_ids, you should consider the following:
-
account_id
must be included in the path for operations on a specific Partner or its resources (use theaccount_id
returned by the Management API):- /v1/accounts/{account_id}/payment/requests
- HTTP header :
- Authorization: Basic <api_key>
DDOS protection
Our integration APIs are fortified with active DDOS protection measures designed to stop traffic identified as illegitimate or exhibiting atypical behaviors. If a DDOS protection rule is triggered, the HTTP-status code 403 will be returned, absent the typical error information object.
Further information about rate limiting is available in the Rate limiting section.
Communication security
The global API endpoint is secured via 2 anycast static IPs, enabling partners to configure egress security measures within their IT infrastructure effectively.
API key usage can be restricted to designated CIDR blocks, ensuring only authorized calls from predetermined IP addresses are allowed. This measure effectively restricts access to Klarna's API to trusted networks, reducing the risk of unauthorized access.
Callbacks from Klarna will originate from specific IP addresses based on the environment, information which should be used to configure firewalls for enhanced security.
Mutual Transport Layer Security
Mutual Transport Layer Security (mTLS) is an enhanced communication security mechanism that adds extra layers of protection to make it more difficult for attackers to misuse leaked credentials. It ensures that both the client and server authenticate each other, making the communication more secure.
Klarna requires acquiring partners to implement mTLS to ensure the security of Partner integrations. For all other account types, it may be enabled manually by Klarna on request.
To enable mTLS for your Klarna account, follow these steps:
- Reach out to the Klarna partner account team to enable mTLS for your account.
-
Create and Store Your Private Key using elliptic curve cryptography with the prime256v1 specification.
-
Example command:
openssl ecparam -genkey -name prime256v1 -out my-key-file.pem
-
Example command:
-
Create a Certificate Signing Request (CSR):
- The Common Name (CN) in the CSR should be the last part of your account ID.
- For example, if your account ID is krn:partner:global:account:live:LYABCDEI, the CN should be LYABCDEI.
-
Example command:
openssl req -new -key my-key-file.pem -out csr.pem -subj "/CN=LYABCDEI"
- Send the CSR to the Klarna account team. Klarna will return the certificate via Yopass (a secure sharing service).
- Use the issued certificate and private key to establish connections to the Klarna API.After the certificate has been returned, the APIs will return an response header including the status of the MTLS verification. The header returned is “Klarna-Mtls-Verification-Status” and the value is one of “NOT_PRESENT”, “VALID” and “INVALID” so that the configuration can be verified beforehand.
- When the integration has been setup and requests returns “VALID” status contact the Klarna account team and communicate from which time mTLS should be enforced
-
At the activation time the mTLS client certificate will be verified on all API-requests and the status header stop being returned.
Important notes
- CSR Requirements : The CSR should only include the CN and no extra attributes.
- Certificate Validity : The issued certificate is valid for 3 years. You need to monitor its expiration and initiate the renewal process in advance.
- Multiple Certificates : You can have up to 10 active certificates at a time.
-
Revoking Certificates
: Before revoking an active certificate, ensure a new certificate is issued and installed. Use the partner API to revoke the certificate.
Certificate rotation process
- Issue a New Certificate following the same steps to create and submit a CSR.
- Install and Test the New Certificate, ensuring the new certificate works correctly.
- Revoke the Old Certificate, using the partner API to revoke the old certificate after confirming the new one is functioning.
By following these steps, you can ensure a secure and smooth setup of mTLS for your Klarna account.
Security protocols and recommendations
Security protocols vary by integration and should be assessed individually. However, some universal requirements include:
- Maintaining up-to-date security across all system components, promptly applying the latest patches, and employing a thorough testing process before deployment.
- Carrying out regular fraud assessments to pinpoint and address potential security issues.
- Limiting administrative rights strictly to those who need them, adhering to the principle of least privilege.
- Keeping a formal log of all individuals with access to Klarna systems and ensuring access is granted via corporate email addresses.
- Regularly monitoring and updating access rights , especially after an employee's role changes or departure, and conducting periodic access reviews.
- Avoiding shared accounts to ensure actions can be attributed to individual customers.
- Enforcing the use of strong passwords (14 or more characters) and enabling two-factor authentication (2FA) where feasible.
- Encrypting stored secrets and not keeping them in plaintext.
- Considering suppliers and third-party providers within the organization’s overall security strategy and conducting appropriate evaluations.
- Enabling logging for sensitive actions and monitoring for suspicious activities. Klarna mandates that partners report any suspicious activities through Partner support or the Partner portal chat. This includes unusual Klarna transaction processes. Such collaborative vigilance is crucial in detecting and mitigating potential threats early, ensuring a secure environment for all parties involved. Klarna reserves the right to disable API keys upon detecting any evidence of potential compromise. Adherence to these guidelines is essential for maintaining robust security standards and protecting against potential vulnerabilities.
Authentication type by service
Two authentication methods are used in the platform: API authentication via an API key and a client ID, employed to authenticate the calling account.
- The API key is highly confidential and must never be exposed in clear-text beyond an API request.
- The client-id is used in a browser environment and is not secret in itself, it must be configured with a list of approved websites from which it’s approved to be used which will prevent some fraud scenarios Both API-keys and client-ids are signed tokens which are verified by the platform to ensure the integrity of the information.
The pattern for both API-keys and client-ids are:
-
Client ID structure:
klarna_<live|test>_<client>_<random>
-
Client ID Example:
klarna_test_client_elZGI1B5dHBIRWcjZrNldnbEVj[...]uefnc3
-
API Key Structure:
klarna_<live|test>_<api>_<random>
-
API Key Example:
klarna_live_api_elZGI1B5dHBIRWltRjF5cjZrNldnbEVjKnIqeC[...]Uybz0
The authentication information used by features of the platform:
Feature | Authentication type |
---|---|
Web SDK | Client-id |
REST API | API-key |
Sign-in-with-klarna | OAuth using client-id and API-key |