feat(config): disable device_code grant by default

[renechoi]

Overview

This PR introduces an opt-in switch for the OAuth 2.0 Device Authorization Grant (aka device_code) in Spring Authorization Server.
By default the grant is disabled, bringing the framework in line with the “secure-by-default” principle discussed in [#1709](#1709).

---

Motivation

• The Device Authorization Grant is purpose-built for devices that have limited input capabilities.
  Most new deployments of the Authorization Server target browser-based or mobile clients and do not require this flow.
• Exposing unused endpoints (/oauth2/device_authorization, /oauth2/device_verification) increases the attack surface and the number of code paths that must be audited.
• Disabling the grant unless explicitly requested mirrors the framework’s stance on other advanced or niche features (e.g. PAR being optional).

---

What changed

Area	Change
AuthorizationServerSettings	New flag deviceGrantEnabled (default false).
	Builder API: deviceGrantEnabled(boolean) – fluent opt-in.
Endpoint configurers	OAuth2DeviceAuthorizationEndpointConfigurer and OAuth2DeviceVerificationEndpointConfigurer now short-circuit their init() / configure() methods when the flag is false. No filters or providers are registered.
Global configurer	OAuth2AuthorizationServerConfigurer skips Device Grant matchers unless the flag is enabled; avoids null request-matcher issues.
Settings names	Added device-grant-enabled to ConfigurationSettingNames.AuthorizationServer.
Tests	Updated existing Device Grant integration tests to enable the flag explicitly. Added a new test asserting that the endpoints return 404 when the flag is left at its default value.
Docs / headers	All new code carries the Apache 2.0 header. Javadoc updated where relevant.

---

Opting back in

@Bean
AuthorizationServerSettings authorizationServerSettings() {
    return AuthorizationServerSettings.builder()
            .deviceGrantEnabled(true)   // <-- enable Device Grant
            // other custom settings …
            .build();
}

Once enabled, behaviour is identical to previous versions; no further changes are required in client or resource owner flows.

---

Backward compatibility

• Breaking change?
  No—deployments that actively use the Device Grant just need to flip one property. All other grants continue to function unchanged.
• Binary compatibility: Existing API signatures are untouched; only one boolean accessor/mutator is added.
• Semantic compatibility: If deviceGrantEnabled(true) is configured the runtime behaviour is byte-for-byte equivalent to current main.

---

Test coverage

• Happy path tests: All existing OAuth2DeviceCodeGrantTests now run with the flag enabled.
• Negative path test: New test requestWhenDeviceAuthorizationEndpointDisabledThenNotFound verifies that the endpoint is not exposed by default.
• CI: All modules compile and the full test suite passes (./gradlew check).

---

Upgrade notes

1. If your application relies on the Device Authorization Grant, add
   deviceGrantEnabled(true) to your AuthorizationServerSettings bean (see snippet above).
2. No migration is required for applications that do not use the grant; they are now more secure by default.

---

Related links

• Fixes Consider disabling device_code grant by default #1709
• OWASP “Secure by Default” principle: https://owasp.org/www-project-top-ten/

---

Checklist

• Code compiles (./gradlew clean build)
• All tests pass
• New functionality documented via Javadoc
• Commit signed (Signed-off-by) and follows Conventional Commit format

---

*Signed-off-by: renechoi [[[email protected]]