Security Event Token Signatures

At the bottom of each security event token you’ll see a block of text that looks similar to this:

IvkrGFE3GsK3eTLO_QvdFKqg4ktJ2sDToHNghMfGUlWNzRLMIpmgsWZXzLv0QMiyatLva7mEshTlfyOje-
S_Y-nUniM9hgHgNg-R0Az9hs2mu_ORcXEFo9AHayhjvW1bKHcmTI7dlw2fqFl2VBS594LQspDYfZ4WJ
7hexq7OwACB8qp0oVskx_fc8mHQfy4YnW5GF4XlTcl6CnjYU81qY4hejcnkkg8olbq_ePUnpTpW8-YO5c
PW9nW8KlivRJGWJbEXnffSAd5xwlViJm6iTde2QQVv9pi_Z6LnrxPQotoGhJOvk_wkwANsWC9TwDNnl\
BTiLePCFLU85haWanXcg

This is the token signature, a hashed string that enables you to verify the validity of the token. Signatures are created by:

  1. Combining the header, the payload, and a secret (i.e., a password).
  2. Hashing that combination using one of the allowed algorithms. The most commonly-used hashing algorithm is HMAC SHA256 (aka HS256).

And how do you read and a token signature? For that, you need to use JSON Web Keys.


A Note About Webhook Signatures

Keep in mind that signatures are used for verifying security event tokens, not for safeguarding the contents of those tokens. For example, suppose you have an encoded token, but you don’t have the JSON Web Key used to sign that token. That’s fine: you can still decode the token. You just won’t be able to validate the signature:

That’s the expected behavior, and, as we’ve noted before, that’s fine: after all, webhook notifications don’t contain any personally-identifiable information, which means that there’s little (if any) risk involved in someone decoding a notification that was never meant for them.