We are adding modern authentication (OAuth/OIDC) to an application that currently uses Windows integrated authentation for single sign on. The user signs into Windows workstation and those credentials can be used by many applications with authentication happening transparently over Kerberos.
Our app is a dot net web services based application and we have a client for users with browsers and a desktop client in WinForms. The browser scenario is no issue as the identity provider stores information in the browser that can be reused across applications in a similar way to WIA (IWA), but we are unsure the best way to handle the WinForms desktop application case. Currently the WinForms application opens a browser window to authenticate using the typical browser based method. The details from the identity provider are passed through the browser back to the WinForms app using a redirect and a custom protocol based URL.
This all works fine, but the user experience is not super tight and, for the case where the user is already logged in, requires them to press a button in the browser window as current Chromium based browsers seem unwilling to do a redirect without a recent user interaction.
Is there a better way?
The standard options according to RFC8252 are as you describe:
I have a few blog posts about this and it is a tricky flow. The posts link to code examples you can run that explore the UX a little. You may find that a loopback URL avoids the need for a button click, though personally I think private scheme based URLs are cleaner.
There are UX things you can do, such as an interstitial web page to better control what happens in the disconnected browser. I have seen companies redirect to their own website after desktop logins, to make the UX better.
In the longer term I expect this to be replaced with API Driven OAuth Flows so that you never need to leave the app. For now you may have to live with some UX linitations, but it is the right flow from a security viewpoint.