# Use discourse for SSO in a non-web app?

**URL:** <https://meta.discourse.org/t/use-discourse-for-sso-in-a-non-web-app/40584>\
**Category:** Development\
**Created:** [2016年三月4日 18:46 UTC](https://meta.discourse.org/t/use-discourse-for-sso-in-a-non-web-app/40584 "2016-03-04T18:46:50Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![DeanMarkTaylor](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/deanmarktaylor/32/102462_2.png) [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)\
**Post date:** [2016年三月4日 20:04 UTC](https://meta.discourse.org/t/use-discourse-for-sso-in-a-non-web-app/40584/3 "2016-03-04T20:04:19Z")

</div>

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)](https://meta.discourse.org/t/using-discourse-as-a-sso-provider/32974):
>
> So you want to use Discourse as an identity provider for your own web app? Great! Let’s get started. Enable [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 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](https://meta.discourse.org/t/13045?silent=true) in your web app: Generate a random [nonce](https://en.wikipedia.org/wiki/Cryptographic_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.

1. Displaying the in-app browser window

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

1. 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`

1. 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`

1. Check the [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) 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`

1. 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.

---

_[View the full topic](https://meta.discourse.org/t/use-discourse-for-sso-in-a-non-web-app/40584)._