# 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:** [March 4, 2016, 6:46pm 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:** 11

<div class="post-metadata">

**Author:** ![chris\_beck](https://avatars.discourse-cdn.com/v4/letter/c/a88e57/32.png) [@chris\_beck](https://meta.discourse.org/u/chris_beck)\
**Post date:** [March 9, 2016, 4:50pm UTC](https://meta.discourse.org/t/use-discourse-for-sso-in-a-non-web-app/40584/11 "2016-03-09T16:50:49Z")

</div>

So, as a followup, which may be helpful to who searches for this question:

What I have ultimately decided to do is, just implement SSO separately in my app as originally suggested. Sending password recovery emails and such is actually not too hard, it doesn’t require you to operate your own SMTP server which is what I originally feared. Indeed discourse doesn’t have an internal SMTP server either.

By implementing SSO on my own, I can make an interface which is customized for my app and which I know is stable and easy to use, (rather than relying on implementation details of discourse’s basic SSO which I assume are subject to change anyways), and then make a separate web interface matching the requirements of discourse.

There are definitely pitfalls associated to trying to roll your own auth / security, esp. for a small team with not a lot of expertise in this, but if you rely on SSL for crypto, as you should, then the majority of the problem is already solved, it seems.

Especially, there’s no particular need to use some large enterprise solution for this in a small project, afaict.

---

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