Use Discourse as an identity provider (SSO, DiscourseConnect)

[Richie (Richie Rich)]

@jessicah

Is it possible to include a state parameter that gets returned unchanged

Could you not add one to the querystring of your callback URL before you wrap it up?

Eg:

nonce=NONCE&return_sso_url=https://www.example.com/my/callback_url.aspx?myparam=here

[Richie (Richie Rich)]

@jessicah I tried this today and yes, it works fine.

        ' Create a Return URL
        Dim strReturnURL As String = "https://www.example.com/authtestRETURNURL.aspx?myownparametershere=surewhynot"

        ' Generate a random nonce. Save it temporarily so that you can verify it with returned nonce value
        Dim strNonce As String = Guid.NewGuid().ToString("N")

        ' Create a new payload with nonce and return url (where the Discourse will redirect user after verification)
        '       Payload should look like: nonce=NONCE&return_sso_url=RETURN_URL
        Dim strPayload As String = "nonce=" & strNonce & "&return_sso_url=" & strReturnURL

Then on the page which is called back you’ll find this inside your decoded SSO query string:

&return_sso_url=http%3A%2F%2Fwww.example.com%2FauthtestRETURNURL.aspx%3Fmyownparametershere%3Dsurewhynot&username=Rich

Hopefully this is what you meant?

[camkego (Cameron E)]

Multi-site approaches to using discourse-auth-proxy?

Are there any examples or recommendations for using Discourse as SSO provider for multi-site authentication?

It seems like the there are two basic multisite approaches:

1. Use multiple instances of discourse-auth-proxy, one per site protected.
2. Use a single instance of discourse-auth-proxy so the payload containing return_sso_url changes based upon the source of the login request.

I think either of these could work, but the issue with these two approaches, is
that you still require logging into each different site.
There is also the risk that something is stored in Postgres that will get overwritten by each login from the different sites. ie: site1.com. site2.com
(I don’t know the details of Discourse auth/PG schema, so I don’t know)

What would be ideal is a way to have login performed once, which gets you logged into all the sites in the multi-site group. ie, site1.com, site2.com, site3.com

Apparently Stackoverflow does this using a combination of localSession storage and Iframes as the main enabler. tech description

But I’d really love to know if someone has implemented any approach to
multisite login using Discourse as the SSO provider.
approach 1: multiple instances of discourse-auth-proxy
approach 2: hacked discourse-auth-proxy affecting return_sso_url in payload.
approach 3: #1 or #2 implemented such that logging in once, means you do not have to login again when moving from site1.com to site2.com

I am tagging you @sam, since you originally authored the Go discourse-auth-proxy program.

[hawm]

Hi.

I am stucking at how the provider handle the + sign in return sso url.

In my case, my DiscourseConnect consumer will create a return_sso_url like

1. raw http://example.com/foo/bar?wpLoginToken=123+\
2. PHP urlencoded http%3A%2F%2Fexample.com%2Ffoo%2Fbar%3FwpLoginToken%3D123%2B%5C

then DiscourseConnect will return to

1. http://example.com/foo/bar?wpLoginToken=123%20\&sso=foo&sig=bar
2. http://example.com/foo/bar?wpLoginToken=123+\&sso=foo&sig=bar

The problem is that the return to url will be handle by the urldecode function in PHP(it’s the core workflow in MediaWiki Authentication), and the wpLoginToken value will be unexpected change from 123+\ to 123 \.

Look like i has found the cause:
https://ruby-doc.org/stdlib-2.7.1/libdoc/uri/rdoc/URI.html#method-c-decode_www_form
https://www.php.net/manual/en/function.urlencode.php

Well, the client and server implement encode/decode but follow different specification.

I’m not asking Discourse to change but looking for advice to resolve this.

Thanks.

Edit:
I resolve it just urlencode the + sign twice.

[uckelman (Joel Uckelman)]

@mdoggydog

Please try this out:

https://github.com/mdoggydog/DiscourseSsoConsumer

Thanks!

I’m trying this presently. I sent you two PRs on GitHub, one for refreshing the docs and one for fixing a bug I hit.

[uckelman (Joel Uckelman)]

In Settings > Login, the two DiscourseConnect provider settings are not consecutive, and appear interspersed with the DiscourseConnect settings:

Since the provider and the non-provider settings are for opposite use cases—using Discourse to manage users for something else versus using something else to manage users for Discourse—displaying these settings mixed together invites misconfiguration. It would be less confusing if the two provider settings were consecutive and either entirely before or entirely after the non-provider settings.

[hyd504]

@techAPJ Can this be used with AWS Cognito? I want to create an app in AWS Amplify for my discourse community and want my app to be authenticated through discourse.

[david (David Taylor)]

@uckelman

In Settings > Login , the two DiscourseConnect provider settings are not consecutive, and appear interspersed with the DiscourseConnect settings:

Sorry for the very delayed reply. You’re absolutely right - it’s confusing that they’re interspersed like that. I’ve cleaned it up in this PR:

UX: Re-order auth-related site settings for clarity

[uckelman (Joel Uckelman)]

@mdoggydog Thanks for the recent update to the DiscourseSsoConsumer MediaWiki extension. We’d been puzzling over what to do about users being logged out of our wiki without having logged out of Discourse, and $wgPluggableAuth_EnableAutoLogin was definitely not what we wanted, since it prevents anonymous access to the wiki. The $wgDiscourseSsoConsumer_AutoRelogin setting you added is exactly what we needed.

[cookieman768]

Hello there!

I am trying to use the PHP example from the original post, but the way they’re storing stuff doesn’t make sense. They’re just storing values in an SQL database with the keys login and nonce. If I want to use SQL to store the nonces what would my SQL database look like exactly?

Some other info that might help is what I’m using this for - I am hoping to link a Discourse user to a Minecraft account by generating an SSO link which is tied to their UUID. Upon successfully logging in with Discourse, I’m going to store their UUID and Discourse ID in a table.

So far, I was able to get the PHP example working, but I guess I’m not fully understanding how I’d have to modify it to work for my use-case. Ideally, I want to generate the link through a GET request and send it to the user, so the UUID is already associated with the nonce.

Thank you for this post, as I would be even more lost without it!

Edit: For nonces would I just be better off storing nonces in the table and look up by that? I know I need to match the nonce but, unless I can pass additional information through in the redirect URL (which I haven’t been successful doing so) I’m not sure how to reference the nonce properly.

[tachibanalolo]

I have created a guide that allow admin to configure DiscourseConnect into standard SAML protocol via SimpleSAMLphp.

Set up your DiscourseConnect(DiscourseSSO) to SimpleSAMLphp, use your Discourse forum as a SAML IDP (Identify Provider)

Discourse has intergrated a DiscourseConnect that allows you to change your Discourse into a SSO provider. You can find it in “Using Discourse as an identity provider (SSO, DiscourseConnect)” this article. However what it provides is not a standard SAML or Oauth protocol. So we need to use a module that created by Paul B. in Discourse forum. This is a module that allows us connect DiscourseConnect to SimpleSAMLphp and then use SimpleSAMLphp to provide standard SAML login service protocol. In he…

[tachibanalolo]

Link Detail

/session/sso_provider?sso=bm9uY2U9NDA3YTVlNjg1ZTEwMDlh...

I’m not sure why it will 502 bad gateway.

[simon]

I edited out some of the value of the sso param that you had provided. Unless someone knew your secret key they would not be able to decode the value, but it still seemed safer to not provide the full value. It won’t be related to the 502 error that you are getting.

[tachibanalolo]

It seems a databse error. Because I try the same plugin and configuration in another discourse website, and it’s working. How can I fix this problem?

[panic]

It seems that trying to authenticate into discourse-auth-proxy with non-ASCII usernames or group names (Chinese in my case) leads to an error due to cookies cannot contain these characters. This is my fix: (disclaimer: I’m not really familiar with golang)

diff --git a/main.go b/main.go
index 1b1dc28..18f8c9e 100644
--- a/main.go
+++ b/main.go
@@ -154,7 +154,12 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
        var username, groups string
 
        if err == nil && cookie != nil {
-               username, groups, err = parseCookie(cookie.Value, config.CookieSecret)
+               var value string
+               value, err = url.QueryUnescape(cookie.Value)
+               if err != nil {
+                       return
+               }
+               username, groups, err = parseCookie(value, config.CookieSecret)
        }
 
        if err == nil {
@@ -224,7 +229,7 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
                cookieData := strings.Join([]string{username, strings.Join(groups, "|")}, ",")
                http.SetCookie(w, &http.Cookie{
                        Name:     cookieName,
-                       Value:    signCookie(cookieData, config.CookieSecret),
+                       Value:    url.QueryEscape(signCookie(cookieData, config.CookieSecret)),
                        Expires:  expiration,
                        HttpOnly: true,
                        Path:     "/",

[david (David Taylor)]

Thanks for reporting! Would you mind making a PR against the github repository so that we can merge this change into the official version?

[cookieman768]

I was able to use this to create an account linking system for my Minecraft server! Thought I’d share what it looks like! This was my first time working with Discourse SSO, so I might’ve overcomplicated everything. However, it works, which is the main thing.

[Devarsh_Mavani]

Hi i did all these correctly. but when the user is not logged in discourse it will show user login popup. when I fill username and password, it does not redirect me back to return_url. can you please help me?

[mksafi (M.K.)]

I assume the nonce is there to prevent replay attacks. I read online that replay attacks aren’t possible with HTTPS, which is what I’m using. So do I still need to do the nonce? I ask because I’m not sure where to store it. Does it make sense to store it as a secure, plain text cookie in the user’s browser? and then read it from the browser along with the return payload?

This library, which is linked from the original post GitHub - ArmedGuy/discourse_sso_node: npm package for Discourse SSO login features. doesn’t use the nonce when validating the user.

[Osama]

@mksafi

I assume the nonce is there to prevent replay attacks. I read online that replay attacks aren’t possible with HTTPS, which is what I’m using. So do I still need to do the nonce?

Yes, you still need to validate the nonce because it prevents reusing payloads that Discourse sends when it redirects users back to your site.

For example, let’s your site has some content behind a paywall that only members of the subscribers group on Discourse can access and you use the groups field in the payload that Discourse sends to your site to display the paid content only to members of the subscribers group. If you don’t validate the nonce, a user who is no longer in the subscribers could use an old payload from when they were a member to login to your site and see the paid content.

@mksafi

Does it make sense to store it as a secure, plain text cookie in the user’s browser? and then read it from the browser along with the return payload?

It’s best to store the nonce in a database with a short expiration date and delete the nonce from the database as soon as it’s used. However, if you can’t use a database, then you can use a cookie to store the nonce, but you need to do some additional steps to prevent payload reuse:

1. attach an expiration date to the nonce when you generate it, for example 10 minutes from the current time
2. sign the whole cookie (nonce + expiration date) to prevent users from modifying the nonce and/or the expiration date
3. verify the signature of the cookie and ensure the nonce isn’t expired

That should give you a good enough protection against payload reuse. Keep in mind that technically it remains possible to reuse a payload, but it’ll be limited to a 10 minutes window instead of forever.

A simpler solution that doesn’t need a cookie is to include the expiration date in a custom field in the payload that you generate. Then when Discourse redirects users back to your site with a payload, your custom fields will be included and you can retrieve the expiration date and you verify it’s not expired. To include a custom field in the payload, you need to include a field prefixed with custom., so your payload would look like this:

nonce=NONCE&return_sso_url=RETURN_URL&custom.expiration_date=TIMESTAMP