Authorization Header keyid?

The Authorization header that is sent with WebHook posts sent by custom Automations contains a ‘keyid’ field which, I am assuming, relates to the keys used for signing and validating the field.

Does anyone know how this is derived and where I can find it? (Other than by monitoring incoming packets, that is.)

My application will have several Automations calling the same Web service so will need to match up the appropriate public key to the incoming requests.

Edit: I suspect the the numeric portion of the keyid may be the key’s fingerprint/MD5 hash but have not been able to generate anything that matches so far so I may be wrong on that.

I think the docs here should answer your question:

Thanks for the suggestion, it has helped me progress a little further.

Although I’d used those docs when creating my web hook I hadn’t looked at the linked libraries very closely.

From looking at the python and java examples the numeric portion of the keyid is just an MD5 hash of the base64 decoded body of the key.

I’ve duplicated both the Java and Python routines and can get hashes in the right format.

Unfortunately that doesn’t give a matching fingerprint for any key I’ve tried so I think I’m still missing a vital element.

(Suspiciously, the Python library describes the fingerprint routine as “currently busted” which is a little worrying)

Yeah. it looks like md5, but not sure if it is standard rsa fingerprint or is smartthings users some special data to generate the keyId. it is somewhat surprising this isn’t documented.

Perhaps @Jim can provide more details.

Hi @TonyFleisher,

I’ve pinged the Developer Relations team about this, but I’d recommend opening a Developer Support issue if you haven’t already.

As mentioned earlier, there are some docs on this topic but it sounds like there’s some gaps that aren’t capture there.

Thanks for that.

I raised a support log on Saturday so hopefully your ping will help to push it along.

I haven’t got anything useful back from the support request but, in case anyone else is facing the same issue, I think I’ve worked out how we’re supposed to match a public key to a signature.

I still haven’t a clue how the keyId is generated but I think what we’re supposed to do is to extract the installedAppId from the body of the message and use that to identify a matching public key.

The application ID is obtainable from the smartapp definition along with the public key and is present as installedAppId in all lifecycle messages except PING which doesn’t have a signature anyway.

This doesn’t solve the problem of getting the keyId or allow the signature to be independent of the body but it is, at least a usable workaround.

I’d still prefer to use keyID but I think I may be able to get by without it, for now at least.

Please ignore my post above.

I had assumed InstalledApplicationId would be the same as my original ApplicationId, but it isn’t so I’m back to sniffing the keyId out of an incoming message and tying it up with a key manually.

Until support respond with an answer to my question, at least.

I don’t know if @Jim can provide a bit more information on here since my support request seems to have fallen into a black hole (no response for over two weeks now)

There must be an official way to tie up the keyId and the public key. Hopefully it’s not just a case of tying things together manually.