Algorithm not allowed Error

[jamesw72]

The latest update of the plugin (1.3.0) now returns a "Algorithm not allowed" Error. {"code":"jwt_auth_invalid_token","message":"Algorithm not allowed","data":{"status":403}}

I am able to successfully request a JWT token, but when attempting to validate said token, it returns this error.

[gouku]

Got the same error after upgrading to 1.3.0.

[harmjanr]

Same here, migrating from 1.2.6 to 1.3.0.

[jamesw72]

@Tmeister no algorithm is specified when making the call, so I presume the default algorithm (HS256) would apply. The code that makes the call can be viewed here: https://github.com/wp-net/WordPressPCL

[Tmeister]

@jamesw72, @gouku @harmjanr:

Can you please test this branch https://github.com/Tmeister/wp-api-jwt-auth/tree/php74?

I'm adding an algorithm validation, and the filter should always return HS256 as the default algorithm.

All looks good on my end; I just want to double-check.

Thanks!

[diegocgaona]

I noticed this error too when calling: /wp-json/jwt-auth/v1/token/validate

headers send to validate: {'Authorization': 'Bearer eyJ0eXAiOiJKV1QiLCJPbGciOLIUzI1NiJ9.XXX.XXX'} The response is: {"code":"jwt_auth_invalid_token","message":"Algorithm not allowed","data":{"status":403}}

My token is created fine too in /wp-json/jwt-auth/v1/token (and I didn't modified anything in the plugin side) so I suppose is a valid algorithm.

I couldn't test the branch yet.

[harmjanr]

@Tmeister I installed the version from the branch, still the same error unfortunately. Unless I am doing something wrong with installing, @jamesw72 @gouku can you confirm?

[nmallare]

I'm not sure if it helps the conversation at all, but I'm leaning toward it being some OS-specific issue.

I was able to get v1.3 working on WP Engine, but I cannot get it to work on Flywheel. Funnily enough, WPE owns Flywheel, but their server stack must still be different between the two platforms.

For the time being, I have manually downgraded back to v1.2.6 on our Flywheel instance.

[Tmeister]

I'm not sure if it helps the conversation at all, but I'm leaning toward it being some OS-specific issue.

@nmallare, It does help; I'll try to get a Flywheel account to test.

Thanks

[marioshtika]

Can you please test this branch https://github.com/Tmeister/wp-api-jwt-auth/tree/php74?

Hello, @Tmeister I tested your branch and it didn't fix the issue.

I agree with @nmallare that it's related to the server where the WordPress site runs because on another server the new version 1.3.0 worked from the beginning.

[Tmeister]

Thank you guys for your feedback.

I created an account on Flywheel and test the plugin (v1.3.0) on a fresh install and it works as you can see here.

Can you please share more about your setup?

Best,

[openarun]

Hi there, I am having the same issue. We have nginx in our system. And having the same error. {'code': 'jwt_auth_invalid_token', 'message': 'Algorithm not allowed', 'data': {'status': 403}}

[urgise]

I still have the same issue, 'code': 'jwt_auth_invalid_token', 'message': 'Algorithm not allowed' I reverted back from the 1.3.0 to 1.2.6. PHP 8.0 I also checked on PHP 7.4 and the server is on a cloudlinux with litespeed

[AaronWitter]

Hi there, we're experiencing the same issue:

"I still have the same issue, 'code': 'jwt_auth_invalid_token', 'message': 'Algorithm not allowed' I reverted back from the 1.3.0 to 1.2.6."

[alaeder16]

Hi there, using Power Automate to connect to the WP site. On HTTP Get Token getting an error: {''code": "jwt_auth_invalid_token", 'message': "Algorithm not allowed", "data": {"status": 403} } reverted back from 1.3.0 to 1.2.6.

[marioshtika]

Any update on this?

I have the same problem, but it's on a server that I don't have access to debug it.

Does anyone have a testing website where I can debug it and maybe help @Tmeister find a solution for this?

[Tmeister]

Please help me here; I'm unable to reproduce the error.

I need more information about your setups and settings.

Also, I create this small app to test the basic implementation https://github.com/Tmeister/jwt-client. You can try it as well and see if the issue still exists.

Best,

[jamesw72]

@Tmeister I haven't had a chance to test your branch, but I originally encountered the error while using the C# library https://github.com/wp-net/WordPressPCL.

If you're able to build a small C# app that uses this, you may be able to replicate it.

Thanks.

[chrisjcalderon]

Hello all, we are experiencing the same issue and had to rollback to a previous version. I see comments about potentially being a server issue - if that is the case, any insights as to what could it be ?

[IdolR]

Hello @Tmeister! I am experiencing the same issue 'jwt_auth_invalid_token', 'message': 'Algorithm not allowed' when using your WP plugin v. 1.3.x, so I have reverted the plugin to 1.2.6, which works. Our site is running on NGINX on Siteground hosts. I take this occasion to ask if the plugin adds a hardening layer to Wordpress REST API, as some endpoints are considered to be at risk (for instance wp-json/wp/v2/users which is I want to use!). In my case, our firewall is blocking access to the above endpoint, although this can be added as a whitelisted URL, but I'd like to know if using JWT helps blocking malicious use of the above endpoint. Let me know if I can help debugging the issue

[alaeder16]

Hello @Tmeister I ran a few tests on my local and it worked fine. The issue as far as I can see is with the validation of the encryption algorithm There is a filter that can be added to override the default used by JWT - I tested it locally by setting an invalid protocol and I was able to reproduce the problem. Somehow it seems like (not sure) the new version in the events site is not able to validate the default algorithm (which is the same as in the older version) - and hence returning an error.

[marioshtika]

Hello everyone,

I have been searching a lot about this issue, and the leeway option has been coming up a lot.

As is shown in the PHP-JWT repository

/**
 * You can add a leeway to account for when there is a clock skew times between
 * the signing and verifying servers. It is recommended that this leeway should
 * not be bigger than a few minutes.
 *
 * Source: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#nbfDef
 */
JWT::$leeway = 60; // $leeway in seconds
$decoded = JWT::decode($jwt, new Key($key, 'HS256'));

Can anyone test this?

Add

JWT::$leeway = 60;

before the

$token = JWT::decode( $token, new Key( $secret_key, $algorithm ) );

in the class-jwt-auth-public.php file, in line 333

[marioshtika]

I tested the $leeway option and it didn't work, sorry 😞

[marioshtika]

Hello, @Tmeister I was able to find what is causing this issue.

It's the usage of the Firebase\JWT namespace. If there are other plugins that are using the same library with the same namespace it usually loads the library from the other plugins (or whichever loads first).

I saw that you updated the firebase/php-jwt to 6.3 and that version does not have the Algorithm not allowed error message. So the error message that we are getting is from the JWT library but from another plugin.

One of those plugins is The Events Calendar. If you install that, you will get the error message.

Let me know if you want me to send a PR or if you want me to test any new version.

Thank you in advance.

[nekobcn]

I can confirm that the previous post workaround worked for me. Just disabling The Events Calendar was enough to recover all functionality.

[IdolR]

Well yes, I do have The Events flipping Calendar plugin! But as this was interfering with REST API Calls as a whole, I have followed instructions to disable Events Calendar REST API , adding the code below within my functions.php file:

// Disable Tribe events API - Advertise to the world that the REST API is disabled.
add_filter( 'tribe_events_rest_api_enabled', '__return_false' );

// Actually disable REST API functionality.
add_action( 'init', function () {
    remove_action(
        'rest_api_init',
        array( tribe( 'tec.rest-v1.main' ), 'register_endpoints' )
    );
}, 5 ); 

Clearly, this is not stopping the plugin from interfering somehow!

[chrisjcalderon]

We do use the Events Calendar and actually need it as the code is for creating events via their REST API.... so disabling is not an option

[IdolR]

Chris, just to further clarify, I have only disabled the Events Calendar REST API using the above code

[chrisjcalderon]

Chris, just to further clarify, I have only disabled the Events Calendar REST API using the above code

I meant disabling the calendar's API as we actually use it....

[Tmeister]

@marioshtika bingo!

I will grab a copy of that plugin (The Events Calendar) and dig in to see how is interfering.

Thank you!

[nmallare]

@Tmeister we don't use this plugin, but I'm sure we use another one that is causing a Namespace issue. Thanks for digging into this, @marioshtika!

Hopefully your fix for The Events Calendar will also fix our issue 🤞🏻

[Tmeister]

Hi all,

Indeed the issue is that the plugin The Events Calendar is using an old Firebase/JWT version, (5.0.0) and WordPress is loading their library before mine, and that's is the problem.

I can do nothing on my end to avoid the issue; you can use this plugin to load my plugin and their dependencies first, BUT that will break their implementations.

I opened an issue on their support forum to let them know about the issue https://wordpress.org/support/plugin/the-events-calendar/; meanwhile, I'll leave this as a Known Issue

[diegocgaona]

@Tmeister I do not have this plugin but I have the same error. Maybe is the "pods" plugin (https://br.wordpress.org/plugins/pods/) or "Disable REST API" plugin (https://br.wordpress.org/plugins/disable-json-api/). Anybody have the same plugins and the error?

EDIT: Found the Firebase/JWT on Pods: https://github.com/pods-framework/pods/search?q=%22firebase%2Fphp-jwt%22%3A+%22%7E5.0.0%22%2C

Can you open a issue with then too?

[Tmeister]

@diegocgaona

Yeah same issue, outdated version

[marioshtika]

Hello @Tmeister

I think this plugin (and every other plugin) should load its own files (libraries) and not depend on which file would load first.

So to solve this issue I was thinking maybe we should either load the JWT & Key classes directly (not using the Firebase namespace) or create a unique namespace to be loaded only from your plugin.

I created a pull request #252 where I am extending the JWT & Key classes and adding a new unique namespace to use it on the class-jwt-auth-public.php file

Like this:

use Tmeister\Firebase\JWT\JWT;
use Tmeister\Firebase\JWT\Key;

What do you think? Is this an acceptable solution?

[Tmeister]

Guys and gals, this branch has @marioshtika fix; all my tests are looking good, but please would be great if you could test the branch on your end before to go live, especially the functionality with the other plugins.

Thanks, @marioshtika!

[marioshtika]

Hello @Tmeister I am glad I helped.

I tested it on my test site and on one other production site and it is working fine 👍

[gfra54]

Guys and gals, this branch has @marioshtika fix; all my tests are looking good, but please would be great if you could test the branch on your end before to go live, especially the functionality with the other plugins.

Thanks, @marioshtika!

Hello ! I had the same issue and I can confirm that this branch seems to work fine 👍

Thanks to you and to @marioshtika

[harmjanr]

Version 1.3.2 resolves the issue for me 🙌🏼

[IdolR]

Same for me, thanks!

[chrisjcalderon]

Same here! thanks all for resolving the issue in such a prompt manner!!!

[HeyMehedi]

After investing some time in this issue, I found an interesting problem, another plugin used the backdated JWT library it was loading at first.

After deactivating the plugin, I can see it works perfectly.