🐛 Bug Report: Device Code flow should not require a client secret #171

New Issue

OVERLORD · 2025-10-09T16:30:33+03:00

OVERLORD commented

2025-10-09 16:30:33 +03:00

Originally created by @ItalyPaleAle on GitHub.

Reproduction steps

When using the Device Code flow with Pocket ID, calls to the /api/oidc/device/authorize require a client_secret

Expected behavior

Per RFC 8628 sec 3.1 the device authorization request endpoint should not require a client secret. This is because clients are assumed to be public.

Section 5.6 calls this out:

Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials.

Actual Behavior

Client secret is required

Version and Environment

main branch

Log Output

No response

Originally created by @ItalyPaleAle on GitHub. ### Reproduction steps When using the Device Code flow with Pocket ID, calls to the `/api/oidc/device/authorize` require a `client_secret` ### Expected behavior Per [RFC 8628 sec 3.1](https://datatracker.ietf.org/doc/html/rfc8628#section-3.1) the device authorization request endpoint should not require a client secret. This is because clients are assumed to be public. [Section 5.6](https://datatracker.ietf.org/doc/html/rfc8628#section-5.6) calls this out: > Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. ### Actual Behavior Client secret is required ### Version and Environment main branch ### Log Output _No response_

OVERLORD added the bug label 2025-10-09 16:30:33 +03:00

OVERLORD closed this issue

2025-10-09 16:30:34 +03:00

OVERLORD commented

2025-10-09 16:30:36 +03:00

@ItalyPaleAle commented on GitHub:

Right now it's possible to pass a client secret and the OidcDeviceAuthorizationRequestDto struct has a property for it. And if you pass one, it's validated. Should maybe be removed entirely, and throw an error if client isn't public?

@ItalyPaleAle commented on GitHub: Right now it's possible to pass a client secret and the `OidcDeviceAuthorizationRequestDto` struct has a property for it. And if you pass one, it's validated. Should maybe be removed entirely, and throw an error if client isn't public?

OVERLORD commented

2025-10-09 16:30:38 +03:00

@kmendell commented on GitHub:

Correct, You need to check the Public client option to use the device code properly. Im not sure this is a bug but maybe a documentation issue, as when if a public client is used everything works correctly.

@kmendell commented on GitHub: Correct, You need to check the Public client option to use the device code properly. Im not sure this is a bug but maybe a documentation issue, as when if a public client is used everything works correctly.

OVERLORD commented

2025-10-09 16:30:38 +03:00

@stonith404 commented on GitHub:

Clients that use the device code flow can also be confidential, and if they are, they require a client secret. In section 3.1:

The client authentication requirements of Section 3.2.1 of [RFC6749] apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint, and public clients provide the "client_id" parameter to identify themselves.

This probably means that we would also have to implement federated client credentials for this endpoint, right?

@stonith404 commented on GitHub: Clients that use the device code flow can also be confidential, and if they are, they require a client secret. In section 3.1: > The client authentication requirements of [Section 3.2.1 of [RFC6749]](https://datatracker.ietf.org/doc/html/rfc6749#section-3.2.1) apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint, and public clients provide the "client_id" parameter to identify themselves. This probably means that we would also have to implement federated client credentials for this endpoint, right?

OVERLORD commented

2025-10-09 16:30:39 +03:00

@ItalyPaleAle commented on GitHub:

Thanks I missed that paragraph. Yes we would need to add federated credentials there too, I can update my latest PR.

@ItalyPaleAle commented on GitHub: Thanks I missed that paragraph. Yes we would need to add federated credentials there too, I can update my latest PR.

OVERLORD referenced this issue

2025-10-09 17:00:04 +03:00

[PR #175] [MERGED] fix: add `__HOST` prefix to cookies #935

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-2#171