is it possible to sign in with multiple providers at once?

[stardvst]

hello,
i'm wondering if it's possible to be logged in with more than one provider at the same time with next auth?

say my home page provides number of login options (auth providers), and user logs in with one of them. after that i want to allow to log in with the other providers from within the application as well.
basically something like "connected apps" feature.

is that possible?

[dbeaudway]

I don't believe so but it's been requested a few times and an issue is open to implement here: #2988

[stardvst]

thanks for the info, will follow it.

[iaincollins]

It is and it's always worked that way since v1 (unless that functionality has been removed in v4...).

In v2 onwards it's not really clear when that is happening visibly (and there is no explicate API for linking/unlinking, which there was in v1; that functionality has been replicated yet), but under the hood it does link accounts.

i.e. if you sign in with an OAuth provider, and while still signed in to it sign in with another OAuth provide, it will link them to the same user and then you can sign out and sign back in as the same user account with either OAuth account.

The caveat to this is you need a database for this with NextAuth.js. Account linking without a database wouldn't let you persist the link beyond the expiry time of a cookie and so would be useful only in limited use cases (though technically possible, it's not a feature unless that has changed in v4).

[balazsorban44]

With databases, it has always been possible, yes. There seems to be interest in JWT only sessions for multiple providers as well though.

v4 will make this possible, actually. Until now, the bigger concern was the 4096 bytes cookie size limit, which is being worked out in #3101, and I have already tested it on a production site at my workplace.

The other issue will be to persist the previous token as outlined in #2988.

Currently, in jwt({ token }), the token is always re-generated, even if there was a previous session token. we could add a new option like jwt({ prevToken }) that could be either the previous value or null. Let's discuss this further on #2988

The main thing to remember here - if I understand this correctly - is that even an encrypted JWT is less secure than storing all that data in a database and retrieving it on demand by a session token, and I think we have to make it more clear in the docs (we do have a brief section mentioning JWT disadvantages in the FAQ, could be even more highlighted IMO.)

BTW @iaincollins, the new default is JWE as suggested/implemented by @panva in #3039 which I fully supported. The default JWT signing is gone as well, as we mainly want people to use our JWT in the app, and use their IdentityProvider's for their third-party APIs. I hope we agree on that.

[raphaelpc]

Is JWT support still planned for v4?