Discourse as the SSO provider


(Daniel Hollands) #1

Apologies if this is answered somewhere else (I’ve looked, but so far not been able to find), but can someone point me in the direction of using Discourse as an SSO provider?

I see there are lots of posts about allowing Discourse to use other applications as the SSO provider, but I want the reverse of this. I have plans to my use Discourse install as the central hub of a network of microsites, and wanted to let people auth themselves on these sites via their Discourse credentials.

Thank you.


How to get current user's session id?
(Sam Saffron) #2

This has not been covered anywhere cause its not implemented, I imagine we will get to it in the next 12 months or sooner if a paying customer needs it.


(NTAuthority) #3

I’m personally looking for something fairly similar; however I’d probably be able to get it done in a slightly-hacky way for my own purposes, however as apparently Discourse doesn’t set the cookie domain on the second-level domain, I can’t directly access the cookies set by the login on Discourse itself.

Also, did anything change in the past 6-ish months of development on Discourse (finally?) causing the cookie containing the per-user token used for looking up current_user to be bound to the client IP? Does the UserProvider override still exist?


(Daniel Hollands) #4

@ntauthority I would be interested in working with you on putting something together, if you fancied it?

For my own stuff, I don’t need anything too fancy, maybe even just a solution implemented via the API or something.

Gimme a shout :smile:


(NTAuthority) #5

I previously had implemented a client set for use in a client-side application before (where the client would use the Discourse API to authenticate and get a session token (in case of Discourse, just the packed cookie with the user’s secret token), and then my application server – on a TCP socket – would verify the session token with the user ID passed by the client), which worked mostly fine back in February - but I’m uncertain if Discourse added restrictions on the secret token to prevent cookie stealing from resulting in a usable session (i.e. creating per-IP sessions).

Anyway, this solution was fairly similar to the following:

  1. A client-sided UI (in this case an embedded browser) with both links directing to /auth/:service on the Discourse site and a form that does some further stuff, such as:

    1. Requests /session/csrf.json, taking the token from [].csrf and passing it in a X-CSRF-Token header in the following request.
    2. Does a POST to /session.json, with a field map of { login: '...', password: '...' }. This request will result in the usual session cookies being amended in the response headers; if one’s doing this from their own web application’s backend or an embedded browser the cookies should be readable from whatever request system used as ‘_t’.
    3. Provides the object /auth/:service will attempt to invoke on completion in the opener (I’m not sure exactly what these were).
  2. A server-sided call requesting /user_preferences with the cookie the client sent in user-specific data (remember, this describes my past client application), checking the URL it redirects to (for instance, /users/ntauthority/preferences), and then looks up the matching /users/ntauthority.json – continuing on from there is again mostly application-specific logic.

For my current project, however, I want to bring this authentication to the web - if I can’t directly modify the cookie domain Discourse sets I’m personally thinking of making a formal login page on my main site, requesting the API on Discourse and forwarding the cookie to the client (except with a .domain.tld domain), and hope Discourse doesn’t need to override it.

As of what the web application does with the cookie, I’d say it’d be similar to point 2 from the list above - and then stores some short-term validity flag in session data provided by the application framework the main site runs on as to not require unneeded lookups in Discourse.


Using the Discourse SSO provider feature
(Daniel Hollands) #6

I’ll admit, on my read though most of that went over my head… But thank you for the info. Once I get as far as needing something, I’ll look back here for reference :smile:


(Erlend Sogge Heggen) #7

There is now an official how-to on this:


(Erlend Sogge Heggen) #8