Federated Login for httpMethod == "POST" fails

My org implements Federated login via Microsoft Entra which expects a SAMLRequest parameter in addition to a few others to be submitted to the idPUrl via a POST request.

The current implementation in https://github.com/XcodesOrg/XcodesLoginKit/blob/main/Sources/XcodesLoginKit/AppleSessionService.swift#L198-L223 will always build a GET style URL and open it in the browser which then results in a malformed request warning from MS Entra.

I have tested two solutions for the issue locally that both work but i am unhappy with both for different reasons. -> Opening this issue hoping someone has a even better idea.

Solution 1:
Host a local Web Server within XcodesLoginKit that serves a self submitting POST form and open that URL in the browser instead if httpMethod == "POST".

Works by letting us send the actual request POST from a users browser, rest of the flow proceeds as before.

->
Requires either a http server dependency or some manual TCP socket magic. Doable but increases the project scope by a lot in my eyes.

Solution 2:
Check for SAMLRequest parameter + httpMethod == "POST" in idpURL getter implementation and rewrite to GET based request.

Works because the Entra endpoint also accepts GET based SAMLRequests but has the caveat of having to base64decode -> deflate -> base64encode -> urlencode the SAMLRequest parameter into the required format for GET based requests.

->
Requires a code path that is specific to a single Federation provider, also might break other implementations if not guarded for correctly. Feels More hacky to me.

Both of these approaches do work but i am not really happy with the tradeoffs for either. Hoping someone else has a better idea 😅

If not i am also happy to upstream either solution.

Start in Sources/XcodesLoginKit/AppleSessionService.swift at lines 198-223 and trace how httpMethod, idpURL, and browser opening are handled. Compare the existing GET flow with the POST requirements described for SAMLRequest, then determine an implementation that supports the provider request without a provider-specific workaround or malformed browser request. Done means federated POST login proceeds successfully while existing GET login behavior remains intact.