OIDC client with local HTTP listener stuck

[Remo]

I've been playing around with this example: https://github.com/DuendeSoftware/foss/blob/main/identity-model-oidc-client/samples/HttpSysConsoleClient/HttpSysConsoleClient/Program.cs#L55

It's a pretty slick approach to start a local webserver and then redirect there. It works very well, only when we close the browser instead of logging in, the code is stuck at line 55

It's waiting to get a feedback via HTTP listener and never receives a message. The only idea is to put this inside another thread and then wait for the process to close. If it does, we stop the HTTP listener and exit with an error code, otherwise if we get an HTTP request, we terminate the process somehow and return the login result.

It feels a bit hacky, any better ideas?

[wcabus]

Based on the sample you're looking at, I suggest adding a .WaitAsync(TimeSpan.FromMinutes(10)); onto the http.GetContextAsync() call. WaitAsync allows you to specify a timeout interval, either using a TimeSpan or a CancellationToken, and will throw a TimeoutException if the awaited task does not return before the timeout interval is reached.

As a bonus, I would also start the task before opening the browser, and await the task afterwards to ensure that we're listening for the response before the response potentially already happened:

// start the task before opening the browser in case we return immediately when the user still has an active session
var contextTask = http.GetContextAsync();
    
// open system browser to start authentication
Process.Start(new ProcessStartInfo
{
    FileName = state.StartUrl,
    UseShellExecute = true,
});

HttpListenerContext? context = null;
try
{
    // wait for the authorization response.
    context = await contextTask.WaitAsync(TimeSpan.FromMinutes(10));
}
catch (TimeoutException)
{
        
}

if (context is null)
{
    Console.WriteLine("\n\nError:\n{0}", "The operation timed out while waiting for the authorization response.");
    return;
}

That said, while using the HttpListener for listening to the redirect works, there are more secure ways to implement authentication in a native client:

• Using a custom URI scheme to redirect back to your application, by registering the URI scheme when installing the app (or at startup, like in the sample): https://github.com/DuendeSoftware/foss/tree/main/identity-model-oidc-client/samples/Wpf
• Registering a callback scheme as an app when distributed via a store (Google Play, Apple App Store, Microsoft Store): https://github.com/DuendeSoftware/foss/blob/main/identity-model-oidc-client/samples/Maui/MauiApp1/MauiApp1/Platforms/Android/WebAuthenticationCallbackActivity.cs

[Remo]

Thanks for your detailed answer!

• Custom URI scheme: I didn't like this because it starts a new process and we would either have to have two processes talking to each other, or save the whole state and then reopen the app. That's why I liked the HTTP listener approach
• Adding a timeout would partially work, but my app still doesn't know that the browser was closed until the timeout has run down.

[wcabus]

As long as the browser is external to your codebase, the application can never truly tell if the browser (tab) was closed. You're also not starting the browser process yourself in this sample; you're creating a process that launches a URL, which causes Windows to start your default browser.

If you're building a desktop application, however, you could open a WebView control to authenticate and keep the flow inside the application: https://github.com/DuendeSoftware/foss/blob/main/identity-model-oidc-client/samples/WpfWebView2/WpfWebView2/WpfEmbeddedBrowser.cs

[Remo]

Thanks! We didn't use that because our users are already logged in to the application from where we get the token. Using a WebView2 control would require them to log in again which we tried to avoid.

[wcabus]

In that case, I'm afraid I see no other alternative than using a timeout or showing a dialog to allow the user to cancel the flow in the app.

[wcabus]

After doing a bit more research, I found that using a Webview approach is no longer recommended for performing OAuth authorization requests. This is mostly because native apps can then steal a user's credentials while they're entering them within the embedded Webview.

Regarding your concerns about custom URL callbacks and multiple instances being invoked, perhaps this sample is a better fit: https://github.com/DuendeSoftware/foss/tree/main/identity-model-oidc-client/samples/WindowsConsoleSystemBrowser/WindowsConsoleSystemBrowser

It won't fully solve your problem when the user closes the browser, for that I still recommend using a timeout or showing an "Authenticating..." dialog with a cancel button to allow the user to cancel the operation in the app.

[Remo]

Wow, thanks for being so engaged!

That examples with the named pipe is a neat way to send the data back to the original process. I'll keep this in mind!