Getting a token is the hard part of feed discovery, not the GET. AVD Feed + Connect runs the OAuth2 authorization-code flow with PKCE inside an embedded WebKit view, which the developer describes as the same flow the official clients use [11]. The reason given is specific: many tenants run Conditional Access policies that block the device-code flow, and device code is what most CLI tools reach for [12]. The cheap implementation, print a code and send the user to a browser, therefore fails at sign-in in exactly the locked-down tenants that buy AVD in the first place.
With a token in hand, the app calls rdweb.wvd.microsoft.com/api/arm/feeddiscovery, and because the service checks for an approved X-MS-User-Agent value, the app sends one it accepts [13]. The response carries the workspaces, the resources and their icons [14]. A double-click downloads that resource's .rdp and launches a bundled sdl-freerdp with /gateway:type:arm /sec:aad [15]. Those two flags have been in recent FreeRDP builds for a while [4], which is the whole argument for where the gap was: the protocol was handled, and the per-resource gateway address and identity that live inside each feed-issued .rdp file were not, because nothing on Linux fetched them [5][6]. Access tokens are renewed with the standard refresh_token grant and offline_access, so a session does not re-prompt every hour [16].
The bundling decision is the part I would have pushed back on at review, and the reasoning holds up. Shelling out to whatever xfreerdp sits on PATH inherits two defects that surface during Teams calls [18]. Plugging or unplugging headphones mid-call can drive the PulseAudio backend into a busy loop in rdpsnd that freezes the whole session; the bundled build carries the fix from FreeRDP#13334 [19]. Stock builds also have no camera redirection, so this one is compiled with CHANNEL_RDPECAM_CLIENT, with microphone and multi-monitor enabled [20]. Packaging as a Flatpak pins that exact build regardless of distro, and keeps it from colliding with a system FreeRDP used for other work [21].
Adopting it means taking on three moving parts with one person behind them: a signed remote on GitHub Pages that normal flatpak update pulls from [22], a FreeRDP build carrying a patch, and an embedded browser view that handles enterprise credentials [11].
For the sign-in claim to transfer to your tenant, your Conditional Access configuration has to be the kind the post actually exercised. It reports working where policy blocks the device-code flow [12]. It does not report behaviour under a policy that requires a compliant device or an approved client application [26].
The developer's own line about the alternative is the fairest sentence in the post: the web client is what you fall back to when you have given up [28]. That is the bar here, and on local audio devices, camera, multi-monitor and clipboard richness the native client clears it [7]. What the write-up leaves unsettled is who rebuilds the Flatpak the week a new FreeRDP release changes behaviour underneath it [25].
