CVE-2026-32245: OIDC Authorization Code Grant Client Impersonation in Tinyauth

Tinyauth serves as an authentication and authorization server, implementing the OpenID Connect (OIDC) protocol over OAuth 2.0. The software processes user authentication and issues authorization codes, which downstream applications exchange for access, identity, and refresh tokens. This component acts as the central identity provider for relying parties within its deployment environment.

The vulnerability, tracked as CVE-2026-32245, exists within the /api/oidc/token endpoint. This endpoint processes requests using the authorization_code grant type. The core issue is classified as CWE-863 (Incorrect Authorization), specifically manifesting as an OIDC Authorization Code Grant Client Impersonation flaw.

When a relying party attempts to exchange an authorization code for tokens, the server fails to validate the binding between the submitted code and the authenticated client. This violates the security requirements defined in RFC 6749 Section 4.1.3. Consequently, an attacker possessing a valid client account can misuse an authorization code issued to a different client, bypassing the intended authorization boundaries.

The OAuth 2.0 Authorization Code grant mandates a tight cryptographic and logical binding between the client requesting the authorization code and the client subsequently exchanging it. When the authorization server issues a code, it must record the client identifier associated with the initial authorization request. During the token exchange phase, the server must verify that the client authenticating to the token endpoint matches this recorded identifier.

In vulnerable versions of Tinyauth, the implementation successfully stores the ClientID alongside the authorization code in the backend database. The StoreCode function correctly captures this metadata during the user consent phase. However, the logical flaw occurs during the retrieval and validation phase within the token exchange handler.

The internal/controller/oidc_controller.go application logic processes the token exchange request by verifying the client credentials and fetching the code entry from the database using a cryptographic hash of the provided code. The controller fails to cross-reference the ClientID of the authenticated client with the ClientID stored in the database record. If the code hash is valid and has not expired, the system proceeds to generate and issue tokens, regardless of whether the requesting client is the rightful owner of the authorization code.

The vulnerability stems from an omission in the service layer where the authorization code is fetched and validated. Prior to version 5.0.3, the GetCodeEntry function retrieved the database record but returned it to the caller without enforcing client binding. The controller then consumed this record to issue tokens without performing the necessary ownership check.

The patch introduced in commit b2a1bfb1f532e87f205fa3afa3fc9f148c53ab89 resolves this by modifying both the service and controller layers. The GetCodeEntry function signature in internal/service/oidc_service.go was updated to require the clientId as a parameter. This ensures the service layer has the context needed to perform the validation.

// Patched implementation in internal/service/oidc_service.go
func (service *OIDCService) GetCodeEntry(c *gin.Context, codeHash string, clientId string) (repository.OidcCode, error) {
    oidcCode, err := service.queries.GetOidcCode(c, codeHash)
    if err != nil {
        return repository.OidcCode{}, err
    }
 
    // The critical validation check added in the patch
    if oidcCode.ClientID != clientId {
        return repository.OidcCode{}, ErrInvalidClient
    }
 
    return oidcCode, nil
}

Correspondingly, the token exchange handler in internal/controller/oidc_controller.go was updated to pass the authenticated client.ClientID to the service layer. If the client identifiers do not match, the service returns an ErrInvalidClient error. The controller catches this specific error and returns an HTTP 400 Bad Request response with the standard invalid_client OAuth 2.0 error code, neutralizing the vulnerability.

Exploitation requires the attacker to fulfill specific preconditions. First, the attacker must have a registered and valid OIDC client on the target Tinyauth instance. This satisfies the requirement to authenticate against the token endpoint. Second, the attacker must intercept an authorization code generated for a victim user interacting with a different, legitimate client.

Authorization code interception typically occurs through secondary channels or misconfigurations in the target client application. Attackers achieve this via referer header leakage, open redirects on the callback URL, interception of unencrypted network traffic, or extraction from browser history on shared workstations. The complexity of acquiring this code elevates the CVSS Attack Complexity metric to High.

Once the attacker obtains a valid authorization code, they initiate a POST request to the /api/oidc/token endpoint. The attacker authenticates using their own client ID and client secret while submitting the stolen authorization code. The vulnerable server processes the request, validates the attacker's client credentials, validates the stolen code, and issues access, identity, and refresh tokens.

POST /api/oidc/token HTTP/1.1
Host: tinyauth.example.com
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code&code=STOLEN_CODE_FOR_CLIENT_A&client_id=ATTACKER_CLIENT_B&client_secret=ATTACKER_SECRET_B

Successful exploitation results in unauthorized user impersonation. The attacker receives an identity token (ID Token) and an access token scoped to the victim user. These tokens allow the attacker to authenticate to downstream services or access protected APIs acting as the victim.

The impact is highly context-dependent, relying on the permissions granted to the legitimate client and the data accessible via the generated tokens. The attacker gains the ability to read or modify any resources that the compromised access token permits. This leads to a High impact on Integrity and a Low impact on Confidentiality within the CVSS v3.1 scoring framework.

The vulnerability primarily affects multi-tenant environments or deployments where third-party developers can register custom OIDC clients. In isolated environments where the server operator strictly controls all registered clients, the risk is significantly reduced. The CVSS vector CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N accurately reflects the required prerequisites and the resulting security implications.

The primary remediation strategy requires upgrading the Tinyauth server software. System administrators must deploy Tinyauth version 5.0.3 or later. This release incorporates the mandatory client binding checks within the OIDC token exchange lifecycle.

For environments where immediate patching is not feasible, operators should implement rigorous monitoring of the /api/oidc/token endpoint. Security teams should analyze application logs for high volumes of 400 Bad Request responses. Following the application of the patch, log entries containing the warning message "Invalid client ID" indicate active attempts to exchange mismatched authorization codes.

Operators should also audit all registered OIDC clients on the Tinyauth instance. Revoking credentials for unrecognized or inactive clients reduces the available attack surface. Ensuring that legitimate client applications employ strict redirect URI validation and utilize Proof Key for Code Exchange (PKCE) provides defense-in-depth against authorization code interception attacks.