Simplify authentication by leveraging CSR + CORS

On the frontend it should be possible to do it in nuxt3 as outlined here:

You need to create a Nitro server middleware. Then you have a way to hook into every server request.
The middleware function gets event as the first argument.
Within the middleware function, you can use getCookie from h3 to check for your cookie.
Then, based on that, you can set event.context.nuxt.noSSR to true.

Untested code:

// @/server/middleware/dynamic-no-ssr.ts

export default defineEventHandler((event) => {
    const myCookie = getCookie(event, 'myCookie');

    if (myCookie) {
        event.context.nuxt = event.context.nuxt || {};
        event.context.nuxt.noSSR = true;
    }
});

Based upon the latest meeting with Dan and longwave we came up with two alternative solutions, leveraging nuxt proxying:

Option Proxy-API:

• Add route-rules for proxying /ce-api to the backend
• Provide Drupal login form on /user/login in the frontend, so the cookie will be set in the frontend
• People can / will have to login separately on frontend and backend
• Optionally, also proxy files to go via the frontend, so the backend URL would not leak through at all

Option Proxy-All:

• The same as Proxy-API, but also proxy the editorial-experience (/admin) through the frontend.
• The challenge here would be to ensure we get a complete list of to be-proxied-paths to the frontend, so the Drupal backend would work correctly.
• People use the site only from the frontend domain, for adminitration and editing as well.

It would be nice, if we could figure a way out to allow Drupal to return a list of to-be-proxied routes to nuxt.

Letting this sink, I think the option "Proxy API" is the way go here. For that we need to do https://github.com/drunomics/nuxtjs-drupal-ce/issues/165 and then provide the user-login on the frontend.

Would it make more sense to use a robust module on the Nuxt side for Auth?

Such as:
https://github.com/sidebase/nuxt-auth

This way the communication, along with permissions and roles can be used?

@glynster: Thanks for your suggestion!

I'm not a big fan of adding something like nuxt-auth in the frontend, since it complicates the frontend stack, e.g. it becomes harder to support multiple frontends, upgrade nuxt majors, etc. But that said, nothing would speak against supportin this optionally. The advantage would be that it makes the frontend aware of permissions via oauth scopes, right?
Admin menu would definitely be a nice use-case, but in the end we only need a simple flag in page-api responses that tell us whether the users has backend-access/permission or not. Use-cases for permissions to check vary, so we could add a feature to allow permissions to be sent to the frontend as part of the page-api response. It smells a bit like a (simpler) rebuild of oauth-scopes though.
Maybe let's add a feature request and work on supporting that in a dedicated ticket?

As default, I think the cookie based access is fine, we just need to finish https://www.drupal.org/project/lupus_decoupled/issues/3336148 📌 Add support for forms Needs review to have user-login forms on the frontend working.

@fago I had actually thought of the permissions/roles being added to the API. I was thinking it makes sense to have a current_user section. Much like the response from /user/login. Then you have more flexibility and keeps things very simple. I agree with the complication of Nuxt Auth. As you say once the forms are connected I think this solves a lot of things. Then users can login from either end and all works as needed.

As to the admin menu then you could have a welcome back or username along with a logout.

Rock on for

user-login forms on the frontend working

FYI: We have managed to hook in Nuxt Auth for our use case. This enables clients to login through a general form using /user/login and user/logout. We use the rest api We also push the new cookie from the response header to the front end which keep font/back end in sync. As well as that we have a session with access to the standard user info. Within that session we have access to csrf_token so we could perform user/node updates if needed. So far so good!