fix: api routes not receiving real host, leading to localhost redirect after login

[MichaelErmer]

This fix resolves next auth not using the correct hostname for requests using the API methods, which ultimately led to users being redirected to localhost:3000 after login if next run behind a reverse proxy.

☕️ Reasoning

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

📌 Resources

• Security guidelines
• Contributing guidelines
• Code of conduct
• Contributing to Open Source

[vercel]

Someone is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2024 3:38pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Mar 19, 2024 3:38pm

[MichaelErmer]

Anything I can do to speed this up?

[ndom91]

Did you enable AUTH_TRUST_HOST (docs) or try the AUTH_REDIRECT_PROXY_URL (docs)?

This should be covered by those two options. Let me know if those still don't work for you 🙏

[MichaelErmer]

Yes, set both, but still the redirect after idp led to localhost.

[ndom91]

Are you sure you updated the callbackUrl in your OAuth providers dashboard?

We've got an example for Docker up at https://nextjs-docker-example.authjs.dev which does work behind a reverse proxy with all providers 🤔

[MichaelErmer]

Are you sure you updated the callbackUrl in your OAuth providers dashboard?

We've got an example for Docker up at https://nextjs-docker-example.authjs.dev which does work behind a reverse proxy with all providers 🤔

Do you suggest using an absolute callbackUrl in the signIn call?
We are using multiple domains and I think the trust-proxy-option should enable the auth to use the domain from x-forwarded-for 🤔

Our IDP (Cognito) is accepting multiple callback URLs, however, without the changes above, the next auth was initializing the signIn with localhost:3000 as callback... We tried both the ENV vars you mentioned and all combinations.

[ndom91]

@MichaelErmer ah okay I think I see what you're saying.

No so you don't have to pass an absolute URL to the signIn() call, but you do have to modify your callbackUrl to be the correct (prod?) URL instead of local dev. I'd recommend two apps in your IdP.

We ran into this a few times, I forget if Cognito was one but I assume from what you're saying it is - Twitch, for example, allows adding multiple callbackUrls, but it'll always redirect to the first one. So if you add a local dev callbackUrl (http://localhost:3000/api/auth/twitch) and a prod one (https://app.company.com/api/auth/callback/twitch), it'll always only set the first (local) one as callbackUrl after coming back from the authorization_url redirect, no matter what

If you create two separate OAuth applications in your IdP, you'll just have to use two sets of separate clientId/clientSecret env vars, 1 for dev 1 for prod, just like with Github for example.

[MichaelErmer]

I understand what you are saying, we wouldn't want our customers to have to setup multiple Apps on their sso for different systems of us, they whitelist only our tld or a list of domains.

This change fixes the issue, in a generic way, by initiating the signIn at the IDP using the (from users perspective) correct return url, whilst ensuring and respecting trust host is enabled etc.