SAML, setting ACS Url to localhost for desktop app

We have a desktop application which will need to support SAML authentication. The UI layer is already running on electron, so the simple approach would be to just use electron, create a tab/window with the SAML provider URL, grab the SAML token and send it to the our service.

However, what I'd like to achieve is to make it smoother for the user through single-sign-on so to speak. It is very likely that the user has already logged into the SAML provider on their default browser. But running default browser means I have no control over it and I can't intercept the SAML token. So, I came up with this approach:

• When the SAML connector (not sure what they are called really) is being configured, we tell the administrators to set the "ACS (Consumer) URL" to http://127.0.0.1:1234/saml instead of the actual consumer.
• Desktop app starts the default browser with the SAML provider's single-sign-on URL.
• The user authenticates, or is already authenticated on the browser.
• Browser is redirected to http://127.0.0.1:1234/saml with the SAML token.
• Desktop app, running a tiny HTTP service, grabs the token and uses as it wishes (using it for oauth); and return window.close(); to the browser.

Is there any holes I'm missing? Is setting "ACS (Consumer) URL" to localhost against SAML good practices? Can it be considered bad for security?

I will post an answer 8 years later as I am now confident that this is a common flow. Practically all the most common SAML providers now allow http://localhost as an exception to "only https links" rule for I imagine supporting this use case.

OIDC addresses this using custom URI handlers instead but also has the same exception.