Summary
Authlib's documented client-registration reference implementations can authorize requests based on a client ID supplied by the requester without confirming that the registration access credential belongs to that client. In deployments that follow both examples, any client with a valid registration access token may be able to read, alter, or delete another client's registration.
Authlib's documented client-registration reference implementations can authorize requests based on a client ID supplied by the requester without confirming that the registration access credential belongs to that client. In deployments that follow both examples, any client with a valid registration access token may be able to read, alter, or delete another client's registration.
Affected context
The issue occurs in OAuth or OpenID Connect servers built with Authlib when both documented reference methods are used for client configuration authorization. The affected logic accepts request-controlled client identifiers, locates the corresponding registration, and checks editability without reliably binding the supplied credential to that same client. Deployments that implement additional ownership or token-to-client validation may not be affected in the same way.
The issue occurs in OAuth or OpenID Connect servers built with Authlib when both documented reference methods are used for client configuration authorization. The affected logic accepts request-controlled client identifiers, locates the corresponding registration, and checks editability without reliably binding the supplied credential to that same client. Deployments that implement additional ownership or token-to-client validation may not be affected in the same way.
Exploit preconditions
- Attack surface: Client registration management endpoints
- Required access: A valid registration access token for any client
- Trigger point: Authentication and permission checks for client configuration operations
- Target selection: The request supplies a client identifier used to select another registration
- Why exploitation is possible: Authorization checks verify whether the selected client is editable but do not establish that the presented credential belongs to that client
- Attack surface: Client registration management endpoints
- Required access: A valid registration access token for any client
- Trigger point: Authentication and permission checks for client configuration operations
- Target selection: The request supplies a client identifier used to select another registration
- Why exploitation is possible: Authorization checks verify whether the selected client is editable but do not establish that the presented credential belongs to that client
Why this happens
The underlying bug is an object-level authorization failure. Request-controlled client identifiers are used to select a registration, while the registration access credential is not cryptographically or logically bound to the selected client before read, update, or delete operations are authorized. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key and is also related to CWE-1188: Insecure Default Initialization of Resource, because the documented authorization behavior can leave ownership validation incomplete.
The underlying bug is an object-level authorization failure. Request-controlled client identifiers are used to select a registration, while the registration access credential is not cryptographically or logically bound to the selected client before read, update, or delete operations are authorized. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key and is also related to CWE-1188: Insecure Default Initialization of Resource, because the documented authorization behavior can leave ownership validation incomplete.
Potential impact
- An attacker may read another client's registration details
- An attacker could modify redirect URIs or other client metadata
- Authorization codes or tokens may be redirected to an attacker-controlled endpoint
- An attacker may delete registrations and cause denial of service
- OAuth or OpenID Connect trust relationships could be weakened
- An attacker may read another client's registration details
- An attacker could modify redirect URIs or other client metadata
- Authorization codes or tokens may be redirected to an attacker-controlled endpoint
- An attacker may delete registrations and cause denial of service
- OAuth or OpenID Connect trust relationships could be weakened
General mitigation guidance
Mitigation should center on binding every registration-management credential to the specific client object being accessed.
Common defensive patterns include:
- Deriving the target client from the authenticated registration credential rather than trusting a separate request-controlled identifier
- Verifying credential-to-client ownership before every read, update, or delete operation
- Applying consistent authorization checks across all client configuration methods
- Rejecting mismatched client identifiers and registration credentials by default
- Restricting who may change redirect URIs and other security-sensitive metadata
- Running registration-management services with only the privileges they require
- Using explicit authorization policies and secure-by-default endpoint behavior
Mitigation should center on binding every registration-management credential to the specific client object being accessed.
Common defensive patterns include:
- Deriving the target client from the authenticated registration credential rather than trusting a separate request-controlled identifier
- Verifying credential-to-client ownership before every read, update, or delete operation
- Applying consistent authorization checks across all client configuration methods
- Rejecting mismatched client identifiers and registration credentials by default
- Restricting who may change redirect URIs and other security-sensitive metadata
- Running registration-management services with only the privileges they require
- Using explicit authorization policies and secure-by-default endpoint behavior
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis and code review checks for authorization decisions that use request parameters to select objects
- Review signals where an access token is validated for existence or general scope but not bound to the selected client
- Tests that attempt to use one client's registration credential against another client's identifier
- Policy enforcement requiring object ownership checks before read, update, and delete operations
- Audit-log analysis for cross-client registration access, unexpected redirect URI changes, and registration deletions
- Automated security review tools that flag missing object-level authorization and insecure direct object references
Organizations can identify this class of issue through:
- Static analysis and code review checks for authorization decisions that use request parameters to select objects
- Review signals where an access token is validated for existence or general scope but not bound to the selected client
- Tests that attempt to use one client's registration credential against another client's identifier
- Policy enforcement requiring object ownership checks before read, update, and delete operations
- Audit-log analysis for cross-client registration access, unexpected redirect URI changes, and registration deletions
- Automated security review tools that flag missing object-level authorization and insecure direct object references
