Follow-up from the identity-leak fix (#120)
#120 closed the primary leak (empty/whitespace legacy UserId no longer becomes a shared cache key). A secondary, lower-severity collision remains in the legacy identity path: IdentityAccountBinding blanks ProviderKey/Issuer for legacy bindings, so two users on different providers/issuers with a coinciding raw subject collide on the bare subject in the process-wide identity cache.
Including principal.IdentityProvider in the legacy key would fix it — but it directly contradicts an existing, intentional spec: for_IdentityAuthorizationCache/when_reusing_a_legacy_authorization ("Specifies the released tenant and user identifier reuse behavior for legacy principals") asserts two legacy principals with the same subject but different IdentityProvider must be treated as the same account. So this is a product decision, not a silent change under a security PR.
The structural cure is opting the affected providers into canonical identity resolution (which already segregates same-subject/different-provider users — proven by for_IdentityDetailsResolver/.../with_a_different_provider_and_the_same_raw_subject). Decide whether legacy cross-provider subject collision is acceptable; if not, either change the documented legacy behavior or migrate those providers to canonical.
Follow-up from the identity-leak fix (#120)
#120 closed the primary leak (empty/whitespace legacy
UserIdno longer becomes a shared cache key). A secondary, lower-severity collision remains in the legacy identity path:IdentityAccountBindingblanksProviderKey/Issuerfor legacy bindings, so two users on different providers/issuers with a coinciding raw subject collide on the bare subject in the process-wide identity cache.Including
principal.IdentityProviderin the legacy key would fix it — but it directly contradicts an existing, intentional spec:for_IdentityAuthorizationCache/when_reusing_a_legacy_authorization("Specifies the released tenant and user identifier reuse behavior for legacy principals") asserts two legacy principals with the same subject but differentIdentityProvidermust be treated as the same account. So this is a product decision, not a silent change under a security PR.The structural cure is opting the affected providers into canonical identity resolution (which already segregates same-subject/different-provider users — proven by
for_IdentityDetailsResolver/.../with_a_different_provider_and_the_same_raw_subject). Decide whether legacy cross-provider subject collision is acceptable; if not, either change the documented legacy behavior or migrate those providers to canonical.