SSO login appears to have stopped working

I have had SSO integration from my site for a few years now with no issue.

Recently users started saying that when they login it redirects to my site to login and then ends back up at Discourse still showing they need to Login. I having been trying to debug but I am not seeing any issues. It just seems like at the end when it does the redirect to Login something is going wrong.

When I look in Discourse the user account is created, but for some reason it is not logging them in.

Here is a quick video showing what I am seeing…

I followed this info:

…and am using the latest discourse-sso javascript library.

This is my AWS Lambda which is fronted by an API Gateway…

'use strict';

exports.handler = (event, context, callback) => {

    var discourse_sso = require('discourse-sso');
    var sso = new discourse_sso("********************"); // secret hidden

    var body = JSON.parse(event.body);

    var payload = body.sso; // fetch from incoming request 
    var sig = body.sig; // fetch from incoming request 
    if(sso.validate(payload, sig)) {
        var nonce = sso.getNonce(payload);
        var userparams = {
            // Required, will throw exception otherwise 
            "nonce": nonce,
            "external_id": body.externalId,
            // Optional 
            "username": body.username,
        console.log("User: " + JSON.stringify(userparams));
        var q = sso.buildLoginString(userparams);

        console.log("q: " + q);

        // Redirect
        var response = {
            statusCode: 200,
            headers: {
                "Access-Control-Allow-Origin": "*"
            body: JSON.stringify({"q":q})
        callback(null, response);
    } else {
        // What to do if doesn't validate?
        var responseError = {
            statusCode: 200,
            headers: {
                "Access-Control-Allow-Origin": "*"
            body: JSON.stringify({"error":"SSO Validation Error"})

        callback(null, responseError);

When the Login button is clicked from Discourse it calls my web app where the user is validated and then if validation passes calls the following…

						if (state.get(["appState", "urlParams", "sso"]) && state.get(["appState", "urlParams", "sig"])) {
							var userMetadata = getUserMetadata(result);

							var body = {
								sso: state.get(["appState", "urlParams", "sso"]),
								sig: state.get(["appState", "urlParams", "sig"]),
								externalId: keyPrefix,
								username: username

								.end(function (err, res) {
									if (err || !res.ok) {
									} else {
window.location.replace("" + res.body.q);

Any help understanding what may be going on would be appreciated.

This is most likely caused by a bug in Chrome 97, which was released this month. While we wait for Google to roll out a fix, we’ve added a workaround to Discourse. Upgrading your site to the latest version should solve the problem.


Unfortunately I am using a hosting provider. Any other workarounds? If I turn off SSO off for the time being from Discourse and then turn back on when fixed will that wreak any havoc? I assume users would have to manually create an account in that case. When I re-enable just curious if then will create a new account associated with my system.

I’m afraid not. Our managed hosting is up-to-date. Can you share which provider you’re using? We might be able to get in touch and let them know about the update.

If email addresses match up, then it should work seamlessly. Initially, users will need to use the “forgot password” button to create a password

1 Like

@jeffbonasso I see you’re hosted with us, we’re going to look for a solution for you. Can you please create a ticket using our control panel, referring to this topic?

No, that would work. If you turn it back on then the SSO will recognize the email address.
But existing users might have a hard time logging on, since they don’t have a password for the forum directly.

@david May I ask - which Discourse commit contains that fix?

1 Like

For the stable branch, this is the fix:

There is a similar commit on beta and tests-passed as well


Thank you David,

That fix is already present on your forum since January 13 @jeffbonasso , so this cannot be it (or the reports you got are from before that date?)

1 Like

The video I created was with a test user I created this morning and the behavior was consistent with what a customer was experiencing. Interesting, I just tried logging in with Safari and it worked. I then tried Chrome again and that is also now working. The Chrome version I just tested with is Version 97.0.4692.99 (Official Build) (x86_64). I am going to reach out to a customer who was having issues to see if they are still having issues.


FYI…the customer reported they are using the Brave browser, a Chrome derivative. He said it is still not working, He then tried Edge and it is working.

our bypass is chrome specific, we may need to extend the net here @Falco / @david

I wonder if we should add a site setting to disable service workers that people can flick on if they experience issues like this?

It’s already fixed in the latest Chrome version since 2022-01-19T03:00:00Z so I believe the Chrome derivatives will follow shortly as the release with this fix, 97.0.4692.99, also includes one critical and 15 high security fixes.


We applied the DiscourseConnect fix across all browsers. The later global fix was specific to Chrome, but it should also target Edge/Brave thanks to their user agent strings:

Edge: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36 Edg/97.0.1072.55'

And Brave apparently doesn’t customize the default chrome user agent