Multiple signIn endpoints for local provider

[despatates]

Describe the feature

It could be nice to have many auth configs or providers. Currently, we can only have one setup.

My application uses the local provider with an external API.
Depending on the business workflow, I must use different endpoints to authenticate the user. Once authenticated, the tokens are the same as well as the refresh logic, no matter the endpoint used.

I can't override the endpoint settings when calling the signIn() method.
I'm currently overriding the configuration on demand (not clean but it works).

let initialSignIn
const config = useRuntimeConfig()
const { signIn } = useAuth()

try {
  // [...]
  initialSignIn = { ...config.public.auth.provider.endpoints.signIn }
  config.public.auth.provider.endpoints.signIn = {
    path: '/other/endpoint/path',
    method: 'post',
  }

  await signIn(
    {
      /* payload for the use case */
    },
    { callbackUrl: '/' },
  )
} catch (error) {
  // [...]
} finally {
  // revert the initial settings
  if (initialSignIn) {
    config.public.auth.provider.endpoints.signIn = initialSignIn
  }
}

Maybe there is a clean way to do it? If so, let me know.

How would you implement this?

The short way: Be able to override the settings set in the nuxt.config.ts file when calling signIn().

The long way: Be able to define many configs or providers in the nuxt.config.ts file.
In the nuxt v2 plugin, I used several strategies with local scheme, and it was perfectly matching my use case.

Additional information

• Would you be willing to help implement this feature?

Provider

• AuthJS
• Local
• Refresh
• New Provider

[phoenix-ru]

The long way: Be able to define many configs or providers in the nuxt.config.ts file.

Sorry to say it, but I highly doubt NuxtAuth will ever support strategies and schemes the way v2 module did.

The short way: Be able to override the settings set in the nuxt.config.ts file when calling signIn().

This is actually one of the big plans for local provider in 2025 - to be able to define hooks and customize requests/responses of the local provider. It is still in the ideation phase though, but you can certainly contribute to it with any input here: #964. In fact, I added your usecase to the issue.