Add RS256 support

[renrizzolo]

I am using React-native-auth0 webAuth() method which uses PKCE. My understanding is that this requires RS256 signing.

So my proposal is to add a select in the basic settings to choose to use HS256 (default) or RS256. wherever JWT::decode is used, I've pulled the option from the settings.

The validation response for the settings page needs the HS256 secret, so it has complicated it a bit having an extra input added for client secret when using RS256 signing... maybe there's a better way to do this. (and it is perhaps superfluous).

Issues

I am getting an Expired token received for JSON Web Token validation error on search_connection , and Not Found on update_connection. basically I can't sync settings between wp and auth0. I think this might just be the API token having expired though?
I manually created a new API token and it is working for updating connections and adding/removing rules. I am not sure whether this sis supposed to get refreshed automatically by the plugin?

The Auth0 data in the WP dashboard is all empty - again not sure if this is related because it seems to be empty even with the default signing / secret settings.

The main thing I can see that won't work with a Native client is the validation check in WP_Auth0_Admin_Basic.php

Predicament

• In order to use react-native-auth0, we need the client to be native - which can't use client_credentials grant
• In order to use wp-auth0, we need the client to use client_credentials grant.

---

To be clear, the changes I've made work for my purpose – my client is set to Native, my signing to RS256, and I can log in to WordPress via auth0, and use the WordPress API through my app (with the JWT auth0 plugin modified similarly).

If anybody has any insight or could help with further testing and implementation that'd be great.

[cocojoe]

Thanks for your PR, will take a look.

[glena]

Correct me if I am wrong, but seems you are asking for the public certificate in the settings, can you use the jwks endpoint instead?

here is how the php sdk handles it https://github.com/auth0/auth0-PHP/blob/master/src/Helpers/JWKFetcher.php

thank you for the contribution

[renrizzolo]

Hi guys,
thanks for pointing me in the right direction @glena, I was not aware of jwks and that endpoint.

I have added (0c6fecc) a JWKfetch function to the API client, and it is being used in the get_client_secret_as_key function when the signing alg is set to RS256.

[glena]

awesome, one thing is missing to get this merged, would be posible to add a cache for the JWK?

I am thinking about using a hidden setting (like the one you added but without the adding the field in the settings page.

Also, we would need to add a configurable field to configure the expiration (in minutes). If this value is 0 cache is disabled.

WDYT @cocojoe?

I am thinking that in the future we will need also some retry logic to try to fetch again the keys when the kid is not present in the cached JWKS (and some validation to avoid DDoS) and maybe a button to force flush this cache (if people want to do it manually) so we avoid key rotation issues. Thoughts?

[cocojoe]

In general looks good, agree on suggested improvements. I think we should have the manual force flush just in case as it will no doubt be an issue at some point. This should be in the required cache addition to this PR.

I wish we had more/any tests 😄

[renrizzolo]

OK,
I am using WP transients api for caching, do you think this is suitable?

I have addressed all of the above except for:

we will need also some retry logic to try to fetch again the keys when the kid is not present in the cached JWKS (and some validation to avoid DDoS)

Not sure where/how kid can be checked against the cache.

[cocojoe]

The transients API doesn't guarantee a minimum availability, it only guarantees it will not be available after the cache expiry time. So it could disappear after 1 second and need refreshed which from a performance standpoint bothers me.
WDYT @glena

[glena]

I am ok by using transient.

About the kid (key id), that is an attribute in the token header. The JWKS has a set of keys each one has its own kid, the format is something like:

{
  keys: [
    { kid:"", x5c:"", alg:"", ...}
  ]
}

if a token has a kid that is not present in the cached version of the JWKS, you might need to refresh it to see if the key has rotated. If after fetching a new version of the JWKS it is still not present, the token should be considered invalid.

if you check the jwt library (https://github.com/firebase/php-jwt/blob/master/src/JWT.php#L99-L108) it checks for the right key based on the kid and if not present it fails.

Thinking it through, having a sensible cache should solve this issue, we can leave this retrying logic aside for now.

[cocojoe]

@glena I've tested this and it works, default cache is 24 hours and it is configurable.

[cocojoe]

LGTM