HTTP headers convey information about a Webhooks v3 request. But what does the request itself convey? We’re glad you asked that question; it conveys something similar to this:
Before you schedule an appointment with your eye doctor, that’s how the payload is supposed to look. That’s because payloads are encoded before being sent.
That also means that payloads need to be decoded after they’ve been received; if they aren’t, then all your database records are going to look like the sample payload shown above. Fortunately, decoding a security event token is pretty easy; that’s because tokens are encoded and not encrypted. Because of that, any application capable of decoding Base64 can decode a webhooks notification, with no password or secret or any other form of authentication required. For example, if you have a Mac you can use Terminal and the base64 app to decode tokens. Here’s the syntax for decoding the token header:
And here’s the decoded header:
On a Windows computer, you can use Windows PowerShell to achieve the exact same result:
If you’re wondering about security, well, encoding is not intended to provide security: encoding simply ensures that all Identity Cloud security event tokens use the same character encoding. That eliminates the problems that could arise if, say, the webhooks server is using UTF-8 encoding while the listener endpoint is using ISO 8859-1 encoding.
So, yes, someone could decode one of your security event tokens, although it’s hard to see what they would gain by doing so. After all, no personally identifiable information is included in a Webhooks v3 security event token: although you might see a user UUID such as 6b004bc5-179c-45c2-815d-31b06169371d you will never see a user’s name, email address, phone number, or anything else that might give you some insight into who that user is.
On a similar note, when Webhooks v3 reports a change made in the Identity Cloud,the security event token will indicate what was changed (for example, a user profile attribute or a password) but it will not report either the previous value or the new value for that item. For example, consider the following notification, which indicates that a user has changed his or her password:
As you can see, the notification tells you that a user account was updated (the entityUpdated event type) and that the attribute changed was the email attribute (which stores the user’s email address). However, neither the user’s old email address nor the user’s new email address is included.
By the way, a fully decoded SET looks something like this:
Again, the color-coding is there for a reason: the colors delineate the three sections of a security event token. Those sections include:
- The security event token header (red color-coding)
- The security event token payload (blue color-coding)
- The security event signature (green color-coding)