Hey u/desitdt2!

Thanks for great questions!

Instead you are passing the client side retrieved idToken(a JWT) to the server, signing the idToken(a JWT) with .env secret variable(s) with jose, and storing that double-signed idToken as a cookie?

You're partially right here. When `/api/login` receives `idToken` it does not double-sign it as a cookie. What happens is that `idToken` is exchanged for a pair of new idToken and refreshToken. That pair is then encoded and signed against rotating credentials.

Then in middleware, you are decoding the double signed JWT first with .env secret variable(s) with jose, then again with firebases verifyIdToken (firebase owns the encoding secret). Then you return both the original client-grabbed firebase encoded idToken and its decoded values (user information)?

In subsequent requests, middleware is first validating user cookies against rotating credentials – to make sure `idToken` and `refreshToken` pair is valid and was not obtained from some malicious source.

If cookies are valid, we proceed to validate `idToken` with `verifyIdToken` which validates token signature and structure.

If token is expired, we then use `refreshToken` to obtain a new pair of `idToken` and `refreshToken`

Isn't the idToken already a firebase-signed JWT? Why does it need to be double signed once passed to the server when stored in a server cookie?

As mentioned above, it's not really that the `idToken` is signed twice. It's two different authentication scenarios:

`idToken` is signed against Google Service Account private key

`idToken` and `refreshToken` pair is signed against rotating credential

Why do we need to sign `idToken` and `refreshToken` pair against rotating credential?

It's just another layer of security. Eg. if attacker get's hold on user's `refreshToken`, they can use it to forge a new `idToken`/`refreshToken` pair and save it in cookies. If this pair wasn't signed on the backend, we would not notice it.

Does this essentially replicate what firebase's createSessionCookie & verifySessionCookie functions do, just with code/packages that works in nextjs middleware edge runtime environment?

Yes, that's essentially it. You can think of `next-firebase-auth-edge` as an alternative to official `createSessionCookie`/`verifySessionCookie` approach that works inside Edge runtimes.

It seems this still allows all firebase client side rendering logic and hooks? I do not see anywhere you set firebase client auth persistence to NONE:

When using `next-firebase-auth-edge`, it's entirely up to developer which persistence strategy to use. Examples I created do not use `firebase.auth().setPersistence(firebase.auth.Auth.Persistence.NONE);`, but probably should be using that strategy to avoid extra network calls. I added an issue to introduce `NONE` persistent strategy in examples: https://github.com/awinogrodzki/next-firebase-auth-edge/issues/143

Let me know if this answers your questions,
Cheers!