PHP and WordPress Single Sign On (SSO) with optional JWT Addon

DragonsWho

Hey everyone,

After a week of troubleshooting, I managed to get the maicol07/flarum-ext-sso extension working for JWT-based Single Sign-On between my main application and Flarum. I wanted to share the key fixes in case anyone else runs into similar issues:

Here are the main problems I encountered and how they were resolved:

Missing lcobucci/jwt Dependency in Production:
- Problem: The Flarum SSO extension's composer.json listed lcobucci/jwt under require-dev and suggest, but not as a main require dependency. This meant that when installing with --no-dev (typical for production environments), the JWT library wasn't actually installed, leading to a Class "Lcobucci\JWT\Configuration" not found error in Flarum.
- Fix: I had to explicitly add the library to my Flarum project's composer.json and install it by running:
```
        composer require lcobucci/jwt "^4.1" --prefer-dist -a -o
```
  This ensures the necessary JWT parsing and validation library is available.

Incorrect Signing Algorithm Resolution in JWTSSOController.php:

Problem: Even with the "Signing Method" set to Sha256 in the Flarum SSO extension's admin settings, the JWTSSOController.php code failed to correctly instantiate the Sha256 signer object. The switch statement (around line 95-105 in vendor/maicol07/flarum-ext-sso/src/JWTSSOController.php) responsible for selecting the signer based on the $this->signing_algorithm property (retrieved from settings) would result in the signer variable remaining null. This caused a TypeError: Lcobucci\JWT\Configuration::forSymmetricSigner(): Argument #1 ($signer) must be of type Lcobucci\JWT\Signer, null given.

Fix (Workaround): To resolve this, I temporarily hardcoded the signer instantiation in JWTSSOController.php before the Configuration::forSymmetricSigner() call:

        // Inside public function handle(Request $request): ResponseInterface
        // ...
        // $signing_algorithm = null; // Original initialization
        // switch ($this->signing_algorithm) { /* ... original switch ... */ }

        // WORKAROUND: Directly instantiate the required signer
        $signing_algorithm = new \Lcobucci\JWT\Signer\Hmac\Sha256(); 
        
        $config = \Lcobucci\JWT\Configuration::forSymmetricSigner(
            $signing_algorithm, // Now $signing_algorithm is an object
            // ... rest of the config
        );
        // ...
        ```        This bypasses whatever issue was preventing the correct reading or matching of the "Sha256" setting string.

3.  **Incorrect JWT Signing Key Loading with `lcobucci/jwt` v4+:**
    *   **Problem:** The extension was attempting to load the plain text "Signer key" (JWT secret) using `InMemory::base64Encoded(base64_encode($this->signer_key))`. For `lcobucci/jwt` v4+, if you have a plain text secret, this double encoding is incorrect and can lead to signature validation failures. The `base64Encoded()` method expects a key that is *already* Base64 encoded (e.g., a binary key that was Base64 encoded for storage).
    *   **Fix:** I modified the `Configuration::forSymmetricSigner()` call in `JWTSSOController.php` (around line 109-111) to use `InMemory::plainText()` for the signer key:
        ```php
        // ...
        $config = \Lcobucci\JWT\Configuration::forSymmetricSigner(
            $signing_algorithm, // This is new \Lcobucci\JWT\Signer\Hmac\Sha256(); from fix #2
            // InMemory::base64Encoded(base64_encode($this->signer_key)) // Original
            \Lcobucci\JWT\Signer\Key\InMemory::plainText($this->signer_key) // Corrected version
        );
        // ...

This ensures the plain text secret is handled correctly by the JWT library.

Hopefully, these details help anyone else trying to set up JWT SSO with this extension!

maicol07

Release 1.11.6

What's Changed

fix: do not redirect to /null if no login_url is set by @SKevo in maicol07/flarum-ext-sso24
fixed missing JWT dependency in production
updated dependencies

Full Changelog: maicol07/flarum-ext-sso1.11.5 → 1.11.6

cb2004

How come Composer wont update to 1.11.6?

maicol07

cb2004 hi, what is the error?

cb2004

There is no error, it just sticks with 1.11.5 as if it thinks that is the latest version

cb2004

Looks like 1.11.6 requires lcobucci/jwt: >=4.1 but 1.11.5 didnt, I thought this was optional?

maicol07

cb2004 actually, that has been made a required dependency due to an issue when using JWTs

cb2004

Ok that all sounds fine. But this was a fresh install of SSO today on an install only a month old so JWT should be installed as well along with 1.11.6 right?

maicol07

cb2004 Yes, when installing for the first time or upgrading, the JWT dependency will be automatically installed

cb2004

Yes this is the problem for me. A fresh install off the extension went with 1.11.5 for me. Guessing because JWT wasn't present. I will require JWT and see if 1.11.6 is then installed when doing an update.

maicol07

1.11.7

Fixes settings page without settings
Updated dependencies

cb2004

cb2004 Sodium wasn't enabled in php.ini on my local, once enabled all was fine.

keshavsm

Can you please disable it in community.powerprofs.com, because I couldn't configure it properly and now I am unable to login as admin as well as user?

maicol07

keshavsm hi, you have to ask to an admin of that Flarum

keshavsm

maicol07 I am the admin. But, I think it is fine now, as I can see it is disabled. Thank you

myeco-earth

Will this work with a node and react based site, I've spent the last 2 days trying to get this to work and its proving to be quite difficult to get right, my frontend is deployed via Netlify from GitHub, dB is MongoDB atlas, made sure the JWT secret in the SSO settings was the same as in my environment variables in Netlify, JWT issuer set to my site, had to leave the other settings such as login/logout URL etc blank as kept getting myself locked out, just wondering if this can work with this sort of setup before I carry on trying to identify the issues, thanks

maicol07

myeco-earth Hi, you will need to develop a plugin for Node (as there isn't one currently). You can check the PHP one to see an example: https://docs.maicol07.it/en/flarum-sso/plugins/php

ctml

Recently upgraded flarum and php, and now having some strange issues with SSO.

Existing User = Fail

127.0.0.1 - "-" - - [06/Jan/2026:00:33:11 -0500] "GET /api/users/existinguser?bySlug=1 HTTP/1.1" 200 479 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:33:24 -0500] "POST /api/token HTTP/1.1" 401 67 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:33:35 -0500] "GET /api/users HTTP/1.1" 200 10338 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:33:44 -0500] "POST /api/token HTTP/1.1" 401 67 "-" "Maicol07 Flarum Api Client"

New User = Success

127.0.0.1 - "-" - - [06/Jan/2026:00:35:05 -0500] "GET /api/users/newtestuser?bySlug=1 HTTP/1.1" 404 59 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:35:17 -0500] "POST /api/token HTTP/1.1" 401 67 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:35:25 -0500] "GET /api/users/newtestuser?bySlug=1 HTTP/1.1" 404 59 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:35:31 -0500] "POST /api/users HTTP/1.1" 201 1006 "-" "Maicol07 Flarum Api Client"
127.0.0.1 - "-" - - [06/Jan/2026:00:35:33 -0500] "POST /api/token HTTP/1.1" 200 77 "-" "Maicol07 Flarum Api Client"

After new user signs off, they cannot sign in again same as existing user. Tried disabling many extensions and keeping just a select handful.

If you have any debugging tips I'd highly appreciate it.

sh-5.2$ php flarum cache:clear
Clearing the cache...
sh-5.2$ php flarum info
Flarum core: 1.8.11
PHP version: 8.3.26
MySQL version: 12.1.2-MariaDB-ubu2404
Loaded extensions: Core, date, libxml, hash, pcre, zlib, filter, json, SPL, pcntl, random, readline, Reflection, session, standard, openssl, sockets, bcmath, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, intl, ldap, exif, mysqlnd, PDO, Phar, posix, shmop, SimpleXML, sqlite3, sysvmsg, sysvsem, sysvshm, tokenizer, xml, xmlwriter, xsl, mysqli, pdo_mysql, pdo_sqlite, xmlreader, zip, Zend OPcache, xdebug
+----------------------+---------+--------+
| Flarum Extensions    |         |        |
+----------------------+---------+--------+
| ID                   | Version | Commit |
+----------------------+---------+--------+
| maicol07-sso         | 1.11.7  |        |
| fof-formatting       | 1.1.2   |        |
| flarum-flags         | v1.8.2  |        |
| flarum-tags          | v1.8.5  |        |
| flarum-approval      | v1.8.2  |        |
| flarum-markdown      | v1.8.1  |        |
| flarum-mentions      | v1.8.5  |        |
| flarum-subscriptions | v1.8.1  |        |
| flarum-nicknames     | v1.8.2  |        |
+----------------------+---------+--------+

                   $options = [
                        "url" => 'https://community.' . $_SERVER['HTTP_HOST'],
                        "root_domain" => $_SERVER['HTTP_HOST'],
                        "api_key" => 'flarum_api_key',
                        "password_token" => "randomtoken",
                        "remember" => true,
                        "verify_ssl" => false
                    ];

                    $flarum = new Flarum($options);
                    $flarum_user = $flarum->user($_SESSION['username']);
                    $flarum_user->attributes->email = $_SESSION['email'];
                    $flarum_user->attributes->password = 'master_password';
                    $flarum_user->attributes->nickname = $_SESSION['nickname'];
                    $result = $flarum_user->login();

Edit: Debugging locally and discovered that the POST requests to /api/token for existing users had the "identification" inside the POST body set to null. It seems to be related to changes to getters and dynamic properties in the 3.3 upgrade. Calls to $this->attributes->username inside getToken return null. The username field does not appear inside dirty attributes or relationships, and the new getter only check these (old version checked attributes field too).

Downgraded to 3.2 and all working again! 🙂

maicol07/flarum-sso-php-plugin8f621a4

    private function getToken(): ?string
    {
        $data = [
            'identification' => $this->attributes->username,
            'password' => $this->attributes->password,
            'remember' => $this->flarum->isSessionRemembered(),
        ];

        try {
            $response = $this->flarum->api->token()->post($data)->request();
            return $response->token ?? '';
        } catch (ClientException $e) {
            if ($e->getResponse()->getReasonPhrase() === "Unauthorized") {
                return null;
            }
            
            throw $e;
        }
    }

Murgusk

I'm getting critical error when I click on "Enable SSO" in the Wordpress Plugin. This is the error log:

PHP Fatal
Uncaught Error: Failed opening required '/wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap80.php' (include_path='.:/usr/share/php')
Stack trace: 
#0 /wp-content/plugins/sso-flarum/vendor/composer/autoload_real.php(41): require()
#1 /wp-content/plugins/sso-flarum/vendor/composer/autoload_real.php(45): {closure:ComposerAutoloaderInit3903de7d8f4cda6f6fdd14da49992462::getLoader():37}() 
#2 /wp-content/plugins/sso-flarum/vendor/autoload.php(25): ComposerAutoloaderInit3903de7d8f4cda6f6fdd14da49992462::getLoader() 
#3 /wp-content/plugins/sso-flarum/sso-flarum.php(81): require_once('...') 
#4 /wp-includes/class-wp-hook.php(341): main() 
#5 /wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters() 
#6 /wp-includes/plugin.php(522): WP_Hook->do_action() 
#7 /wp-settings.php(593): do_action() 
#8 /wp-config.php(119): require_once('...') 
#9 /wp-load.php(50): require_once('...') 
#10 /wp-admin/admin.php(35): require_once('...') 
#11 /wp-admin/tools.php(40): require_once('...') 
#12 {main} thrown in /wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap.php on line 15
Plugin: SSO for Flarum
File: /wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap.php
Line: 15

Any fix for this?

Murgusk

This is the error log sent by Wordpress:

Error Details
=============
An error of type E_ERROR was caused in line 15 of the file /wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap.php. 
Error message: Uncaught Error: Failed opening required '/wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap80.php' (include_path='.:/usr/share/php') in /wp-content/plugins/sso-flarum/vendor/symfony/polyfill-mbstring/bootstrap.php:15
Stack trace:
#0 /wp-content/plugins/sso-flarum/vendor/composer/autoload_real.php(41): require()
#1 /wp-content/plugins/sso-flarum/vendor/composer/autoload_real.php(45): {closure:ComposerAutoloaderInit3903de7d8f4cda6f6fdd14da49992462::getLoader():37}()
#2 /wp-content/plugins/sso-flarum/vendor/autoload.php(25): ComposerAutoloaderInit3903de7d8f4cda6f6fdd14da49992462::getLoader()
#3 /wp-content/plugins/sso-flarum/sso-flarum.php(81): require_once('...')
#4 /wp-includes/class-wp-hook.php(341): main()
#5 /wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#6 /wp-includes/plugin.php(522): WP_Hook->do_action()
#7 /wp-settings.php(593): do_action()
#8 /wp-config.php(117): require_once('...')
#9 /wp-load.php(50): require_once('...')
#10 /wp-admin/admin.php(35): require_once('...')
#11 /wp-admin/options-general.php(10): require_once('...')
#12 {main}
  thrown

Anyone can help with this?

« Previous Page Next Page »