An identity provider is a high-value control plane. It authenticates people, issues tokens to applications, and often contains service accounts that operate without a human at the keyboard. Kanidm's documentation makes the service-account model explicit. Creating accounts and issuing tokens are privileged operations, and the resulting token can carry access beyond the account's original group membership.
On November 2, 2026, a ZoomEye SDK count-only query returned 0 matches for app="Kanidm" and 50 for title="Kanidm", using sub_type=all, page 1, and a page size of 1. The title matches are a small external signal and may include documentation, login pages, or customized deployments. They are not proof of a valid Kanidm management interface.
Kanidm service accounts can be administered by an entry_managed_by group or account. The documentation states that API tokens are read-only by default and that read-write tokens require an explicit choice. It also describes scope maps that connect OAuth2 scopes to Kanidm groups. That design supports least privilege, but it creates several places where the effective authorization can drift.
The review should trace each service account from owner to token to application. Record the display name, managing group, token expiry, read-only flag, OAuth2 client, scope map, and group membership. Check whether a token was copied into a CI variable, a container image, or a configuration file that is readable by a broader group. Check whether a service account is in idm_high_privilege, because the documentation gives changes to such accounts a stricter administrative boundary.
A token that can read directory data may still be sensitive. A token that can modify identity data can create persistence. A read-write token issued for an integration should not be accepted as the default for a monitoring job. Test the token against the endpoint it is supposed to use and against at least one operation it should not be able to perform. Confirm expiry behavior and revocation on a schedule, not only after an incident.
The 50 title matches do not provide a count of exposed Kanidm instances. They provide a reason to identify internet-facing identity infrastructure and compare it with the internal service-account inventory. The useful question is not whether a page says Kanidm. It is whether a reachable service account has a token that can alter the directory or issue additional credentials.
Kanidm gives administrators useful primitives for delegated identity management. The security outcome depends on token scope, owner visibility, expiry, and the separation between human administrators and machine credentials.
Query evidence
app="Kanidm" returned 0 matches. title="Kanidm" returned 50. Both queries used sub_type=all, page 1, and a page size of 1.