Webhooks v3 reports a non-existent client ID

When a Webhooks event notification is issued, that notification indicates which API login client was responsible for the event (i.e., which API client created, modified, or deleted the corresponding user profile). For example, if you’re using Webhooks 2.0, your event notification will look similar to this:

[
  {
    "uuid":"12345678-4321-1234-4321-123456789123",
    "entity_type":"user",
    "datetime":"2022-01-07T22:26:10.947Z",
    "hash": "1234567891234567891234567891234567891234",
    "client_id":"98765432198765432198765432198765"
  }
]

In the preceding example, the client_id claim tells us that the API client with the ID 98765432198765432198765432198765 was used to modify a user profile and, in turn, was responsible for generating the event.

That should be pretty straightforward, especially if (for the sake of this example) you only have one API login client: 98765432198765432198765432198765. In that case, you'd expect the client ID to always be reported as 98765432198765432198765432198765. And yet, if you’re using Hosted Login, you might occasionally receive an event notification like this one:

[
  {
    "uuid":"12345678-4321-1234-4321-123456789123",
    "entity_type":"user",
    "datetime":"2022-01-07T22:26:10.947Z",
    "hash": "1234567891234567891234567891234567891234",
    "client_id":"34way7esasgyjsq99wu7emu6wtt82j8w"
  }
]

As you can see, this time around the client_id is reported as 34way7esasgyjsq99wu7emu6wtt82j8w, which is definitely not one of your client IDs. Is this a mistake or, even worse, some sort of security breach?

Fortunately, the answer to both of these questions is the same: no. As it turns out, 34way7esasgyjsq99wu7emu6wtt82j8w is the ID of an internal Identity Cloud API client. When a user modifies their user profile, those modifications are typically carried out by the user’s login client. If you’re running Hosted Login, however, that’s not always the case. Instead, there are times when Hosted Login itself updates the user profile. For example, this occurs when:

An email address or mobile number is deleted. (That is, the email and emailVerified or the mobileNumber and mobileNumberVerified attributes are set to null.)
An email address or mobile number is verified. (Again, changing either email and emailVerified or mobileNumber and mobileNumberVerified).
Email address or mobile number verification takes place during the two-factor authentication process.

The user selects the Delete my account or the Request my data setting in their user profile (which, as a result, changes either the accountDeleteRequestTime or the accountDataRequestTime attribute).
In the preceding scenarios, Hosted Login bypasses the API client and modifies the user profile itself. To do that, it relies on an internal I<<PR
API client (like client 34way7esasgyjsq99wu7emu6wtt82j8w). As a result, client 34way7esasgyjsq99wu7emu6wtt82j8w is correctly reported in the client_id claim; after all, that was the API client responsible for updating the user profile and for generating the event.

Which simply means that yes, on relatively-rare occasions your event notification could reference an API client that isn’t one of your API clients. And that's OK: that's simply how the system works.

A couple things to keep in mind here. For one, the Identity Cloud has a limited number of these internal API clients. That means that Organization A might see client 34way7esasgyjsq99wu7emu6wtt82j8w in one of its event notifications and Organization B might see the same client ID reported in one of their event notifications. Again, that’s no cause for alarm: that simply means the same internal client was employed in both those events.

In addition to that, the Identity Cloud has multiple internal clients, which means that the internal client used today might (or might not) be the same internal client used tomorrow. For example, suppose a user verifies their email address today, and the resulting event notification indicates that the internal client 34way7esasgyjsq99wu7emu6wtt82j8w was used to update the user profile. Let’s further suppose that, tomorrow, a second user verifies their email address and the event notification indicates that internal client nhjsdtjwvaytevc2w5sx42skggvjn7bu was used to update the profile. There’s nothing unusual about that: internal clients (and client IDs) are subject to change, and you shouldn’t expect the same internal client to be used each time Hosted Login updates a user profile.