Asking the user for consent in device authorization grant is confusing and a workaround to meet RFC 8628
#41.396 geöffnet am 24. Juli 2025
Repository-Metriken
- Stars
- (34.398 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 6T 19h) (384 gemergte PRs in 30 T)
Beschreibung
Before reporting an issue
- I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.
Area
authentication
Describe the bug
When the device code flow is used, the consent screen is shown on every authentication. This is confusing and inconvenient for users, as consent for scopes is usually asked only once and stored. It was implemented o resolve https://github.com/keycloak/keycloak/issues/26100. While the consent screen is an additional step to prevent silent SSO, it does a poor job to fulfill ask the user for decision to proceed, as required by RFC 8628, section 3.3:
The authorization server should then inform the user about the action they are undertaking and ask them to approve or deny the request. Once the user interaction is complete, the server instructs the user to return to their device.
The main issue, is that it isn't clearly communicated to the user, that they should cancel the process, if they did not initiate the login process on their device. In addition the user should be able approve or deny the request with a "Proceed" and a "Cancel" button.
Version
26.3.0
Regression
- The issue is a regression
Expected behavior
The device code input screen should be shown and ask the user to confirm sign-in of the device or cancel. If verification_uri_complete is used, the device code should be filled but not editable.
Suggested screen:
According to the RFC, the screen should also include the client name (which is missing in the suggested screen).
On cancel, a screen without any options should tell that device login failed and browser can be closed.
Actual behavior
The consent screen is shown. A scope can be defined which tries to communicate the security risk
How to Reproduce?
Create a client with device authorization grant enabled. Call the authorization endpoint to start the device authorization. Open the verification URI provided.
Anything else?
No response