If you encounter Signature is invalid error (error.signature.invalid), please consider the following:
- Documentation regarding Signature creation:
- Help Centre article regarding eIDAS signing:
How can I get started signing with eIDAS?
- An example in our documentation:
Redirect - Token Exchange (Access Authorization API)
-
Use our Postman collection with your data and check if a request passes (if the Signature works it shows everything is in order from Nordea side):
Postman and Swagger files (Nordea API Market)
- Compare Signature received from Postman Pre-Request script to your own script. Postman Pre-Request script generates working Signatures
- Send the request without "\" (backslashes) in the Signature header
- A valid request sequence is: code, grant_type, redirect_uri (as in Postman collection)
- Digest and Signature headers values are not hardcoded. These values are generated according to:
How do I sign my API requests? (Corporate Access Authorization API)
Postman collection includes the logic for generating these values as a pre-request script:
Creating signature header with Postman (Corporate Access Authorization API)
-
(Sandbox) Signature is generated based on a private key (variable: eidasPrivateKey) and Sandbox testing with any other certificate than the sample QSealC which is downloadable from:
API Market (Sandbox Developer Portal)
will always lead to an unsuccessful request. You can set Signature header to SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in case you want to test without a signature. Refer to:
- (Sandbox) change x-nordea-originating-host value from Production host:
to Sandbox host:
in the signature, so it matches the value sent in X-Nordea-Originating-Host header
- Ensure that headers values in the request are exactly the same as the values used to calculate the Signature (for example: if the Signature string is created based on application/json content-type, the request must also include application/json)
- Headers shouldn't contain content-type and digest. For GET requests it should be:
headers="(request-target) x-nordea-originating-host x-nordea-originating-date"
- Do not miss content-type: application/json in normalized string:
Authentication with eIDAS certificate/How does it work? (Access Authorization API)
How can I get started signing with eIDAS?
Ensure they are sent in the right order and that /n is not present at the end
- Use relevant private key for signing
- Make sure you don't miss space characters between ":" and the value of headers:
(request-target): POST /corporate/v2/authorize
x-nordea-originating-host: open.nordea.com
x-nordea-originating-date: Mon, 14 Aug 2023 06:25:45 GMT
content-type: application/json
digest: SHA-256=IgkTCJLHZWDfD4RTmdkYscsonWvEc642BwP+gufZAsA=
- Don't include whitespace characters in the payload and while generating the Digest:
Authentication with eIDAS certificate (Access Authorization API)
- Both endpoint URL and Digest value are taken into consideration when a Signature is calculated
- When calling /corporate/v2/authorize endpoint you should have this endpoint in the normalized string:
(request-target): POST /corporate/v2/authorize
x-nordea-originating-host: open.nordea.com
x-nordea-originating-date: Mon, 07 Aug 2023 09:21:22 GMT
content-type: application/json
digest: SHA-256=IgkTCJLHZWDfD4RTmdkYscsonWvEc642BwP+gufZAsA=
- Request-target is a part taken to build normalised string, hence make sure it doesn't contain double-slashes (//).
FAQ
- (Sandbox) When we try to upload a test certificate to Microsoft Azure Key Vault, we get an error message: “More than one certificate with private key found in the specified X.509 certificate content. Please specify X.509 certificate content with only one certificate containing private key.” We downloaded the test certificate and changed the file extension to .pfx (Azure Key Vault does not support .p12 format). The Sandbox certificate is expired and Microsoft Azure doesn't allow expired certificates. When will you have a valid certificate for Sandbox available?
We recommend skipping the signature signing with SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in the Signature header or use alternative way of storing the certificate if your secure secret store doesn't allow you to store our test certificate.
-
(Sandbox) We are testing GET requests on the endpoint corporate/premium/v4/accounts and having trouble with the signature-argument in the header “Signature”. We are using a test eIDAS Certificate. What format the signature code must be provided in? Do we have to encode with base64? Do you have an example request?
Example code: eIDAS signature creation (Access Authorization API)
signature="Base64(RSA-SHA256(signing string))". We provide an example on how the signature can be created with Java in the same section. In case of POST, PUT or PATCH method you have to also add "Content-Type" and "Digest" header with value Digest. Example on how to create Digest can be found in our documentation:- Are the following steps correct?
- Define the signing string as desired:
“(request-target): get corporate/premium/v3/accounts\n
x-nordea-originating-host: api.nordeaopenbanking.com\n
x-nordea-originating-date: Fri, 31 Mar 2023 08:31:34 GMT\n”
- Encrypt the signing string using RSA-SHA256 and the private key from the test certificate
- base64-encode the encrypted signing string
- Assign the encoded signing sting to the signature-header and define the remaining headers
- Make the get request
If you still need our assistance, please submit a request:
Nordea Open Banking contact form
and provide:
- a full body of an Open Banking API request/response with an exact endpoint, headers, message_identification and creation_date_time included - please see: API Responses
- normalized string before encryption
- your algorithm (don't disclose your certificate) in order to show how you create a Signature
Preserve a proper order of headers: