400 error after POST when redirecting with an action

The docs for redirecting with actions indicate that when passing information back to the action this should be done as a POST.

We’re using axios to POST a JWT back to the /continue endpoint, with all the keys that the docs indicates are required (including state), but this results in a 400 Bad Request.

If instead we redirect with a GET putting the session_token and the state as query params, everything works, but this is counter to the recommendation in the docs which (maybe?) indicate that POSTing is necessary ‘to avoid replay attacks’.

Is there something missing from the docs regarding what needs to be included/configured for a POST to the /continue endpoint. Is a GET request a security concern/not recommended?

Hi @davidpmccormick,

Welcome to the Auth0 Community!

Can you please share a code snippet of the POST request you are making? Additionally, can you share the full error message? Usually there is some more info about why the request failed.

Hi @dan.woda

Thanks for getting back.

Here’s the NextJS api route that is handling the POST

Here’s a gist of the error

And a gist of the post-login action we’re testing with for good measure.

As I mentioned, this does work if we do it with a redirect rather than using axios to POST.

Thanks for posting your code! :handshake:

From what I can tell, you are missing the state param in this request:

You should be passing the state param from the original request back like this:


I have to admit, the docs aren’t very clear on this. I am going to submit some feedback to the team and let them know this could be improved.

Thanks @dan.woda.

The state claim is part of the jwt (newToken) i.e. you can see it if you decode the below at jwt.io. Although I had already tried what you suggest, and the error remains the same edit: the error is then a 401 (here’s a gist of that error).


What authorization or config is required/possibly missing here?

1 Like

Hey Dan and auth0 folks,

Really appreciate your help on this. Just wondering if you’re able to help further with this issue? A redirect to /continue with state works but an axios POST to /continue with state doesn’t work (David shared the error above).

The documents don’t make it super clear, should a POST work?

Many thanks for the help, after a few days of debugging and trawling documents any light you can shed or help you can offer would be very much appreciated.


Hi @melrogan, @davidpmccormick,

Sorry for the delay, I think the confusion here is related to next js (I’m not intimately familiar with the framework.)

I suspect this issue is because you are making a post from your backend, and it doesn’t include the cookies needed in the request. Stated in this doc: 401 Unauthorized error when calling /continue endpoint after a redirect from the rules

I am able to make a POST to the /continue endpoint and continue my transaction. here is an example:


1 Like

Thanks @dan.woda

I’d previously pursued that line of enquiry but had concluded it wasn’t the root of the issue. I’ve had another bash this morning, sending all the cookies along with the POST, but still getting a 401.

I’d love to get to the bottom of this for 1. anyone else who encounters this issue and 2. my own sanity. But in the meantime we’re going to resort to using the management API and circumvent the requirement to do it this way.

I couldn’t see any immediately relevant-looking cookies (hence why I sent them all along). Do you know which one/ones we should be looking for?

I’ll probably keep tinkering away at it to see what I’m missing.


I would suspect it would be the auth0 cookie.

Is it possible to make the request from your frontend?

Hi @davidpmccormick,
Were you able to resolve this one? even we are trying to implement the same but only a GET request is working and POST is failing.

@dan.woda , could you please help us with concrete resolution, Also, as per the document it says state should be passed within the token.

I’m afraid we never did @jamie.9 – we ended up opting for a different approach off the front channel. IIRC our suspicion was that the issue was likely to do with cookies not being set, though.