How to SECURELY connect my next.js frontend with next-auth to my springboot backend

[Buzzet]

Question 💬

I am building a frontend with next.js right now, which authenticates with GitHub OAuth using next-auth.

Next-auth handles all the authentication including the session and saves all that into a database, in my case a Postgres DB.

I now also want to connect my frontend to a spring boot backend server via REST API, which handles some file access. I could simply include the session token into the authorization header and connect my backend to the Postgres DB also and check if a session with this token exists.

But this approach seems not right. What is the best way to secure my backend here? How can my backend check if the user is logged in with GitHub?

How to reproduce ☕️

Like mentioned above

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[mtt87]

It might not be the best approach as you are sort of delegating the auth mechanism to the frontend (well the backend of the frontend, the nextjs serverless function) while your real backend is somewhere else.

We also use spring boot but do things a bit differently:

• our frontend is authenticating with our spring backend which is exposing a valid oAuth2 (OIDC) provider, this is because we want people to authenticate "with us" not "with google/github etc".
• we include a query param in the login service provider_id so we can support social login with GitHub/Microsoft/Google/Apple etc
• this means that the code exchange and token exchange with the IDP (google, github etc) happens with our spring backend, not nextjs which we consider just a frontend extension of our service.
• we then exchange an access_token and refresh_token to communicate with our backend. This is not the access_token issued by the IDP (google, github etc) but it's our oAuth2 issuing this token.
• the frontend then has a token that can use to perform API requests to our services.
• it's up to you how you wanna store this token either by using a DB or by using an encrypted JWT (so you decrypt it to fetch the access_token on the serverless function and you are not saving the access_token in clear visible to the client (bad practice))