feature: 로그아웃 api

[TaeyeonRoyce]

📌 관련 이슈

• closed feature: 로그아웃 API #118

📁 작업 설명

• 로그아웃 API 구현
  로그아웃 시, 회원의 oauth 토큰 정보와 리프레시 토큰을 초기화 하였습니다.
  추가로 사용중이던 인증정보에 대해 사용할 수 없는(블랙리스트) 인증 정보로 관리 되도록 구성하였습니다.

기타

블랙리스트 토큰 관리를 위해 Redis에 인증 정보들을 저장하였습니다.
저장 형식은 아래와 같습니다.

key - value
"member:${id}:accessToken" - "emj123mmnad0Bsd1.anboauhoEm1SVas.abahhjiaknl"

만료 시간은 accessToken의 만료시간과 동일하게 구성하였습니다!

[hgo641]

깔끔 코드 맛집👍

[github-actions]

Test Results

 42 files  +1   42 suites  +1   18s ⏱️ -1s
212 tests +6  212 ✅ +6  0 💤 ±0  0 ❌ ±0 
296 runs  +7  296 ✅ +7  0 💤 ±0  0 ❌ ±0 

Results for commit eea6e24. ± Comparison against base commit ad5b8fc.

This pull request removes 5 and adds 11 tests. Note that renamed tests count towards both.

com.petqua.application.auth.AuthServiceTest ‑ Then: 멤버의 인증 토큰을 발급한다
com.petqua.application.auth.AuthServiceTest ‑ Then: 발급한 refreshToken을 저장한다
com.petqua.application.auth.AuthServiceTest ‑ Then: 예외가 발생한다
com.petqua.application.auth.AuthServiceTest ‑ Then: 입력한 회원의 정보를 삭제한다
com.petqua.application.auth.AuthServiceTest ‑ Then: 토큰 정보를 갱신한다

com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 로그아웃한 회원의 토큰 정보를 블랙리스트에 추가한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 멤버의 인증 토큰을 발급한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 멤버의 토큰 정보와 RefreshToken이 초기화 된다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 발급한 refreshToken을 저장한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 예외가 발생한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 입력한 회원의 정보를 삭제한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 토큰 정보를 갱신한다
com.petqua.domain.auth.token.BlackListTokenCacheStorageTest ‑ 블랙리스트 추가 테스트
com.petqua.domain.member.MemberTest ‑ 로그아웃 처리를 한다
com.petqua.presentation.auth.AuthControllerTest ‑ Then: 멤버의 토큰 정보와 RefreshToken이 초기화 된다
…

♻️ This comment has been updated with latest results.

[Combi153]

redis 를 잘 쓰시는 게 너무 멋져요!
저도 열심히 공부하겠습니다 😃
고생하셨어요!

[Combi153]

BlackList 신기하네요~ 👍
만약 redis 가 없다면 이런 기능은 DB에 따로 저장해서 구현하려나요?

[TaeyeonRoyce]

이 부분에 대해서 조금 고민이 들더라고요.
말씀대로 redis는 캐시의 구현체로서 의미가 있어서 만약 redis가 없다면 DB에 따로 저장해야 할 것 같아요.

현재는 추상화 없이 세부 구현체로 직접 구현 되어 있습니다.
@Cachable을 사용하려 했는데 ttl 설정이 어려워서 redisTemplate으로 구현했어요.
좀 더 분석해보고 ttl을 지정하면서 @cachable 처럼 추상화 된 캐시스토리지도 만들어 보겠습니다!

[Combi153]

로그인 연장 시에는 로그아웃한 accessToken 이 사용될 수 있는 것처럼 보여요!

[TaeyeonRoyce]

버그 발견! 감사합니다👍

[Combi153]

깔끔합니다 👍

[TaeyeonRoyce]

@Combi153 @hgo641
찬민님의 리뷰를 받고 blackList 관리에 대해 고민이 생겼는데 의견을 구해보고자 합니다!

문제 상황

현재 구현되어 있는 상태는 로그아웃 요청 시 redis에 해당 로그아웃 요청에 사용된 토큰을 추가하는데요.

"member:${id}:accessToken" - "emj123mmnad0Bsd1.anboauhoEm1SVas.abahhjiaknl"

이런 형태로 저장합니다.

유효한 accessToken에 대해서, payload를 얻은 뒤 포함되어 있는 memberId의 값을 활용해서 토큰의 사용가능 여부를 확인하는데요. (key에 member:${id} 가 있어서)
회원별 로그아웃 이력도 남고, 조회할 때 유리해서 선택한 방식이었습니다!

그런데, extendLogin 처럼 accessToken 값 자체만 사용하는 경우에는 문제가 있더라고요.
만료된 accessToken이 정상적인 요청이라 payload를 확인 할 수 없습니다.(expired token)
그래서 redis에서 key로 조회가 불가하고, value로 찾아야 하는 상황이 발생하게 되는데요.

고민

두 가지 방법이 있습니다.

1. value로 찾기
   redis의 scan을 통해 value들을 조회 하고, 존재하는지 확인합니다.

SCAN 0 MATCH member:*:accessToken COUNT 100

이런식으로 value를 모두 가져온 후, 해당 token이 블랙리스트인지 확인합니다.

고려되는 문제점은 scan에 대한 복잡도와 $O(n)$의 시간 복잡도 입니다.

KEYS 명령어와 달리 SCAN은 커서기반으로 조회를 하게 되는데요.
그에 따라 cursor를 반복적으로 지정하고 0이 될 때 까지 조회하는 로직이 필요합니다.
cursor 관련 구현 참고

추가적으로, 크게 고려할 사항은 아니지만 scan의 경우 조회 일관성을 보장하지 않을 수도 있습니다.
ex) scan으로 여러번 조회하는 중에 데이터가 변경된 경우

2. redis key-value 형태 변경
   단순히 token만 저장하는 형태로만 저장하는 방법입니다.

AS-IS
"member:${id}:accessToken" - "emj123mmnad0Bsd1.anboauhoEm1SVas.abahhjiaknl"

TO-BE
"emj123mmnad0Bsd1.anboauhoEm1SVas.abahhjiaknl" - ""

로그아웃된 토큰만 저장하는 방식이에요!
매우 간단하지만 토큰 관점으로만 봐서 더 괜찮은 것 같긴 합니다.
key-value의 DB를 그냥 값으로만 사용하는게 조금 어색하긴 하지만 좋은 방법인 것 같긴 합니다.

단점(?)은 회원 이력을 남기지 못한다는 것과 설계 변경으로 인해 PR내 로직을 다수 수정해야합니다..!

---

의견 주시면 감사하겠습니다!

[Combi153]

@TaeyeonRoyce
ExpiredToken 의 payload 를 추출한다면 지금 구조를 그대로 이어가도 괜찮을 것 같아요!

    fun getExpiredTokenPayload(token: String): Map<String, String> {
        return try {
            getPayload(token)
        } catch (e: ExpiredJwtException) {
            val payload = mutableMapOf<String, String>()
            e.claims.forEach { payload[it.key] = it.value.toString() }
            payload
        } catch (e: Exception) {
            throw IllegalArgumentException()
        }
    }

만료된 토큰에 대해서 payload 를 접근하는 방법이 아예 없는 건 아니더라구요! 위 코드처럼 ExpiredJwtException 을 Catch 한 블럭에서 e.claims 로 claim 에 접근할 수 있습니다. 이 정보로 payload를 구성할 수 있어요!

@SpringBootTest(webEnvironment = NONE)
class JwtProviderTest(
    private val jwtProvider: JwtProvider,
) : StringSpec({

    "만료 토큰 생성" {
        val token = jwtProvider.createToken(
            claims = mapOf(
                "memberId" to "1",
                "authority" to "GUEST"
            ),
            tokenLiveTime = 0,
            issuedDate = Date()
        )

        jwtProvider.isExpiredToken(token) shouldBe true
    }

    "만료 토큰 payload 얻기" {
        val token = jwtProvider.createToken(
            claims = mapOf(
                "memberId" to "1",
                "authority" to "GUEST"
            ),
            tokenLiveTime = 0,
            issuedDate = Date()
        )

        val payload = jwtProvider.getExpiredTokenPayload(token)

        payload["memberId"] shouldBe "1"
        payload["authority"] shouldBe "GUEST"
    }

    "만료 토큰과 정상 토큰의 차이" {
        val expiredToken = jwtProvider.createToken(
            claims = mapOf(
                "memberId" to "1",
                "authority" to "GUEST"
            ),
            tokenLiveTime = 0,
            issuedDate = Date()
        )
        val token = jwtProvider.createToken(
            claims = mapOf(
                "memberId" to "1",
                "authority" to "GUEST"
            ),
            tokenLiveTime = 100000000000,
            issuedDate = Date()
        )

        val expiredTokenPayload = jwtProvider.getExpiredTokenPayload(expiredToken)
        val payload = jwtProvider.getPayload(token)

        println("만료 토큰 payload")
        println(expiredTokenPayload)

        println("토큰 payload")
        println(payload)
    }
})

위 테스트로 만료된 토큰의 payload 를 받아오는 것이 충분히 가능하다는 것을 확인했습니다. 출력 결과만 보아도 차이가 없어 보이네요!

redis 는 기존과 같이 key-value 구조를 이어가면서 extendLogin 에서는 만료된 토큰 payload 를 추출해서 key로 value 를 조회하는 건 어떠신가요? value로 찾거나, value 만 저장하는 방식보다 데이터를 효율적으로 사용할 수 있을 것 같아요.

[TaeyeonRoyce]

@Combi153
오...! 이 방법은 생각해보지 못했어요! 감사합니다.
제안 주신 방법으로 구현해서 다시 리뷰요청 드릴게요!!
👍👍👍👍👍👍

[Combi153]

로그아웃 고생하셨습니다!
blacklist 관리까지 추가해주셔서 더 신뢰도 높은 애플리케이션이 되었네요
감사합니다~~ 😀

[Combi153]

좋아요!!!👍 👍