E_oauth_state_mismatch


#1

Hey! As I updated @adonisjs/ally to 2.1.2, started getting multiple E_OAUTH_STATE_MISMATCH errors. I see state was added in 2.1.0, but I can’t get why do I receive these errors.


#2

Ideally this isn’t meant to be a breaking change

Couple of things to know here:

  1. What’s the URL of the app when you redirect it to the social provider website?
  2. What’s the redirect URL?
  3. Does it happen everytime or occasionally.

The state has been introduced to improve security around hijacked requests. It basically drops a cookie in the user browser and on redirect verifies the cookie to match the state returned by the social provider.

Anytime you can call stateless to disable state verification.

await ally.driver('facebook').stateless().redirect()

However, I want to know the flow that is breaking this?


#3

Hey, thank you for the answer.

Seems like it is very random, I don’t have these issues with any of two providers (google, facebook), some users report it, some not.
I checked my cookies config, it was outdated a bit, added sameSite: false, not sure if it may help in any way.

The url for initial redirect is /auth/:provider/, for response redirect is /auth/:provider/redirect.


#4

It uses the config from config/app.js file under cookie key. https://github.com/adonisjs/adonis-ally/blob/develop/src/Authenticator.js#L29

Maybe you can update that file with following settings.

config/app.js

cookie: {
   maxAge: '240'
}

By default no max age or expiry is set. Browsers considers cookies without any expiry or max age as non-persistent cookies, which are ideally deleted when browser gets closed.

However, I am not sure if some legacy browser is clearing them during redirect also.


#5

Added and deployed, will look into logs in several hours and will report.

Why is it using new cookie setting from app.cookie, but not those from session.cookie. Do they have different scope and meaning?


#6

Yes, scope is completely different.

It’s quite possible that you want your sessions to be available on multiple subdomains or have longer expiry. However, oauth state doesn’t need same settings


#7

Okay, so I guess I know what is the problem.

Client entered the website via www subdomain, from this subdomain being redirected to provider, client returned to non-www address.

Fixed on server redirecting to non-www, but how it can be healed in the app, so the cookies will not count subdomains.