Automatic session management with OAuth SSO

Hello,

We are running a suite of services for a specific closed community and we are deciding to include Discourse as the social platform. I am wondering what is the best and most elegant way (technically) to seamlessly integrate a Discourse instance to our suite.

To give you an example, our suite includes service A and service B (which we have built in-house) as well as an OAuth2 SSO service.

If a user clicks to sign-in on either service A or B, he/she is redirected to the SSO service where he logs-in and redirected back as usual. However, with cookies and session control, logging-in to service A will not require the user to log-in again to service B if he/she decides to visit service B afterwards (he/she will already have a session).

Similarly, we want a way to let users seamlessly traverse to Discourse service from either service A or B after logging-in with the SSO service. Assume the user entry exists in all services. Right now, the OAuth2 Discourse plugin has been evaluated and works with our SSO service, but it requires users to click sign-in with SSO again when they visit Discourse. Is there a way, e.g. an API call to automatically initiate a session with Discourse as well when users log-in via the common SSO from Service A or B?

Furthermore, the above question extends also to comment integration though the embedded component. Maintaining a “public” Discourse service poses no issue with the comment section, and comments are embedded properly. However if running a private Discourse service, the embedded comment window will not display the comments properly if users has not logged-in also to Discourse beforehand, which is a problem when talking about seamless integration.

Is there a way to work around these issues? I was thinking about building a middleware plugin which will decode a token or cookie and instantly authenticate and log-in the appropriate use before making the actual call. Is there an existing plugin for that?

Thanks for your support

2 Likes

You just need to enable the login required site setting for this.

Enabling the login required site setting will also solve this.

2 Likes

Thank you for the quick reply. However, this does not solve the problem. Both on the embedded Discourse comment window as well as when going to the Discourse site, the user (who is already logged in to, say, “service A” via the SSO), will need to log in again.

In both cases I am greeted with a welcome message: “Welcome, An account is required. Please ask an existing member for an invite or log in to continue.” and the log-in button. When I click it, the log-in pops up and I am prompted to log-in via username/password or via the OAuth SSO. I am not required to enter my SSO’s username and password again because the SSO session is still active, however I don’t want users to experience that. When the user logs-in to “service A” he/she needs to automatically be logged-in to Discourse as well without having to press any “Log in” button again.

What do we need to achieve that?
I am using Discourse version 2.5.2 if that’s relevant

On latest Discourse, provided both login required and auth immediately are enabled the user will be automatically logged into Discourse as long it already have a valid cookie in the Identity Provider.

On versions prior to latest, this “magic” login flow was limited to sites using our own SSO protocol, described in Official Single-Sign-On for Discourse (sso).

I’d suggest updating to latest.

3 Likes

Hmm, I’m using bitnami images and their latest is still 2.5.2, so I’ll probably have to wait a bit for that (or find a way to do a manual update, or use some other image).

Anyway, thank you for pointing me to the right direction. Much appreciated!

Keep in mind the bitnami images are not supported by the Discourse developers, and over the years had many incompatibilities with the normal usage of the software. I strongly suggest using an Discourse official Standard Installation

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.