Why only server side

[ennioVisco]

Thanks a lot Atinux for the great work!

This module is very clean and easy to understand!

My question is what are the reasons for which it is only server-side, by looking at the endpoints it seems that code could easily be in pages or composables, so, why the limitation?

[atinux]

Hey @ennioVisco

Because the session / cookies system I use is relying on httpOnly cookie that can be accessed when we have a Nuxt server.

What are you building that does not need SSR?

[ennioVisco]

It's not that it does not need SSR, it's more like SSR is a gigantic burden with negligible benefits:

• it makes the deployment pipeline more complex
• it makes the state management much more complex, because we have to handle 2, with different information
• we are nuxt3 early adopters, I'm very passionate about the project, but until yesterday a lot of pieces had to be managed by us (e.g. we are on AWS and switching from static delivery to a server is not that trivial, nitro had basically no AWS support until a few days ago, and still the current one seems pretty superficial), and several are still very early.
• Lastly, we want to adopt SSR but progressively, we tried several times by doing static generation with SSR on and reverted because of several issues popping up, same about moving to a server side, ideally we will stick with a solution that works on the client side and progressively move to get that 0.3s of loading time benefits.

[atinux]

The thing is that we need an API endpoint anyway to store the cookie, so even without SSR you will need to run a node server, would that be OK to you?

[ennioVisco]

The thing is that we need an API endpoint anyway to store the cookie, so even without SSR you will need to run a node server, would that be OK to you?

But I don't get why: couldn't a sessionStorage or localStorage serve the purpose? This is for example how amplify does: https://docs.amplify.aws/react/build-a-backend/auth/manage-user-session

[atinux]

This module leverages h3 sealed session and httpOnly cookie to avoid XSS attacks.

I guess Amplify store the session in database to get back the values?

[ennioVisco]

This module leverages h3 sealed session and httpOnly cookie to avoid XSS attacks.

I guess Amplify store the session in database to get back the values?

I'm not sure what you mean, sorry, I'm not a super expert on authentication protocols. Here is how Cognito (the AWS service Amplify wraps) works:

Picture source

From my understanding, it is an OAuth 2.0 flow where:

• the Identity Provider is the classical OAuth provider, and therefore should not be handled by Nuxt
• the API (right of the chart) might or might not be a Nuxt application, depending whether the server folder is present
• the Amazon Cognito User Pool is probably the part where we cannot understand each other, it serves as the software middleware that handles the flow and is responsible for creating the credentials. This part I believe is the one where nuxt "requires" to have a server, but that is often provided by auth providers (see also Kinde, that has a nuxt module: https://kinde.com/docs/developer-tools/nuxt-module/). So I guess in this case a nuxt-auth-util library could serve as a standardized way to manage coherently the session on the client side, ignoring what will happen on the other side

[ennioVisco]

This module leverages h3 sealed session and httpOnly cookie to avoid XSS attacks.

I guess Amplify store the session in database to get back the values?

I think I get your point now, you want to enforce the encryption and the adoption as an httpOnly cookie.
I feel these could be two fairly restrictive design choices, and not strictly related to session management as a whole, but I understand if it is the direction you are willing to pursue.

It goes without saying that if you want to enforce server-side encryption, there is no way to have this library without ssr :)

[atinux]

Also the fact that all utils are server-side for OAuth.

[alexcroox]

If you've ever built a hybrid native app (Capacitor.js) with a web version you'll know the different hoops the client has to jump through for Apple and Facebook Oauth depending on if you are native or web. One thing that remains the same is the API code thankfully, so a module like this can be used.

[mbergen]

Reading this, it seems like there are no plans to ever support nuxi generate, is that correct?

[atinux]

Not at the moment @mbergen

What's your usage of authentication on a nuxt generated application?

[mbergen]

What's your usage of authentication on a nuxt generated application?

I have an API I need to authenticate against with an OpenIDConnect token, which the generated nuxt frontend needs to send with all requests.
Therefore a user has to login with that, which the nuxt2 auth module made possible

[jonas87]

What's your usage of authentication on a nuxt generated application?

I have this use case as well. Python FastAPI backend with auth handled through JWT access and refresh tokens. SEO or initial loading time is not important, makes more sense to run the frontend as static SPA.

[atinux]

One of the issue when dealing with static generated content is when you have the Auth state in the header for example, then the "login" button will be generated at build time. You will have to wrap this with <ClientOnly> for example, would that be ok?

[mbergen]

One of the issue when dealing with static generated content is when you have the Auth state in the header for example, then the "login" button will be generated at build time. You will have to wrap this with <ClientOnly> for example, would that be ok?

I might be too inexperienced here, but I don't see what the issue with that is (e.g. right now with nuxt2+nuxt/auth, I don't have a login button on every page, but rather redirect to a dedicated login page with a Middleware if someone is not logged in)

[jonas87]

One of the issue when dealing with static generated content is when you have the Auth state in the header for example, then the "login" button will be generated at build time. You will have to wrap this with <ClientOnly> for example, would that be ok?

Hi Sébastien, I will soon be migrating from Nuxt 2 to 3, It would be nice to have in these auth utils a flow for "Local/refresh" as it was called in nuxt/auth, and that it would work for SPA apps. In case of precompiled apps I think indeed it would make sense to wrap in <ClientOnly>

[atinux]

it would be nice if you can test implementing yourself the authentication using Nuxt useCookie and your own Vue composable :)

[jonas87]

I will look into it when I start migrating. I just saw the PR request for jwt local auth #17. I understand from the discussion there that the Nuxt team considers full flows for clientside token based schemes out of scope for nuxt-auth-utils, but rather than providing all of the flow in one event handler may still consider small composable utility functions that could be used to build a jwt flow?

[luminous8]

The thing is that we need an API endpoint anyway to store the cookie, so even without SSR you will need to run a node server, would that be OK to you?

Would love to be able to use this module without SSR (but deployed on a nodejs server) - my understanding is SPA !== static
My use case is that users can log in on my website, and SPA mode offers better UX than SSR (feels faster)

That's not doable at the moment with the plugin, right?

tldr: i need SSR for crawlers and not logged users and SPA for non logged users

[reslear]

I agree that we need local support.

[atinux]

@luminous8 very good timing as I have been working the last days on supporting SPA & SSG/SWR but it will need to use nitro-nightly

[luminous8]

@luminous8 very good timing as I have been working the last days on supporting SPA & SSG/SWR but it will need to use nitro-nightly

Awesome news!
what’s nitro nightly? Is it included with Nuxt?

[atinux]

Read more on https://github.com/atinux/nuxt-auth-utils?tab=readme-ov-file#hybrid-rendering :)