Advisories for Pypi/Oauthlib package

OAuthlib's token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied client_id from the request body. In affected token grant flows, authenticate_client(request) sets request.client to the authenticated client object, but OAuthlib does not require request.client_id to match request.client.client_id. If the request body already contains client_id=…, OAuthlib keeps that value and passes it to validate_grant_type() and validate_scopes(). As a result, an authenticated …

A call to the token endpoint with a grant type of "urn:ietf:params:oauth:grant-type:device_code" and a bogus device_code is able to get a bearer token as long as they know a valid client ID enabled for the device workflow.

A timing side-channel vulnerability exists in the PKCE (RFC 7636) implementation of the Authorization Code Grant flow. The code_challenge_method_plain function uses Python's standard == operator for string comparison instead of a constant-time comparison function, potentially allowing timing-based attacks.

When enable_jsonp=True, oauthlib's RevocationEndpoint reflects the user-supplied callback parameter directly into JavaScript response bodies on both success and error paths without validating that it is a legal JSONP callback name. This allows arbitrary JavaScript response generation instead of a restricted function call, making the documented JSONP revocation feature unsafe for browser-based JSONP consumption when attackers can influence callback.

Attacker providing malicious redirect uri can cause DoS to oauthlib's web application. Attacker can also leverage usage of uri_validate functions depending where it is used. What kind of vulnerability is it? Who is impacted? Oauthlib applications using OAuth2.0 provider support or use directly uri_validate function.