Summary
Logto Account API handlers may disclose stored social or enterprise SSO provider access tokens to callers whose same-user access token has only the openid scope. If federated token storage is enabled and the user has authenticated through a supported connector, a low-trust application may obtain and use the provider token within its granted upstream scopes.
Affected context
The issue occurs in Logto deployments where:
- Account API endpoints expose stored third-party or enterprise SSO access tokens
- Federated token-set storage is enabled
- The affected user has authenticated through a supported social or enterprise connector
- Authorization checks confirm user identity but do not enforce the identities scope
The affected handlers are associated with account identity and SSO identity access-token retrieval.
Exploit preconditions
- Attack surface: Logto Account API endpoints for identity access-token retrieval
- Required access: A same-user access token with the openid scope; the caller need not hold the intended identities scope
- Trigger point: A request to retrieve a stored social or enterprise SSO provider token
- Required state: Federated token-set storage must be enabled, and the target user must have authenticated through a supported connector
- Why exploitation is possible: The handlers authenticate the caller but omit the authorization boundary applied to neighboring identity-detail operations
Why this happens
The underlying flaw is an authorization-check omission mapped to CWE-862: Missing Authorization. The Account API verifies that the request is associated with the user, but does not require the additional identities scope intended to protect sensitive identity operations. This creates a gap between authentication and authorization, allowing a lower-privilege token to access credentials that should require explicit consent.
Potential impact
- Disclosure of stored social or enterprise SSO provider access tokens
- Unauthorized access to upstream provider APIs within the disclosed token's scopes
- Exposure of user-linked data held by external identity providers
- Account or integration abuse if upstream tokens support sensitive operations
- Increased impact from token reuse across applications or services
General mitigation guidance
Mitigation generally focuses on restoring explicit authorization boundaries around credential-sensitive operations.
Common defensive patterns include:
- Require the identities scope, or an equivalent narrowly defined permission, before returning provider access tokens
- Apply consistent scope and resource authorization checks across related Account API handlers
- Avoid returning third-party tokens to low-trust applications when a server-side integration can perform the required action
- Minimize stored token scope, lifetime, and audience where supported by the upstream provider
- Encrypt stored federated tokens and restrict access to the decryption and retrieval paths
- Use least-privilege service identities and segregate applications with different trust levels
- Record and monitor token retrieval events, including caller, user, connector, and decision outcome
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and policy checks that compare endpoint behavior with declared scope requirements
- Code review of handlers that return credentials, tokens, or other sensitive identity data
- Tests that exercise each sensitive endpoint with progressively reduced scopes
- Authorization matrices verifying that authentication alone cannot satisfy credential-retrieval requests
- API gateway or service policy enforcement requiring explicit permissions for token-bearing responses
- Audit monitoring for unusual third-party token retrieval volume, applications, or connector access patterns
Automated security review tools may help flag endpoints that expose sensitive resources without corresponding authorization checks.
