Summary
Backstage's OIDC authentication provider may improperly resolve identities when email-based resolution is used with an identity provider that permits unverified email addresses. An authenticated provider user could potentially assume another catalog identity and gain that identity's associated access and permissions.
Backstage's OIDC authentication provider may improperly resolve identities when email-based resolution is used with an identity provider that permits unverified email addresses. An authenticated provider user could potentially assume another catalog identity and gain that identity's associated access and permissions.
Affected context
The issue may occur in Backstage deployments using the @backstage/plugin-auth-backend-module-oidc-provider package with OIDC email-based identity resolution. Risk is higher when the configured identity provider permits users to authenticate with email addresses that have not been verified, allowing an email claim to be treated as a trusted catalog identity mapping.
The issue may occur in Backstage deployments using the @backstage/plugin-auth-backend-module-oidc-provider package with OIDC email-based identity resolution. Risk is higher when the configured identity provider permits users to authenticate with email addresses that have not been verified, allowing an email claim to be treated as a trusted catalog identity mapping.
Exploit preconditions
- Attack surface: Backstage's OIDC authentication flow
- Required access: An account at the configured OIDC provider
- Provider condition: The provider permits unverified email addresses
- Configuration condition: Backstage uses email-based identity resolution
- Trigger point: Authentication and catalog identity mapping
- Why exploitation is possible: An unverified email claim may be trusted
when selecting an existing catalog identity
- Attack surface: Backstage's OIDC authentication flow
- Required access: An account at the configured OIDC provider
- Provider condition: The provider permits unverified email addresses
- Configuration condition: Backstage uses email-based identity resolution
- Trigger point: Authentication and catalog identity mapping
- Why exploitation is possible: An unverified email claim may be trusted
when selecting an existing catalog identity
Why this happens
The underlying defect is insufficient authentication assurance during OIDC identity resolution. When an application maps a provider-supplied email address directly to a catalog identity without requiring verified ownership or another strong binding, an attacker may influence the identity selected during login. This behavior maps to CWE-287, Improper Authentication, because the system does not adequately verify that the authenticated subject is the same entity represented by the resulting catalog identity.
The underlying defect is insufficient authentication assurance during OIDC identity resolution. When an application maps a provider-supplied email address directly to a catalog identity without requiring verified ownership or another strong binding, an attacker may influence the identity selected during login. This behavior maps to CWE-287, Improper Authentication, because the system does not adequately verify that the authenticated subject is the same entity represented by the resulting catalog identity.
Potential impact
- An attacker may assume another catalog identity
- The attacker could receive permissions associated with that identity
- Protected developer-portal resources may become accessible
- Audit records could associate activity with the wrong user
- The issue may enable unauthorized actions without a demonstrated direct
availability impact
- An attacker may assume another catalog identity
- The attacker could receive permissions associated with that identity
- Protected developer-portal resources may become accessible
- Audit records could associate activity with the wrong user
- The issue may enable unauthorized actions without a demonstrated direct
availability impact
General mitigation guidance
Mitigation generally focuses on strengthening the binding between an external
identity and its Backstage catalog identity.
Common defensive patterns include:
- Requiring verified email claims before using email-based identity mapping
- Preferencing immutable provider subject identifiers over email addresses
- Restricting accepted issuers, domains, and identity attributes
- Applying explicit allowlists for catalog identity mappings
- Requiring additional account linking or administrative confirmation for
ambiguous identities
- Ensuring resulting identities receive only the minimum necessary privileges
- Logging identity-resolution decisions and rejected assurance checks
Mitigation generally focuses on strengthening the binding between an external
identity and its Backstage catalog identity.
Common defensive patterns include:
- Requiring verified email claims before using email-based identity mapping
- Preferencing immutable provider subject identifiers over email addresses
- Restricting accepted issuers, domains, and identity attributes
- Applying explicit allowlists for catalog identity mappings
- Requiring additional account linking or administrative confirmation for
ambiguous identities
- Ensuring resulting identities receive only the minimum necessary privileges
- Logging identity-resolution decisions and rejected assurance checks
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis and configuration checks for email-only OIDC identity mapping
- Code review signals where email claims are trusted without verification
- Tests using unverified, duplicated, changed, or reassigned email addresses
- Policy enforcement requiring verified claims or immutable subject identifiers
- Authentication logs showing unexpected mappings between provider accounts and
catalog identities
- Automated security review tools that flag weak identity-binding patterns
Organizations can look for this issue through:
- Static analysis and configuration checks for email-only OIDC identity mapping
- Code review signals where email claims are trusted without verification
- Tests using unverified, duplicated, changed, or reassigned email addresses
- Policy enforcement requiring verified claims or immutable subject identifiers
- Authentication logs showing unexpected mappings between provider accounts and
catalog identities
- Automated security review tools that flag weak identity-binding patterns
