Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSSL error in WP_Auth0_Api_Client_Credentials::call #631

Closed
coperator opened this issue Mar 14, 2019 · 4 comments
Closed

OpenSSL error in WP_Auth0_Api_Client_Credentials::call #631

coperator opened this issue Mar 14, 2019 · 4 comments
Assignees
Milestone

Comments

@coperator
Copy link

Description

The error happens, if a user tries to change his password.
Since there is no valid api_token, Wordpress calls WP_Auth0_Api_Client_Credentials::call().
The JWT::decode() fails to verify the signature:

[14-Mar-2019 10:26:40 UTC] PHP Warning:  openssl_verify(): supplied key param cannot be coerced into a public key in /srv/www/app/wp-content/plugins/auth0/lib/php-jwt/JWT.php on line 223

The DomainException is thrown:

DomainException: OpenSSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line

and written to the Auth0 Log.

The line 80 in php-jwt/JWT.php:

if ( false === ( $sig = static::urlsafeB64Decode( $cryptob64 ) ) ) {

seems to result in a broken $sig.

I checked the token returned from the Auth0 Management API with https://jwt.io/ and the signature is verified successfully.

What could be the problem?

Environment

Please provide the following:

  • WP-Auth0 version: 3.9.0
  • WordPress version: 4.9.9
  • PHP version: 7.0

The Client Secret is not base64 encoded.
The JsonWebToken Signature Algorithm of the client is set to HS256 in the Auth0 management console and also in the Wordpress Auth0 settings.

@coperator
Copy link
Author

I do not understand, why the API token is decoded at all. I only need the token, but not the decoded version, as obvious in line 86-87 of WP_Auth0_Api_Client_Credentials.php

			$this->token_decoded = $this->decode_jwt( $response_body->access_token );
			return $response_body->access_token;

@joshcanhelp
Copy link
Contributor

joshcanhelp commented Mar 14, 2019

@coperator - That decoding is also validating the access token we get back for the Management API. So, while we don't use any of the data in there, we're checking to make sure it's valid.

You mentioned the "JsonWebToken Signature Algorithm" for the Application in Auth0 but this is for the Management API so that setting is APIs > Auth0 Management API > Signing Algorithm (should be RS256 and not able to be changed).

I just tested locally and everything works if the JWT algorithm is set to RS256. It looks like the problem, though, is when the algorithm is set to HS256. The access token for the Management API is always RS256 but the secret used to decode it comes from the application setting, which is not correct (bug in the plugin). Easiest way to get around this before a fix is applied is to switch your Applications JWT algo to RS256 in Auth0 and in the plugin (that's the recommended setting). Otherwise, if you need to keep it HS256, the code change below needs to happen on this line:

- $this->options->get_client_secret_as_key(),
+ WP_Auth0_Api_Client::JWKfetch( $this->domain ),

As an aside ... I think this is over-stepping a bit on the part of the plugin and will be addressed in the next version. We're changing a number of things about how that token is generated, stored, and used to cut down on the number of API calls we're making and follow more closely the OAuth standards around access tokens.

Apologies for the trouble here and thank you for the clear and detailed report!

@coperator
Copy link
Author

@joshcanhelp Thank you for your prompt reaction and explanation!
When we started our Wordpress application with Auth0 we had problems with RS256 and, thus, simply used HS256, but since I now realized that it makes things a lot easier, we will most probably switch to RS256 for the application JWT.

However, as mentioned above, in my mindset applications should not care about decoding access tokens.

@joshcanhelp
Copy link
Contributor

in my mindset applications should not care about decoding access tokens.

Yes, this is guidance we typically give. In this case, the intent was a slightly better experience but I came up with a better way to do that in #632.

Thanks again for the report here!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants