Auth: Cookies not properly set?

[srodriki]

SST Version: 0.0.368 Platform: MacOS Cloud: aws

I've implemented a simple Adapter for Auth that does email/password validation. I'm using the /authorize endpoint to handle this. Here's a code snippet:

import { Adapter } from 'sst/auth'
import { AccountService } from "@glue/core/models/account";
import { Hono } from 'hono'
import { AdapterOptions } from 'sst/auth/adapter/adapter';

export const EmailPassAdapter = (() => {
  return function (routes: Hono, ctx: AdapterOptions) {
    routes.post('/authorize', async (c) => {

      const body = await c.req.json()

      if ( body.email && body.password) {

          /* OMITTED: GET USER AND VALIDATE */
          userRecord = /*stuff from db*/
          return ctx.success(c, { claims: userRecord.data as any });
        }

        throw new Error('User does not exist')
      } else throw new Error('Bad request')
    })
  }
}) satisfies Adapter<{ claims: Record }>;

Expected results The expected behavior is that after I've validated the user's data, I continue with the success path for the auth call.

Actual Results

getting this exception:

UnknownStateError: The browser was in an unknown state. This could be because certain cookies expired or the browser was switched in the middle of an authentication flow
 at Object.success (/Users/rodri/dev/sqquid-next/node_modules/sst/dist/auth/handler.js:75:78)iiI

Observations First of all, the error is thrown from here. It basically tries to read the redirect_uri from the cookie, instead of, for example, from the querystring, as it happens in other parts of SST.

Workarounds I've tried

So, I've already:

1. Verified that redirect_uri is part of the cookies before I call ctx.success
2. Re-added redirect_uri to the cookies just in case.

Any pointers into what am I doing wrong will be much appreciated

[thdxr]

do other adapters work properly?

[srodriki]

@thdxr I've tried, for instance, the LinkAdapter and it works in regards to the example I shared above:

I get redirected to my redirect_uri, though in this case I see the token as a hash parameter instead of a querystring parameter (which is expected based on this ):

http://localhost:3000/#access_token=eyJh...

[rracariu]

LinkAdapter would error the same when processing the callback token /link/callback?token=...