providers/oauth2: require client_secret on device_code exchange for confidential clients

[SAY-5]

What

TokenParams.__post_init__ in authentik/providers/oauth2/views/token.py only ran the client_secret check for the authorization_code and refresh_token grant types:

if self.grant_type in [GRANT_TYPE_AUTHORIZATION_CODE, GRANT_TYPE_REFRESH_TOKEN]:
    if self.provider.client_type == ClientTypes.CONFIDENTIAL and not compare_digest(
        self.provider.client_secret, self.client_secret,
    ):
        raise TokenError("invalid_client")

The device-code path (__post_init_device_code) then looked up the DeviceToken purely by device_code and issued an access token whenever one matched — regardless of whether the caller had proved ownership of the confidential client:

def __post_init_device_code(self, request: HttpRequest):
    device_code = request.POST.get("device_code", "")
    code = DeviceToken.objects.filter(device_code=device_code, provider=self.provider).first()
    if not code:
        raise TokenError("invalid_grant")
    self.device_code = code

Per #20828 this is exploitable via the standard device-flow phishing shape (attacker starts device authorization, sends user_code to a victim, victim completes authorization, attacker redeems device_code): an attacker that only knows client_id can redeem a stolen device_code without ever proving ownership of the confidential client.

RFC 6749 §2.3.1 requires confidential clients to authenticate to the token endpoint; RFC 8628 §3.4 inherits that. The device_code is bearer-shaped but is not a substitute for client credentials. Keycloak and Okta both enforce client_secret on the device token exchange for confidential clients.

Fix

Add GRANT_TYPE_DEVICE_CODE to the list that already runs the compare_digest check:

if self.grant_type in [
    GRANT_TYPE_AUTHORIZATION_CODE,
    GRANT_TYPE_REFRESH_TOKEN,
    GRANT_TYPE_DEVICE_CODE,
]:
    if self.provider.client_type == ClientTypes.CONFIDENTIAL and not compare_digest(
        self.provider.client_secret, self.client_secret,
    ):
        raise TokenError("invalid_client")

• Public clients are unaffected (guard is gated on ClientTypes.CONFIDENTIAL).
• client_credentials / password keep their own client-auth path in __post_init_client_credentials (which also enforces the secret, plus supports client assertion).
• authorization_code / refresh_token paths are unchanged.

Test plan

• Repro on main: configure an OIDC provider with client_type: confidential, run a device flow, POST /application/o/token/ with only client_id=...&device_code=...&grant_type=urn:ietf:params:oauth:grant-type:device_code — gets an access token.
• With this patch applied: same request returns {"error":"invalid_client"}; the request with the correct client_secret (or a valid Authorization: Basic ...) still succeeds.
• Public clients: same request without client_secret still succeeds (unchanged behaviour).

Fixes #20828

[netlify]

✅ Deploy Preview for authentik-docs ready!

Name	Link
🔨 Latest commit	38251b9
🔍 Latest deploy log	https://app.netlify.com/projects/authentik-docs/deploys/69e55a291f0b4c00082eeefd
😎 Deploy Preview	https://deploy-preview-21700--authentik-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.