Auth0 Home Blog Docs

How do I avoid a0.invalid_state

auth0
login

#1

I am trying to get the login callback working. Currently it looks like this…

@GetMapping("/callback")
protected void getCallback(
        final HttpServletRequest req,
        final HttpServletResponse res
) throws IOException {
    service.handleCallback(req, res);
}
...
public void handleCallback(HttpServletRequest req, HttpServletResponse res) throws IOException {
    try {
        Tokens tokens = controller.handle(req); // breaks here
        TokenAuthentication tokenAuth = new TokenAuthentication(JWT.decode(tokens.getIdToken()));
        SecurityContextHolder.getContext().setAuthentication(tokenAuth);
        System.out.println("Questioning Reality Because it is redirecting correctly");
        res.sendRedirect(redirectOnSuccess);
    } catch (AuthenticationException | IdentityVerificationException e) {
        System.out.println("We are where I thought we would be");
        e.printStackTrace();
        SecurityContextHolder.clearContext();
        res.sendRedirect(redirectOnFail);
    }
}

But when it gets to the point where it breaks it says the state is invalid. If I check my Auth0 logs I see a successful login. What am I missing? I am using mod_proxy if that could be doing something.

The error I get is…

com.auth0.InvalidRequestException: The request contains an error: a0.invalid_state
	at com.auth0.RequestProcessor.assertValidState(RequestProcessor.java:181)
	at com.auth0.RequestProcessor.process(RequestProcessor.java:103)
	at com.auth0.AuthenticationController.handle(AuthenticationController.java:141)

#2

I can run it locally and it works. When that happens at this line…

return getSession(req).getAttribute(name);

I debug and run

getSession(req).getAttributeNames().hasMoreElements()

On the local I see true, but on the remote instance I see false. Could it be that the mod_proxy is causing the session info to be lost?


#3

Hey ,

Did you find out a solution for this ? am having the same issue when I redirect the callback to localhost ?


#4

Hi,

Did you manage to fix this issue, if yes could you please post the solution.


#5

I ran into a similar issue. Digging into the source I saw that the root problem was failing in com.auth0.RequestProcessor.assertValidState. The problem was that the Auth0 state variable was set in the request but not in the session. I’m using the v11 of the embedded locket widget, and during the upgraded from v10 to v11 it looks like the lock widget will set the the state variable to a nunce if you don’t specify it.

My solution was to set the state myself in the Lock config to a nunce I generated myself and then also make sure it got set in the session when the lock page is initially served.

Hope that helps