Doorkeeper Improper Authentication vulnerability

Vulnerability

Doorkeeper prior to version 5.6.6 automatically processes authorization requests without re-prompting for user consent for public clients that have been previously approved [1]. This behavior is problematic because, as noted in RFC 8252, public clients (e.g., native apps) cannot reliably prove their identity, making them inherently vulnerable to impersonation [1]. The underlying issue is that Doorkeeper did not differentiate between confidential and public clients when determining whether to skip consent for previously approved applications [2].

Exploitation

An attacker can exploit this by impersonating a legitimate public client, such as a native mobile application. If the victim user has previously authorized the legitimate client, Doorkeeper will automatically approve the attacker's authorization request without any user interaction [2]. The attacker only needs to know the client_id and a valid redirect URI to initiate the attack. No additional authentication or user consent is required at the time of attack.

Impact

Successful exploitation allows the attacker to obtain an authorization code or access token, thereby gaining access to the user's protected resources via the OAuth 2.0 protocol [3]. This can lead to unauthorized data access or actions on behalf of the user, potentially compromising sensitive information.

Mitigation

The issue is fixed in Doorkeeper version 5.6.6 [4]. All users are advised to upgrade to this version or later. There is no known workaround for earlier versions. Administrators should review their OAuth client registrations and ensure that public clients are configured appropriately, but upgrading is the primary remedy.