Saying "Yes" Is Killing Your Happiness

Well put! Thanks for awesome article!

\


Using Firebase Authentication with the Latest Next.js Features

Hey @hammadz768! Here’s a link to FAQ section in official docs, that should answer your question: <https://next-firebase-auth-edge-docs.vercel.app/docs/faq#where-are-login-and-logout-api-routes-defined>

\
Short answer is: those routes are handled internally by authMiddleware. You don’t need to create dedicated files for those routes.

As mentioned in <https://next-firebase-auth-edge-docs.vercel.app/docs/getting-started/auth-context>, there is no pre-defined way of accessing user data in client-components. 

\
In starter example, I am using React Context to share the token between server and client components: <https://github.com/awinogrodzki/next-firebase-auth-edge/blob/main/examples/next-typescript-starter/app/auth/AuthProvider.tsx>

\
You can follow [Getting Started](https://next-firebase-auth-edge-docs.vercel.app/docs/getting-started) section in docs to create your own `AuthContext` and use it inside Next.js Layout

\
**Verification process**

When later, authenticated user opens your web app, middleware extracts tokens and the signature from user cookies and **verifies it** against **all keys in** `cookieSignatureKeys`

\
**ALL KEYS** part is important, because it enables process called **key rotation** where you can replace **current key** that is used to sign the tokens, while still being able to verify old credentials

\
It can be simplified to this:

\
```javascript
const {idToken, customToken, refreshToken, signature} = parseAuthenticationCookies(headers())
const isAuthenticated = verify(`${idToken}.${refreshToken}.${customToken}`, signature, cookieSignatureKeys);
```

\


Hey! The values you’re asking about should be any string at least 32 bytes in length. Library uses those values to create HS256 signature to verify with the token. 

\
You can use Bitwarden’s Password Generator and change the password length to 32 characters: <https://bitwarden.com/password-generator/#password-generator>

\
To give you a brief overview of how exactly library processes those keys:

\
When you pass `cookieSignatureKeys: [AUTH_COOKIE_SIGNATURE_KEY_PREVIOUS, AUTH_COOKIE_SIGNATURE_KEY_CURRENT]` to authMiddleware, it can be used to **verify** or **sign** keys:

\
**Signing process**

When you call `/api/login` endpoint with `idToken` , the library asks Google to generate three tokens: `Custom token` , `Custom id token` , `Custom refresh token`

\
Then, a **signature** is generated based on the value of those tokens and **the first value** in `cookieSignatureKeys` array.

\
We can simplify the signature process to this pseudocode:

```javascript
const signature = createSignature(`${idToken}.${refreshToken}.${customToken}`, cookieSignatureKeys[0]);
```

\
This signature is then included in authentication cookies attached to the request using HTTP-Only Set-Cookie header.

\


Hey @treendaa! Thanks for your comment and sorry for delayed response. Exactly as you’ve described. If you’re using Nest.js, you’ll probably be using `firebase-admin` Node.js library in one way or another. `firebase-admin` does expose `verifyIdToken` method which you can use to validate API calls made from the client app.

\
In app, you can use `token` string provided by `getTokens` function to attach to your API call in one way or the other. Preferred way is to attach it as bearer token

Hey! Thanks! 

\
I haven’t yet checked out Firebase’s Service Worker Sessions. Sounds like a great feature though. Thanks for a heads up. I will check it out and possibly integrate it into `next-firebase-auth-edge` in the future. Cheers!

Amadeusz Winogrodzki