Wordpress plugin: Invalid Authorization Code when logging in

Hello people of Auth0.

We have recently started to experience problems when trying to login with the Auth0 Wordpress plugin.
The login page can be reached as usual, but after signing in we are redirected to the Wordpress start page but with /?message=Invalidauthorizationcode added to the URL. See image:

![alt text][1]

Everything was working well a couple of weeks ago, and we have not updated the Auth0 Wordpress Plugin nor the Wordpress Version since the time it was working. Also: there are no new versions available.

I know this issue has previously been on topic in this forum, but the answers have mostly been to check the Base 64 encoding. This, however, is already as it should be. See image below:

![alt text][2]

When checking the Error Log inside Wordpress we get a bit more information:
![alt text][3]

And when checking the Logs inside Auth0 things get more confusing. For every login attempt we get three log items. Success login, Success Exchange & Failed Exchange. See image below:
![alt text][4]

If we click on the Failed Exchange we get the following information:
![alt text][5]

Since our setup was working a couple of weeks ago, it feels like our setup should be fine. In the wordpress plugin we have added (and double checked) the following information from the Auth0 client page: Domain, Client ID, Client Secret, API token. WordPress login enabled and the Login redirection URL is at the default value.

On our client page, inside Auth0, we have added:

Allowed Callback URLs: http://ourwebsite.net/ index.php?auth0=1
Allowed Origins (CORS): http://ourwebsite.net/

So, the bottom line is: we have no clue why this stopped working for us. I have provided all the information I could think of but would be happy to provide more if someone needs it in order to help us. If someone would be willing to take a look at this we would be forever grateful!

Thanks in advance, and happy easter everybody!

Hello, can you do me a favor and look at the network list in chrome and see if you are getting an extra redirect? You should see a call to your login page, then a call to your callback, then a redirect to your main page. I’m wondering if there is an extra call to your callback in the list.

I’m also looking through the code to see if there is an extra call happening to the token endpoint possibly. That is what the error is looking like right now is that the server tried to exchange the code twice. This could happen if the code was somehow sent to the callback twice, or if the callback itself called the /oath/token endpoint.

Do you have Fiddler or something along those lines that you could use to see whether the call to /oath/token is happening twice?

Another question:

Is the login actually working? Are you getting successfully logged in, just showing that message along the URL?

Thanks,

Carlos

@lp please tag me when you have more information. Also, if you have some more information you can share, but don’t want to be public, please create a ticket through the support center and put the information there.

hi @carlos.mostek

Is there any update on this issue?

I am having the same problem with the Wordpress Auth0 Plugin and can’t find a solution anywhere.

Thank you very much in advance.

@carlos.mostek I am having this issue as well. Can you assist?

I had the same issues, with more strange behaviours as well. My steps were:

  1. Export settings from our development website
  2. Install our staging website (running off Wordpress with the Auth0 plugin)
  3. Import settings in the staging website

I also tried to create a new client for the staging website, in case … didn’t work. I either got:

/?message=Invalidauthorizationcode

or

There was a problem with your log in This account does not have an email associated, as required by your site administrator.

So. I did one last thing. I copied the version of the Auth0 plugin from the development website (3.3.2) and installed it on the staging website (which was running 3.5.1). Then imported the settings, and everything worked. So my guess is something broke in 3.5.1.

We are sticking with 3.3.2 until we can safely run off 3.5.1.

For anyone else having this issue after upgrading to 3.5.x, please review the Configuration page on our Docs site:

Specifically:

  • Client Grants on the Client/Application settings page
  • Authorizing the Client/Application for the Management API