[Core feature] Device authorization grant (RFC 8628) in flyteadmin's built-in authorization server #8086

Motivation: Why do you think this is important?

flytectl and flytekit both implement the OAuth 2.0 device authorization grant (authType: DeviceFlow, flyteidl #313). They discover the device endpoint from flyteadmin's OAuth metadata (GetOAuth2Metadata, /.well-known/oauth-authorization-server). flyteadmin's built-in authorization server (authServerType: Self) never advertises one and does not implement the grant, so on a deployment that uses the built-in server the device flow cannot start. The only way to log in from a host without a browser is a browser-less workaround, an external authorization server, or a patched client.

This comes up regularly: How do I setup device code authentication, #5084, and the reason I opened #8080 and #8081. Moving to an external authorization server is a large change when the deployment only needs headless CLI login, and it is not an option when the IdP has no client_credentials grant for the in-cluster components (Dex, for example).

Goal: What should the final outcome look like, ideally?

With authServerType: Self:

• the metadata response includes device_authorization_endpoint
• flyteadmin implements RFC 8628: a device authorization endpoint that issues device and user codes, a verification page that reuses the existing /login OIDC flow and records the approval, and the urn:ietf:params:oauth:grant-type:device_code grant at the token endpoint
• the default flytectl public client allows that grant type

Stock flytectl and flytekit then work with authType: DeviceFlow and no client change, and they receive flyteadmin's own access and refresh tokens like the PKCE flow does today.

Describe alternatives you've considered

• Let clients run the device flow against the OIDC provider and send ID tokens #8080: the Go client runs the device flow against the OIDC provider directly and sends the result as IDToken. Fixes flytectl only; flytekit would need the same change in Python.
• Accept OIDC ID tokens presented with the Bearer scheme #8081: flyteadmin accepts an OIDC ID token presented as Bearer. Lets any client that can obtain an ID token out of band log in, but each client still needs its own way to run the device flow.
• A proxy in front of flyteadmin that rewrites the metadata to point at the OIDC provider's device endpoint and rewrites Bearer to IDToken for provider-issued tokens. Works today with stock clients, but every deployment has to build and run it.
• authServerType: External. Heavy, and it moves client_credentials for propeller and friends to the external IdP, which some IdPs do not support.

Propose: Link/Inline OR Additional context

flyteadmin pins github.com/ory/fosite v0.42.2. fosite added RFC 8628 in v0.47.0 (handler/rfc8628, compose.RFC8628DeviceFactory, compose.RFC8628DeviceAuthorizationTokenFactory), so the grant itself is a fosite upgrade plus two factories in auth/authzserver/initialize.go. The pieces that need design:

• storage for device and user codes, since flyteadmin's authorize codes are stateless encrypted JWTs and the device grant needs to look a user code up
• the verification page (/oauth2/device) that runs the existing OIDC login and marks the code approved
• DeviceAuthorizationEndpoint in the self server's metadata provider

I am happy to contribute this if the approach is acceptable. #8080 and #8081 stand as the smaller alternatives.

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes