Setting requireAuthorizationConsent is ignored for device code grant

[antoinelauzon-bell]

Hi,

Unsure if it's a feature request or a bug, feel free to adjust the category.

Expected Behavior

As documented on the requireAuthorizationConsent setting, I would expect its value to be considered during a device code grant. For example, if the value is set to false, the consent page (that includes the user code and the scopes by default) should be skipped.

Current Behavior

In the case of the device code grant (OAuth2DeviceVerificationAuthenticationProvider class), the check only does a difference between the current scopes and the requested scopes. It means that the first time the flow is executed, the user has to accept the scopes (and confirm the user code). After that, if the scopes remain unchanged, the consent page is skipped.

OAuth2DeviceVerificationAuthenticationProvider (sadly not as customizable as the class below)
vs
OAuth2AuthorizationCodeRequestAuthenticationProvider

Context

I would like to be able to always skip the consent page. More precisely, the user code validation would be done in a separated page (like in your example). This page would then POST to the device verification endpoint (that would always skip the consent).

Thank you

[jgrandja]

@antoinelauzon-bell I've confirmed that there is no check for RegisteredClient.getClientSettings().isRequireAuthorizationConsent() to allow for skipping the consent page. This would be a fairly quick update but are you looking for something more flexible like what was implemented in OAuth2AuthorizationCodeRequestAuthenticationProvider gh-1541 ?

[antoinelauzon-bell]

Hi, thanks for the reply.

I think it would make sense to have a similar "authorizationConsentRequired" implementation between the OAuth2AuthorizationCodeRequestAuthenticationProvider and the OAuth2DeviceVerificationAuthenticationProvider. That is:

• Considering the isRequireAuthorizationConsent setting (as already documented)
• Skipping if OPENID is the only scope
• Skipping if the scopes are the same
• And mostly being able to replace the Predicate entirely

In our use case, only the first point would be enough. But it would be nice to have the flexibility of defining a custom Predicate.

[jgrandja]

@antoinelauzon-bell

I'll mark this as a bug since the isRequireAuthorizationConsent setting should be considered.

Would you mind opening a separate ticket for adding the Predicate enhancement?