Best practice for authentication in a C# desktop exe

Questions
1

We are developing a c# desktop client for use on windows machines. We would like to have the users authenticate to Okta natively in the app. What is the best practice for login verification?

Thanks!

2

Hello,

For native applications, the preferred way would be to launch/embed a browser and redirect to your Okta Org login screen. Have the native app startup a temporary http server to handle the browsers redirect call back with the authorization code and exchange it for tokens.

You might want to look into this IdentityModel sample to see if it accomplishes what you need.
I have run the sample in the past and it seemed to work fine from the short amount of testing I did.
You would just need to update the Authority/ClientId/(possibly Scopes) in this file.

If coding the flow yourself you can use this as a reference, which is done in Node but the same logic applies.

Thank You,

3

Starting a temp HTTP server is probably a non-starter because that requires elevated permissions on Windows and would be a pretty big security hole.

It appears that the PKCE sample still requires a browser launch, which is clunky.

Is there really no native library for authentication? With AD I’m able to use NTLM or even LDAP. I would like to create a seamless experience for the user (this is a CRM app being used in a call center) and launching a browser will be problematic.

We could also do this server side, where the credentials are passed securely to our server and then the server does the auth. The servers are C# based services running on Windows. Is there any solution that is more “API based”?

Thanks,
Shaun

4

There probably are various libraries that would do what you are looking for but I am not aware of them and Okta does not provide one for this use case.

When doing an authorize code flow it is always preferable to launch a browser for a user to enter their credentials at the IdP login screen.

  • this is a known endpoint to the end user so they trust it
  • the credentials are not passed through the application (which could be a security issue)

Different apps will have different security requirements and the above may not apply. The following sample builds on the prior Node sample I provided before. This version does not launch a browser and instead does the authn and makes the authorize call with a native http client.

It does still open a web server to handle the redirect for the native http client on the authorize call, but you could easily skip doing this and instead configure the http client to not redirect and instead parse out the location http header to get the code/state values.

1 Like