인프런 커뮤니티 질문&답변

refreshToken는 백엔드 로직에서 디비와 쿠키에 저장하고 있습니다.

프론트 서버에서는 next-auth로 로그인하고, 백엔드 서버에서는 access token으로 인증하는 식인 것입니다. 저는 그래서 프론트 서버에서 먼저 로그인하고, 프론트 서버가 백엔드 서버의 로그인을 진행하여 access token을 발급받는 식으로 합니다.

이 부분이 조금 이해가 어려워 추가 질문 드립니다.

1. 말씀하시는 프론트 서버 로그인과 백엔드 서버 로그인이 어떤 부분이 다른 것일까요? 느낌상 프론트 서버에서의 protected page를 접근하는 것과 백엔드 서버에서 api활용을 위한 token에 대한 것이라고 생각이 듭니다. 이해한것이 맞을까요?

2. 답변해주신 내용과 강의 내용을 토대로 이해해본 바로는 auth.ts (강의 섹션4: 서버 쿠키 공유하기)의 connect.sid 를 세팅하는 부분이 답변에서 말씀해주시는 부분이라고 생각드는데 맞을까요?

기존에 저는 서버에서 accessToken을 받으면 해당 토큰은 decode하여 id, email등은 zustand로 관리하여 user정보를 관리하는 방식을 사용하였습니다. 이것으로 로그인 여부를 판단해 프론트의 protected page도 접근하였구요.

그렇다면 위 과정을 적용하고자 할 경우, auth.ts 파일에서 authResponse로 서버에서 받은 access token을 decode해서 user에 삽입하고(protected page 유저 검증),

이 토큰을 connet.sid로 셋팅(서버 전송 access token)하면 되는 것이라고 생각듭니다! 혹시 이 과정이 맞을까요?

현재 실습이 어려운 상황이라 질문을 먼저 남깁니다 ㅠ 감사합니다.

1. 네 맞습니다. 프론트 서버는 페이지 접근, 로그인/로그아웃을 담당하고, 백엔드 서버는 api 호출을 담당합니다.

2. 네 connect.sid가 백엔드 토큰입니다. 강의에서는 쿠키를 활용한 것이고요.

3. 네 일단 과정은 맞는데요. 다만 프론트에서도 auth-js.session-token같은 쿠키를 따로 활용해서 인증 관리를 하고있어서 프론트 로그인은 별개입니다.

안녕하세요. 말씀해주신 부분 참고하여 많이 진행하였습니다. 감사합니다.
추가적으로 어떤 것이 더 좋은 방법 일까 궁금한 부분 있어 질문 남깁니다 !

백엔드에서 발급 받은 백엔드 호출을 위한 rt, at 입니다.

1. rt, at 둘 다 쿠키에 저장하기 (혹은 at: zustand)

2. rt 쿠키에 저장, at 세션에 저장하기

저는 2번에 대해서 보안 문제 때문에 1번 방법으로 진행하며, 유저 정보는 세션에 저장하고 진행하고자 하였습니다.

그런데 https://next-auth.js.org/configuration/callbacks#jwt-callback 글을 참고하여 at를 세션에 저장해서 사용하기도 하는 것 같은데 어느 방법이 더 좋은 방법일지 궁금합니다.

하단 저장 코드입니다.

export const { handlers, signIn, signOut, auth } = NextAuth({
  pages: {
...
  },
  providers: [
    Credentials({
      credentials: {
        email: { label: "Email", type: "email" },
        password: { label: "Password", type: "password" },
      },
      authorize: async (credentials): Promise<any> => {
        const res = await login(
          credentials.email as string,
          credentials.password as string
        );
        const result = await res.json();

        if (res.status === 401) {
          const errorMessage = result.message;
          throw new Error(errorMessage || "Failed to login");
        }

        let setCookie = res.headers.get("set-cookie");

        if (setCookie) {
          const parsed = cookie.parse(setCookie);
          cookies().set("token", parsed["token"]); // set refresh token
        }

        const { accessToken } = result;

        if (res.ok && accessToken) {
          cookies().set("connect.sid", accessToken); // 1번 : 쿠키에 저장
          const user = jwtDecode(accessToken);

          return {
            ...user,
            accessToken,
          };
        }

        return null;
      },
    }),
  ],
  callbacks: {
    async jwt({ token, user }: { token: any; user: any }) {
      if (user) {
        token.id = user.id;
        token.email = user.email;
        token.nickname = user.nickname;
        token.image = user.image;
        token.role = user.role;
        token.accessToken = user.accessToken;
      }

      return token;
    },
    async session({ session, token }: { session: any; token: any }) {
      if (token) {
        session.accessToken = token.accessToken;
        session.user.id = token.id;
        session.user.email = token.email;
        session.user.nickname = token.nickname;
        session.user.role = token.role;
        session.user.image = token.image;
      }
      console.log("session", session); // 2번 : 세션에 저장
      return session;
    },
  },
});

2번에 대해 보안문제가 있다하셨는데 무슨 문제가 있나요? 그리고 refresh token을 쿠키로 전달하시는 거면 replay attack이나 csrf 공격에 대한 대비는 하셨나요? 애초에 저는 프론트에 왜 리프레시 토큰을 내려보내야 하는지 잘 모르겠습니다.

우선, 저는 rt의 경우가 at 갱신 용도로 사용하고 있습니다. at만료시 갱신 용도로만 활용되기에 rt가 at보다 유출에 대한 위험성이 적다고 생각했습니다. csrf 등 공격에 대해서도 쿠키의 secure, httpOnly등 옵션으로 저장할 경우 비교적 타협이 가능하지 않을까 하는 의견이였습니다.

반면 at의 경우 직접적으로 백엔드 서버 reqeust에 활용이 되니까 더 보안을 신경써야하지 않았나 싶었고 브라우저 쿠키보다 세션이 더 보안상 취약하지 않을까?라는 생각이였습니다.

(이 부분은 방금 더 확인해보니 세션이 쿠키와는 달리 서버에 저장이 되기에 더 보안상 더 강하다고 하는것을 확인하였습니다.)

프론트에 왜 리프레시 토큰을 내려보내야 하는지 잘 모르겠다고 하셨는데 혹시 백엔드 서버 request를 위한 리프레시 토큰과 엑세스 토큰을 어떻게 유지하는 것이 더 좋은 방법이라고 생각하시는지 알 수 있을까요?

현업에서 어떤 방법으로 사용하는지 잘 몰라 어떤 것이 더 좋을지 여쭤보고 싶었습니다.

일단 리프레시 토큰이 훨씬 더 중요합니다. 리프레시 토큰이 털리는 순간 액세스 토큰을 무제한으로 발급할 수 있기에 리프레시 토큰이 털린다 = 모든게 다 털린다와 동일한 의미입니다. 그래서 프론트로 아예 내려보내지 않고요. 그냥 DB에 넣어둔 뒤에 액세스 토큰 재발급 요청을 서버로 보내시면 됩니다. 액세스 토큰은 수명이 짧아서 로컬스토리지/쿠키/메모리 등에 필요에 따라 넣어두시면 됩니다.

추가로 csrf 공격은 secure/http 쿠키로 해결되지 않습니다.

아 그런 이유도 있을 것이라고 생각 못해봤네요.. 재발급 로직을 수정해야겠습니다 ㅠ 감사합니다 !

좋은 강의 덕에 더 공부하고 알아갑니다 ! 감사합니다 !