Hi Genesys Developer Team,
After integrating the Audiohook API, I now want to verify the signature of the http message. I obtained a different signature when I generated one using the signature-inputs. Could you tell me what's wrong with this please.
Reference URL: https://developer.genesys.cloud/devapps/audiohook/session-walkthrough#establishing-connection
I used the reference url details, still generated with different hash like below.
Actual one generated from code : jEylAwtghWFWytY0R42pe7WFNidyisXPRETVpfhh+1o=
var crypto = require('crypto')
var secret = Buffer.from('TXlTdXBlclNlY3JldEtleVRlbGxOby0xITJAMyM0JDU=', 'base64')
var signature_base = "@request-target": /api/v1/voicebiometrics/ws "@authority": audiohook.example.com "audiohook-organization-id": d7934305-0972-4844-938e-9060eef73d05 "audiohook-session-id": e160e428-53e2-487c-977d-96989bf5c99d "audiohook-correlation-id": 30b0e395-84d3-4570-ac13-9a62d8f514c0 "x-api-key": SGVsbG8sIEkgYW0gdGhlIEFQSSBrZXkh "@signature-params": ("@request-target" "@authority" "audiohook-organization-id" "audiohook-session-id" "audiohook-correlation-id" "x-api-key");keyid="SGVsbG8sIEkgYW0gdGhlIEFQSSBrZXkh";nonce="VGhpc0lzQVVuaXF1ZU5vbmNl";alg="hmac-sha256";created=1641013200;expires=3282026430;
var sign_hash = crypto.createHmac('sha256', secret).update(signature_base).digest('base64')
console.log('computed hash : ',sign_hash);
var hash = 'NZBwyBHRRyRoeLqy1IzOa9VYBuI8TgMFt2GRDkDuJh4='
console.log('expected hash : ', hash);
if (hash === sign_hash) {
console.log('match') // logs => 'match'
} else {
console.log('no match')
}
Expected one from http header : NZBwyBHRRyRoeLqy1IzOa9VYBuI8TgMFt2GRDkDuJh4=
If this is working fine, then its easy for me to test this with my details.
Could you please go through the code and let me know if anything wrong.
Issue was interchanged audiohook-session-id & audiohook-correlation-id values while documented.
If you correct those values, we will get same hash like
"audiohook-session-id": 30b0e395-84d3-4570-ac13-9a62d8f514c0
"audiohook-correlation-id": e160e428-53e2-487c-977d-96989bf5c99d
@Genesys Developer Team, Please update these values in your documentation. So that, it's easy for future developers who are referring the documentation for audio hook signature verification process.
signature-input order got changed in real-time payload when compared to documentation example, which order you need to follow?
request-target means have to mention only the URI part which includes query params or not like below?
wss://test.example.com/integrations/genesysaudiohook?botId=xxxxxxxxxxxxxxxxxxx
authority means host name or different one which is configured in audiohook?
At the end of this section, you will find the following statement:
IMPORTANT
Implementers should not assume the client will only use the listed signature parameters or HTTP header fields and order as shown in examples and test vectors in this document. Implementers are encouraged to support as much of Signing HTTP Messages as possible or practical. Genesys reserves the right to include other parameters, derived components, or HTTP header fields in future releases. We may support other signature algorithms in addition to "hmac-sha256" in the future too, but they will be made configurable though the integration configuration.
Basically, the server needs to follow whatever is listed in the "signature-input" header (derived components, headers and order of elements). The documentation only shows a few examples and should not be used as the source of truth.
Thank you for your reply on this. Yes, we followed the same link as a reference and tried all possibilities to verify the signature. I will try to connect with you/team shortly to showcase a live use-case demo.
There is indeed a bug at the client side when query parameters are used in the URI.
For instance, this URI: "wss://genesys.com/api/v1/some/route?bot=123456&language=en-US" was producing the following @request-target: /api/v1/some/routebot=123456&language=en-US. As you can see, the ? is missing. This would mess up the whole signature.
I am opening a ticket and the fix will probably be deployed by the end of next week.