[RESOLVED] OAuth2 and desktop app

I'm trying to implement an OAuth2 solution, hopefully using a somewhat older framework, though that's not essential. This is something I have zero experience with, and I'm not sure our organization is all that on top of it, either. The guy who primarily implemented our identity server left, which may leave us with tools and not a complete understanding of how to use them.

I've been following the sample code from Google in this link:

https://developers.google.com/identity/protocols/oauth2

but it has left me unclear on one issue. I have a client ID from our identity server, and it appears that I should be putting up a web page to get credentials, but no example I have seen actually does that. So I'm unclear as to whose role that is. Am I to show a page for username and password, or is that something the identity server does? I get only vague answers from the one person we still have who has any understanding of this, so I felt somebody on here might be able to clarify this.

I think peterst had a good example about ..credentials..username and password

I can't remember which Thread it was, perhaps he can chime in

You have to provide UI for entering of user ID and password (secret). Our projects are different types - console, winforms, web, so there are different login UI libraries that can be referenced. Also login info can be stored in file with secrets - useful for some tools where no interaction is required.

For public web apps it is possible to redirect to Google, Facebook, Microsoft web login page for OAuth2 and provide redirect back link to return to your web page, but it is another case. But this requires registering your app in their dev consoles or do configure other specific settings.

You can check Google examples here. The first example uses ID/secret from json file, but the second shows how to use in your app:

C# Code:

credential = await GoogleWebAuthorizationBroker.AuthorizeAsync(
    new ClientSecrets
    {
        ClientId = "PUT_CLIENT_ID_HERE",
        ClientSecret = "PUT_CLIENT_SECRETS_HERE"
    },
    new[] { BooksService.Scope.Books },
    "user",
    CancellationToken.None,
    new FileDataStore("Books.ListMyLibrary"));

So you decide how to get the ID and secret to "put it here and there".

That ID I already have. There is a client ID registered for the program. There isn't a client secret on the principle that a desktop application can't keep a secret (or at least you can't trust it to, so why bother having one?).

I had written more, but after a bit more investigation, I've pulled that back. I believed my thinking on this was more wrong that it was. I think I've been looking at the wrong problem. I had written a lengthier reply with the right problem, but I still have a bit more studying to do before I'm ready to post that.

Well, once again I find that writing things out makes all the difference.

The redirectURI was wrong, everything else was right. I had a few pages written here, but I'll spare you, because while writing, I tried a variety of things, always creeping closer to the answer. With each small step, I gained a bit of insight, and then it worked up to a point. The key is that redirectURI, and I'm not sure how to set it correctly, or if I can.

What I'm using is this:

Code:

---

Dim redirectURI = String.Format("http://{0}:{1}/", IPAddress.Loopback, GetRandomUnusedPort())

---

That comes from the Google example. This will end up with a redirect that looks like:

http://127.0.0.1:60524/

which can be then set into the prefixes like so:

Code:

---

Dim Http = New HttpListener()
Http.Prefixes.Add(redirectURI)

---

But, I no combination of that URI works for registering the application. I can't be including the random port, but no variation of the URI with or without the port has yet been acceptable.

In the working example I have, they use http://localhost/winforms.client. That works fine as far as the identity server recognizing the application, but naturally, the browser isn't happy with that, since it's not being redirected to where the HttpListener is listening.

So, I guess my question is what redirectURI should be registered for this to work?

Check out StackExchange authentication API description as it has the full workflow steps.

The big problem with authentication services, even they are using some "standard", are implemented differently. And to be painful for desktop apps devs - most public ones work only with callback URL so you must have public web service too. Some are implemented also to be used from desktop apps like the Google ones from the examples above.

So it really depends how the identity server you use is implemented. By registering an application to use them, then using app secrets, redirect to login of the identity server, return back to callback URL... Or just by calling the API with user/pass and get the token to use the other APIs.

I probably completely edited my reply while you were writing this.

I'll add one other point:

I have a working example, which is somewhat overwrought, uses a series of third party items, and uses features that are in more recent frameworks. I'd like to stick with FW 4.0 for the application, since changing that would cause me just a bit more pain, and doing it solely to take advantage of some examples just doesn't seem justified. Still, it's a working example.

What they are doing in the working example is using a webbrowser as a component in a windows form (in about as awkward a fashion as I have ever seen, but at least I don't have to understand why they did that). Therefore, their redirect is as noted previously. It's not just the browser, it's A browser in a form. I can do that, but it seems unnecessary.

What I see is that it is made to be used by web apps and for desktop devs to use strange methods like the web browser component which will show you the identity/auth server login page (served by the identity server itself) and then to redirect to your server URL. I am not sure if you can replace the browser component as you have to render the login web page served by identity server.

If you have access to the identity server source, you can check if it provides some other APIs which can be used without manual user login.

About .NET Framework 4, I think you can rewrite everything without any problems. For our projects we decided to support what Microsoft supports of .NET frameworks but then we moved to 4.6.1 and now waiting to see how the migration may go with .NET 5 as .NET Core apps where the installed framework is not important.

The authentication server I've created is not standard one (OAuth2 compliant) but it uses similar ideas like the JWTs. The API is created to be used mostly by desktop apps in non-public environment (local networks and VPNs). Redirection (callback URLs) is not required as every app can decide how to store the secrets or to have own login UI.

Well, I can rewrite the component for the form without much difficulty, in which case it should work the same way.