Is HMAC signature value in API documentation correct
Authentication documentation Dear Sir or Madam,
I'm preparing integration to pilot environment for World Check One API and am thus studying precisely your documentation.
My question treats the HMAC signature using SHA256 as hash function. When I presumably implement the identical sample plain text signature message from printscreen (using 0x0A aka LF as line ending also in formatted JSON output) and use secret "1234" as key a different HMAC result is being generated.
Therefore my question is:
Is the HMAC result value in Base64 encoding Iktz/AdXHmDouNm6uBB8ZW0xcfNGuWGDxmX9TFMwuF0= mentioned in the documentation definitely correct?
When I use e.g. the online HMAC generator https://www.devglan.com/online-tools/hmac-sha256-online I get the same result as when I implement the message with specified secret key in a small C#.NET sample code.
In my case the HMAC result (Base64 encoded) is: BNxFcG6hrSEtsbuIuVhJQ6OCRvLCd+8rEslRI6Jj6M0=
My idea was to write an automated test verifying a correct HMAC signature prior to directly start sending requests to the pilot API. But in this case, I must know the expected correct result of HMAC signature.
A similar question was posted in https://community.developers.refinitiv.com/questions/74536/invalid-example-hmac-string.html
I'm kindly expecting your assistance and thank you in advance for your efforts.
Kind regards
With the help of the reference code example we were able to resolve this issue by addressing the below points:
- Set content type and content length in HTTP POST-Request (not only in signature data)
- Set JSON payload flat without line breaks etc., i.e. not indented
Marking this question as accepted, as mentioned feel free to reach out if you need any further assistance.
The host mentioned in the security document is an old host the latest host utilized it "api-worldcheck.refinitiv.com", but the underlying mechanism of hmac generation is correct and hmac value also depends on the date parameter, so a request sent now and a request sent next second will have a different hmac value.
As you can see below script from Postman that is used in a simple "Get my top-level groups API", here we have declared the values of attributes like host,url, API key etc in the Postman environment, but if you see the dataToSign value date is one of the attributes contributing to it which inturn goes into hmac.
However, I will follow up with the concerned team to have the host updated to reflect to the latest host in the documentation.
function generateAuthHeader(dataToSign) {
var hash = CryptoJS.HmacSHA256(dataToSign, environment["api-secret"]); return hash.toString(CryptoJS.enc.Base64);}
var date = new Date().toGMTString();
var dataToSign = "(request-target): get " + environment["gateway-url"] + "groups\n" + "host: " + environment["gateway-host"] + "\n" + "date: " + date;
var hmac = generateAuthHeader(dataToSign);
var authorisation = "Signature keyId=\"" + environment["api-key"] + "\",algorithm=\"hmac-sha256\",headers=\"(request-target) host date\",signature=\"" + hmac + "\"";
postman.setEnvironmentVariable("authorisation", authorisation);postman.setEnvironmentVariable("currentDate", date);
Hi @Mehran Khan,
thank you very much for your immediate response.
I'm fully aware of the fact, the the timestamp in signature data (in fact each and every byte) is relevant for the hash generation. In order to receive an idential HMAC, I have to use the identical timestamp - generally said all identical contents - from your example.
This is in fact exactly what I did. The timestamp in my sample is Tue, 07 Jun 2016 20:51:35 GMT.
I don't want to exclude a mistake in my implementation (C#.NET on framework .NET 5). However, I receive with two different HMAC SHA256 generators twice the same HMAC using the identical signature data (host "api-worldcheck.refinitiv.com"), timestamp as mentioned, API key ("4321") and API secret ("1234") as mentioned in your sample.
Could you please check and let me know? If it facilitates your analysis, I could provide you with my HMAC implementation and the corresponding unit test.
If this turns out to be a mistake on my side, I have to fix it prior to send any request to the pilot environment.
Your support is very much appreciated.
Kind regards,
Markus
May I propose a quick meeting on Monday to go through this? Tomorrow is a public holiday here so let us know your availability for Monday we will happy to jump on a quick call and discuss this in length with you.
Sure, I'm available on Monday Sept 13 from 10-12 (8-10 GMT) as well as from 15-18 (13-16 GMT).
I have unaccepted the answer, we will continue our debugging over the email and update the solution and accept it here once we reach there.