Skip to content

커스텀 인증 로직

tnghd5761 edited this page Dec 22, 2022 · 1 revision

커스텀 인증 로직

  • 기존 방식

    image

    • 처음에는 Nest.js document를 따라 passport 기반 인증 방식을 도입했습니다. 하지만, 이 방식은 access token만 사용했기 때문에 access token이 탈취될 경우에 대한 대비가 이루어지지 않았습니다.
    • access token 탈취를 대비하기 위한 가장 간단한 방법은 access token의 유효 기간을 짧게 두는 방식이었습니다. 그런데 access token의 유효 기간을 짧게 두면 유저가 자주 로그인을 해야 한다는 불편함이 있었습니다.
    • 이를 극복하기 위해 유효 기간을 길게 두는 refresh token을 도입하고 이를 이용해 access token을 갱신할 필요가 있었습니다.
    • 하지만, 단순히 access token의 유효 기간은 짧게 refresh token 의 유효 기간은 길게 두고 발급하는 것으로 끝내는 건 좋지 않아 보였습니다. access token이 탈취당할 수 있다면 refresh token 또한 탈취 당할 수 있기 때문입니다.
    • 어떻게 해야 refresh token의 존재 의의를 살릴 수 있을 것인지 나름의 방법을 고민한 끝에 아래와 같은 커스텀 인증 로직을 떠올릴 수 있었습니다.
  • 커스텀 Guard

    image

    • 저희는 커스텀 인증 로직을 사용하기 위해 passport를 이용한 손쉬운 인증 방식을 포기하고 직접 커스텀 guard를 구현했습니다.
    • 커스텀 guard의 로직은 다음과 같습니다.
      1. access 토큰 검증
        • access 토큰이 존재하지 않거나 유효하지 않다면 토큰을 모두 삭제하고 block
        • access 토큰이 유효하다면 통과
        • access 토큰이 만료되었다면 2단계로
      2. refresh 토큰 검증
        • refresh 토큰이 존재하지 않거나 유효하지 않거나 만료되었다면 토큰을 모두 삭제하고 block
        • refresh 토큰이 유효하다면 다음의 절차를 따른다
          1. refresh 토큰이 denylist에 존재한다면 재사용된 refresh 토큰임을 의미하므로 유저에게 보안 경고 메일을 보내고 토큰을 모두 삭제한 뒤 block

          2. access 토큰, refresh 토큰 재발급

          3. 사용한 refresh 토큰을 denylist에 등록

          4. 해커가 유저보다 먼저 refresh 토큰을 사용하는 경우를 대비해 유저에게 로그인 알림 메일을 보내고 통과.

            이로서 refresh 토큰이 탈취당하더라도 유저가 이를 인지하고 조치를 취할 수 있다.

📕 메인

👨🏻‍💻 팀 규칙

🛠 프로젝트 명세

👨‍🏫 멘토님 미팅

📝 회의록

1주차 회의록
2주차 회의록
3주차 회의록
4주차 회의록
5주차 회의록
6주차 회의록

📅 스프린트 계획

🔙 회고록

피어세션

2주차 피어세션
3주차 피어세션
4주차 피어세션
5주차 피어세션

💻 기술적 경험

Clone this wiki locally