Federated Login for httpMethod == "POST" fails

Comienza en Sources/XcodesLoginKit/AppleSessionService.swift, en las líneas 198-223, y sigue cómo se gestionan httpMethod, idpURL y la apertura del navegador. Compara el flujo GET existente con los requisitos POST descritos para SAMLRequest y determina una implementación que admita la solicitud del proveedor sin un workaround específico del proveedor ni una solicitud de navegador malformada. Se considera terminado cuando el inicio de sesión federado mediante POST funciona correctamente y el comportamiento existente del inicio de sesión mediante GET permanece intacto.

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.