-
Notifications
You must be signed in to change notification settings - Fork 1
커스텀 인증 로직
tnghd5761 edited this page Dec 22, 2022
·
1 revision
-
기존 방식
- 처음에는 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
- 저희는 커스텀 인증 로직을 사용하기 위해 passport를 이용한 손쉬운 인증 방식을 포기하고 직접 커스텀 guard를 구현했습니다.
- 커스텀 guard의 로직은 다음과 같습니다.
- access 토큰 검증
- access 토큰이 존재하지 않거나 유효하지 않다면 토큰을 모두 삭제하고 block
- access 토큰이 유효하다면 통과
- access 토큰이 만료되었다면 2단계로
- refresh 토큰 검증
- refresh 토큰이 존재하지 않거나 유효하지 않거나 만료되었다면 토큰을 모두 삭제하고 block
-
refresh 토큰이 유효하다면 다음의 절차를 따른다
-
refresh 토큰이 denylist에 존재한다면 재사용된 refresh 토큰임을 의미하므로 유저에게 보안 경고 메일을 보내고 토큰을 모두 삭제한 뒤 block
-
access 토큰, refresh 토큰 재발급
-
사용한 refresh 토큰을 denylist에 등록
-
해커가 유저보다 먼저 refresh 토큰을 사용하는 경우를 대비해 유저에게 로그인 알림 메일을 보내고 통과.
이로서 refresh 토큰이 탈취당하더라도 유저가 이를 인지하고 조치를 취할 수 있다.
-
- access 토큰 검증
- 22.11.01 멘토님 미팅
- 22.11.09 멘토님 미팅
- 22.11.17 멘토님 미팅
- 22.11.23 멘토님 미팅
- 22.12.01 멘토님 미팅
- 22.12.08 멘토님 미팅
- 22.12.15 멘토님 미팅