SOLVED: Looking for real SPA behavior for the credentials provider.

[DragoshDX]

Later edit:

Since I didn't get any answers, I dug deep into what next-auth is and what its philosophy is and realized that it's not what I need.
I think that this is the future though, however my organization still needed regular credentials. So JWT stored in a secure http cookie and a user and authenticated key in my redux store did the trick.

Hello.

I have followed the documentation to customize my signin page, using the user and password credentials provider, and it works, however, I don't understand how I can make this work via Ajax. I can't have my SPA redirect and refresh users on login and logout :)).

Here is what I tried to get that going:

1. Custom page for signing in which is also set-up for the error in [...nextauth] in order to have the user go back to the page and add their credentials when the login failed. This is a server response model, doesn't help me, it refreshes the page.
2. I briefly tried the signIn() function that next-auth provides; however it just redirects, and sends the same response as rendered HTML, not SPA...
3. That hasn't worked, so I implemented the credentials form as exemplified here:
   https://next-auth.js.org/configuration/pages
   still server response and still not SPA :(
4. Next thing was trying to do the POST request manually with Axios to either /api/auth/callback/credentials or /api/auth/signin/credentials; This was moderately successful in the sense that yes, I no longer get a refresh, and the session is indeed correctly created. The problem is that that POST endpoint returns nothing... I did try to add json: true, as specified in another discussion, but still nothing.

Basically, I guess, what I need is a sane response to that /api/auth/signin/credentials endpoint so that I can either show an authentication error or just redirect the user to wherever they wanted to go via the callback URL (which I can probabil access via the Router).
Question: do I need to implement it in [...nextauth]? Is there an example?

And I guess, tl;dr:
Is there any way that I can use the credentials provider to provide true SPA behavior?

I can provide more details, I'm stopping now and going back to hacking the thing so this question doesn't become overwhelming and gets ignored.

Best regards,
Dragos.

[DragoshDX]

Perhaps a very obtuse way is to do the following.

Do the requesti via Ajax (authentication is just my client-side Axios api instance).
Wait for it to finish (it definitely works and it is binding a session if credentials are right, but it just doesn't do anything good anymore from there)

After it's finished, I get a session using getSession (useSession didn't work in my Ajax callback) and if I have a session that means the user is authenticated and I can just programatically navigate tthe router to wherever I need ( I will grab the callback URL from the router, this is just a simple test)

However, I do believe this is probably not the way it's intended to work (why is that json: true, there? it should have worked, based on another discussion I've read).

That said, this is the way I did in fact get my SPA behavior (even though I will have to keep track of callbackURL manually).

The same problems happen to signOut... it needs to have a csrfToken which sometimes may have to be downloaded via ajax, so after the token is downloaded I try to call: POST /api/auth/signout. based on https://next-auth.js.org/getting-started/rest-api

It takes it FOREVER to actually sign the user out. I'm definitely not on the right track here, but if no other recommended solution pops-up this will probably have to be it...

authentication
            .post('/callback/credentials', {
              csrfToken: csrfToken,
              username: values.email,
              password: values.password,
              callbackUrl: 'http://localhost:3000/auth/signin',
              json: true,
            })
            .then(async () => {
              setSubmitting(false);
              const session = await getSession();

              if (session) {
                router.push('/');
              }
            });`
            
            
            

[iaincollins]

Hey there!

Thanks for the write up!

Is there any way that I can use the credentials provider to provide true SPA behavior?

So, it's it is designed for what is called a "confidential" OAuth flow (rather than a public one) where the client/secret is server side and not visible to the client. This has security advantages over public flows that are 100% client side. This flow involves redirecting the client to another host and back again so for OAuth flows we need to do that.

However, we could support signing in via popup window to avoid reloading the main app (and instead fire a cross window event back to the app), but we don't support that explicitly at the moment.

However, I do believe this is probably not the way it's intended to work (why is that json: true, there? it should have worked, based on another discussion I've read).

Ah good question! That is there to support the client API methods like signIn() and signOut(). The API endpoints support normal form submissions (for clients that do not support JavaScript) but also JSON responses so the client can read the redirect URL that is returned (as fetch isn't able to access headers to do that, annoyingly). It's also useful for returning errors to the client.

I think there is some reason we use json=true instead of Content Type headers but I can't remember what that is (maybe they can't be set in some scenarios?). I hope it's documented in the comments but I'm not sure if it is.

FWIW using signIn() with the credentials flow should almost give you the behaviour it sounds like you are looking for, although there is some client code which currently forces a window.reload to the redirect URL on sign in, so yeah you'd need to write your own signIn function right now.

There is an issue (maybe closed now by the bot?) with a discussion about that and ways we could allow folks to have it not do that (like pass an option to signIn with a custom redirect handler). That seems like something we could pick up.

[DragoshDX]

Hello.

Thank you for taking the time to read and process this.
As you may imagine, my organization had to move on so I eventually did it the Redux, including server side Redux with next. My luck was that we don't require login via anything at this time, and if the need ever arises, I will do it on the API side with Passport and still generate a custom JWT for my users.

Ah good question! That is there to support the client API methods like signIn() and signOut(). The API endpoints support normal form submissions (for clients that do not support JavaScript) but also JSON responses so the client can read the redirect URL that is returned (as fetch isn't able to access headers to do that, annoyingly). It's also useful for returning errors to the client.

I see, this depends on how you design the API, however, my first instinct was that by adding the key there, I would get a JSON response instead of the whole reload process. Of course, I tested it and it proved to not be the case.

All these being said: I think this is the future of authentication (I see Vercel does use a form of public oauth, possibly even next-auth?), which is why I would like to share my other findings because it might help someone in the future.

I believe I know what other issue you speak, of I might have been there as well :)
Could it be this issue:
#167 (comment)

It looks like a bunch of people need to support both a private JWT and public ouath, the latter is a real strong point for using next-auth as it works so well out of the box for what it was intended.

Here's a thought that might help these users still posting there:
What if instead of relying on the signin page that next-auth provides, one might hardcode a couple of buttons such as Google, Facebook, etc, then use the client API:
https://next-auth.js.org/getting-started/client#signin
The signIn method supports the string name of the provider we would like to authenticate with, so essentially the user would be transported to the Google auth screen (or permissions pop-up if they're already logged on Google), and a reload is mandatory and expected for such actions.
Then one would use the next-auth hooks, to also generate a user on the custom API platform (whatever it may be) and link that local user with the social auth provider ID.

The login form would still work via POSTing to the custom API and obtaining the custom JWT.

It might be a less obtuse way of next-auth developers having their cake and eating too.

Best regards,
Dragos.