Automatic login from Windows Application


#1

Apologies if this has already been solved. I’ve searched and read all posts that I thought would match.

We have a multi-user windows application with SQL Server back-end and a separate Discourse instance. We don’t use SSO or OAuth.

We want to automatically provision Discourse users from our application.
It looks like we can use the API to do this and auto-generate API Keys for each user, and store the API key in the database against the user record.

We now want to have a menu option (in the windows application) that will launch the default browser and use the logged in user (and api_key) to automatically log into Discourse for that user.

Does anyone know what mechanism can be used to achieve this?
What endpoint can be used?

Many thanks for any assistance that can be given.


(Sam Saffron) #2

I would look into user api keys, they were designed for this exact use case.


#3

Thanks for your response.

Generating API keys for users is not the main issue we face.

We need to know:

  • given the user has already logged into our application (Windows or Web)
  • how to provide a user with a “link” that will automatically log them into the Discourse instance, without prompting them to log into Discourse again.

(Sam Saffron) #4

This is why you should read that topic carefully


#5

Thanks Sam.

I have read the topic carefully.

I’m not trying to use the API for remote access to Discourse data.

I’m trying to automatically log into Discourse from another application.
The end result is that the user is automatically logged into Discourse without having to enter their username and password.

I’m sure that someone else has had this requirement and has a solution?


(Felix Freiberger) #6

If the Discourse instance is only for users of your application, I’d look into implementing SSO with a small middleware that checks whatever authentication form the app or web front end use, and then signs the SSO payload.


#7

Unfortunately SSO is not an option for us.
We have a commercial product that is installed in 300+ clients and a single Discourse instance to provide a forum for our users.
From each client install of our product we want to automatically log the user into the Discourse instance.


(Felix Freiberger) #8

Is there any central point of trust? Without it, this is going to be very difficult.


#9

Each client is licensed to use our product.
When the user logs into their instance of the product on their site (on-premise) we want to provide the user with a menu item/link to open a browser and automatically log into our Discourse instance without having the user needing to enter their username/password for Discourse.

We thought we could use the API to provision the user account, and generate the api_key for the user, automatically.


(Felix Freiberger) #10

That will be troublesome, because it looks like you don’t have a centralized point of trust yet.

You can certainly hack something together with the API, but I’d guess that this needs a custom plugin. Building a custom, central SSO endpoint may be easier, depending on your infrastructure.

Either way, this will need some difficult custom development.


(Rafael dos Santos Silva) #11

This is probably a very bad idea, but What If:

Your desktop app could listen to traffic in a higher port (like 8080) locally for every customer, and Discourse was configured to SSO with localhost:8080. Wonder if that would work… :thinking:


(Felix Freiberger) #12

Very bad indeed, because the SSO secret would have to be baked into the application.
Unless the app would then proxy the requests to a central service – but that service could handle SSO directly :thinking:


(Rafael dos Santos Silva) #13

Yeah, this was just thinking aloud in a what if YOLO way. But if he is selling this software and it’s desktop software he may have code obfuscation, and many layers to protect their IP. (Wild guess never worked in this area).


(Sam Saffron) #14

you know how you don’t bake any secrets into an application, BY USING THE USER API.

It really is quite simple:

  • User launches your application
  • You launch a web browser to Discourse in an embedded browser with a return URL that is intercepted by your app
  • User authorizes your app to access Discourse
  • Discourse opens the intercepted URL with the encrypted payload
  • You have a user api key that your app can use.

(Felix Freiberger) #15

I’m sorry, but I don’t get it. If I understand both you and @gwhite correctly, this is the exact opposite of what @gwhite wants to do.

The user API offers:

  • The user signs in with local Discourse credentials, in Discourse’s web UI.
  • Afterwards, the app can use the API to programmatically interact with the user’s Discourse account.

@gwhite wants:

  • The user signs in within his application, with credentials belonging to this third-party application.
  • The application fires up a browser where the user is logged into Discourse with a corresponding user account and can use the Discourse web application.

And this looks like the use case that is solved with SSO. Im I misunderstanding something?