The list was short, but the names on it mattered. Every sub-processor behind an OpenID Connect (OIDC) workflow is a link in the chain, and one weak link can shatter trust.
OIDC sub-processors are third-party services that help deliver identity and authentication features. They can handle token storage, perform cryptographic checks, manage user profile data, or process logs for compliance. In practice, they operate behind your IdP or authorization server, making calls and storing information that moves through your authentication layer.
Knowing your OIDC sub-processors is not optional. Each one touches sensitive data: the sub claim, user attributes, token signatures, client IDs, redirect URIs. These are the points where security, privacy, and regulatory compliance intersect. If you use a managed OIDC provider, you inherit their sub-processors, often including cloud infrastructure services, monitoring platforms, or email/SMS gateways used for MFA flows.
The risk profile changes with every new service added to the list. Data residency laws may force you to vet where a sub-processor stores tokens or logs. Some jurisdictions require public disclosure of all sub-processors. Others mandate that you allow customers to object to certain processors or give advance notice before changes. For OIDC workloads in enterprise or regulated industries, tracking this list is a standard part of vendor due diligence.