Use discourse for SSO in a non-web app?

[DeanMarkTaylor (Dean Taylor)]

Here is one way, there are probably security implications that are deeper than this to think about - but this should give you the gist.

unless i’ve forgotten something important

A few apps that work like this run a “mini web server” inside themselves on a non-fixed port (i.e. it finds the first free port).

Effectively turning app into a web app.

See the this thread regarding using Discourse as an SSO provider:

Use Discourse as an identity provider (SSO, DiscourseConnect)

So you want to use Discourse as an identity provider for your own web app? Great! Let’s get started. Enable DiscourseConnect provider setting Under Discourse admin site settings (/admin/site_settings) enable setting enable discourse connect provider and add a secret string to discourse connect provider secrets (used to hash SSO payloads). Implement DiscourseConnect in your web app: Generate a random nonce. Let’s call this value NONCE. Save it temporarily so that you can verify it with the …

You’ll need to think carefully about avoid leaking sso_secret - hence the introduction of YOUR_SERVER in the process flow below. But you don’t just want to recreate the problem further along the chain.

The process follow looks something like this:

1. Start internal HTTP server (LOCAL_SERVER)

• finding first free port > 1024 so you don’t need admin rights.

2. Displaying the in-app browser window

• this browser windows will effectively just loads https://YOUR_SERVER/some-path/?somesecurityA=somevalueA

3. Generate the redirection URL (YOUR_SERVER)

• Have your own web site (a simple PHP site will do) - this is not inside the app
• This is responsible for keeping your sso_secret secret and playing it’s part in generating the return_sso_url
• You’ll need to manage the security here carefully to pass the minimal amount of details (port number) each way between the app and YOUR_SERVER and securing your server from abuse i.e. somesecurityA=somevalueA.
• perhaps always assume localhost is a part of the security measure.
• generate the appropriate Discourse return_sso_url URL - this will some URL like YOUR_SERVER/check-discourse-response?somesecurityB=somevalueB
• redirect to DISCOURSE_ROOT_URL/session/sso_provider?sso=URL_ENCODED_PAYLOAD&sig=HEX_SIGNATURE

4. User signs into Discourse in the in-app browser window

• On success the user will be redirected to YOUR_SERVER/check-discourse-response?somesecurityB=somevalueB

5. Check the Discourse SSO response (YOUR_SERVER)

• Check the security values etc i.e. somesecurityB=somevalueB
• On success redirect to localhost:{port_number}/another-path/?some-other-security=some-other-value

6. Handle HTTP request response to the local in-app web server (LOCAL_SERVER)

• actually check any security measures you have.
• do something nice like close the auth dialog automatically.

Doing this you’ll get support for whatever SSO providers your Discourse instance has setup i.e. Google, Twitter, Facebook, GitHub etc.