Summary
Open WebUI can accept an OAuth access token issued to a different client registered with the same identity provider and exchange it for an Open WebUI session. When OAuth token exchange is enabled, anyone holding such a token may be able to authenticate as the token's user without the operator having authorized the originating client.
Affected context
The issue occurs in Open WebUI deployments that enable OAuth token exchange and expose the provider-specific token exchange endpoint. Risk arises when the implementation validates only that the provider accepts the token through its userinfo endpoint, without also confirming that the token was issued to the OAuth client configured and trusted by Open WebUI.
Exploit preconditions
- Attack surface: The
/oauth/{provider}/token/exchangeendpoint - Required access: Possession of a valid access token issued by the same OAuth provider, potentially for another registered client
- Trigger point: Submission of the provider access token to the token exchange flow
- Why exploitation is possible: The exchange process verifies the token's provider-side identity but does not adequately bind the token to the authorized OAuth client context
Why this happens
The underlying flaw is an authentication-boundary failure. Open WebUI treats successful validation by the provider's userinfo endpoint as sufficient proof that the token is acceptable for its own OAuth client, without validating the token's intended audience, client binding, or equivalent authorization context. This maps to CWE-287: Improper Authentication, because an identity assertion is accepted without adequately verifying that it was issued for the relying application.
Potential impact
- An attacker may obtain an Open WebUI session representing the token's user
- Unauthorized users may access conversations, files, models, or other resources available to that account
- A compromised or third-party OAuth client may become an unintended path into the Open WebUI deployment
- Account-level actions could be performed without the operator's intended client authorization
General mitigation guidance
Mitigation generally focuses on binding exchanged tokens to the intended OAuth client and enforcing a complete authentication context.
Common defensive patterns include:
- Validate the token audience, authorized client, issuer, and other provider-specific claims where available
- Use authorization-code flows with PKCE or another flow that binds authorization to the configured client
- Reject tokens that were minted for unknown, untrusted, or unrelated clients
- Keep OAuth token exchange disabled unless the deployment requires it
- Minimize session privileges and apply least-privilege authorization after login
- Treat provider userinfo validation as one authentication signal rather than proof of client authorization
How teams detect issues like this
Organizations can look for:
- Static analysis and code review findings where userinfo success is treated as sufficient without audience or client validation
- OAuth exchange handlers that accept raw bearer tokens without checking issuer, audience, client identity, or token type
- Tests covering tokens issued to alternate clients at the same identity provider
- Authentication logs showing token exchanges from unexpected clients, issuers, or application contexts
- Policy controls requiring explicit OAuth client binding and negative authorization tests in CI pipelines
