🤖 안드로이드에서 Access Token 만료 처리하기 (Feat. dataStore)

들어가기

드디어 안드로이드에서 Access Token이 만료되었을 때와 Refresh Token 만료되었을 때 처리하는 방법에 대해 소개할 차례다!!
Access Token과 Refresh Token이 어떤 프로세스로 동작하는지 잘 모르시는 분들은 🧐 Access Token과 Refresh Token이란 무엇이고 왜 필요할까? ← 이 글을 먼저 보고 오는 게 좋을 것 같습니다!

생각보다 글이 길어져서 Access Token 만료 처리와 Refresh Token 만료 처리 글을 나눠서 작성했다.

오늘은 Access Token 만료 처리 과정 & 코드를 다루도록 하겠다.

참고로 아래 코드는 전부 코틀린으로 구현되어있습니다!🙂

목표

Access Token이 만료되었을 때

1️⃣ Refresh Token으로 대체하여 API 재요청하기
2️⃣ 새 Access Token 로컬(dataStore)에 저장하기

Overview

위의 목표를 달성하기 위해 사용할 기술과 구현할 작업은 다음과 같다.

• AuthInterceptor : OkHttp3의 Interceptor 상속
  • request 헤더에 JWT 토큰 추가해주는 작업
  • response 헤더에 Authorization 키 값 존재하면 Access Token 업데이트 해주는 작업
• AuthAuthenticator : OkHttp3의 Authenticator 상속
  • 401 http error code를 받았을 때 호출되는 클래스
  • Access Token 만료 시 Access Token ➡ Refresh Token으로 교체 후 API 재요청하는 작업
• TokenManager : Token DataStore < Preferences>
  • Access Token을 로컬에 저장해두는 곳
  • 토큰 CRUD 작업 동기 or 비동기로 선택해서 작업 가능

OkHttp3

먼저 OkHttp에 대한 소개가 필요할 것 같다. OkHttp는 앱에서 네트워크 통신(요청 및 응답)을 할 때 사용되는 라이브러리다. HTTP를 효율적으로 수행하면서 로드를 빠르게 하고 대역폭을 절약하는 특징을 가지고 있다.

기본적으로 OkHttp3는 HTTP/2를 지원하고 있다. HTTP/2는 HTTP/1.1과 유사한 기능을 하지만 더 효율적으로 만든 프로토콜이다.

HTTP/2의 특징

• 여러 Request 파일을 병렬적으로 전송한다
  • HTTP/1.1까지는 request에 대한 response가 오고 다음 request를 보낼 수 있었다. 여기서 병목현상이라는 문제 상황이 발생했고 이를 HOL(Head of line blocking)이라고 한다.
  • 이를 해결하기 위해 HTTP/2에서는 병렬 전송을 지원하게 되었다.
• 중복 헤더의 제거
  • 같은 내용의 헤더를 보낼 경우 생략 처리하여 속도를 높인다
• 헤더 압축
  • HTTP/1.1에서는 헤더를 평문으로 보냈지만, HTTP/2에서는 헤더를 압축해서 보내 용량 대비 처리 효율성을 높였다.
• 우선순위
  • request에 우선순위를 두어 더 빨리 로딩되어야하는 파일을 구분할 수 있다.

Frame

HTTP로 서버-클라이언트 통신을 할 때 Frame을 가지고 한다. Frame은 Header와 Data로 구성되어있다. Header와 Data의 구조는 아래 사진과 같다.

우리가 관심을 가져야하는 구조는 Header다. 앞선 블로그에서 이야기한 것처럼 JWT 토큰 인증 방식은 Header에 있는 JWT 토큰으로 인가(Authorization)을 확인해주는 작업이기 때문이다.

이제 다시 돌아가서 OkHttp3가 지원해주는 헤더와 관련된 클래스를 공부해보자.

Interceptor

Interceptor는 HTTP 통신을 모니터링할 수 있게 해주고, API 재요청 등을 가능하게 해주는 클래스이다. Interceptor에는 Application Interceptor와 Network Interceptor 2가지가 있다.

📌 Application Interceptor

• 주로 어플리케이션의 비즈니스 로직과 관련된 작업을 처리할 때 사용
• 네트워크 호출 이전에 실행 됨
• 사용 예) 사용자 인증 토큰 추가, 캐시 구현

📌 Network Interceptor

• 실제 네트워크 요청 및 응답과 관련된 작업을 수행하는데 사용

• 사용 예) 네트워크 요청 및 응답 로그

  

  우리는 Authorization을 처리할 것이므로 Application Interceptor를 사용하면 된다.

🔥 Access Token 만료 구현하기

Build

먼저 build.gradle(Module :app) 파일에 아래 라이브러리들을 추가해줘야 한다. (만료 작업을 구현하는 사람이라면 이미 DataStore를 제외하고는 이미 라이브러리를 추가했을 거라 믿는다!)

dependencies {
			// OkHttp
            implementation(platform("com.squareup.okhttp3:okhttp-bom:4.10.0"))
      		implementation("com.squareup.okhttp3:okhttp")
      		implementation("com.squareup.okhttp3:logging-interceptor")

			// DataStore
			implementation "androidx.datastore:datastore-preferences:1.0.0"

			//Retrofit
			def retrofit_version = "2.9.0"
			implementation "com.squareup.retrofit2:retrofit:$retrofit_version"
			implementation "com.squareup.retrofit2:converter-gson:$retrofit_version"

			//Hilt
			def hilt_version = "2.44"
			implementation "com.google.dagger:hilt-android:$hilt_version"
			kapt "com.google.dagger:hilt-compiler:$hilt_version"
}

인터넷 통신하기 전에 Internet 권한도 AndroidManifest.xml에서 추가해줘야하는 것도 잊지 말자.

<uses-permission android:name="android.permission.INTERNET" />

Token DataStore

JWT 토큰을 로컬에 저장해주기 위해 DataStore Preference를 사용한다. 사용자가 로그인하여 인증(Authentication)하면 서버로부터 Refresh Token과 Access Token을 받게 된다. 이때 TokenManager 에 정의한 save_token()함수를 사용해서 각 Token을 저장하면 된다.

class TokenManager @Inject constructor(
    private val dataStore: DataStore<Preferences>
) {
    companion object {
        private val ACCESS_TOKEN_KEY = stringPreferencesKey("access_token")
    }

    fun getAccessToken(): Flow<String?> {
        return dataStore.data.map { prefs ->
            prefs[ACCESS_TOKEN_KEY]
        }
    }

    suspend fun saveAccessToken(token: String){
        dataStore.edit { prefs ->
            prefs[ACCESS_TOKEN_KEY] = token
        }
    }

    suspend fun deleteAccessToken(){
        dataStore.edit { prefs ->
            prefs.remove(ACCESS_TOKEN_KEY)
        }
    }
}

AuthInterceptor

OkHttp3의 Interceptor는 request header의 내용 추가와 교체 기능를 제공한다. 우리는 JWT 토큰을 헤더에 넣어줘야하므로 Interceptor를 상속받은 AuthInterceptor 클래스를 만들면 된다. Interceptor를 상속 받으면 interceptor() 함수를 오버라이딩 하라고 뜬다.

기본 코드는 다음과 같다. (아래에서 추가될 예정)

class AuthInterceptor @Inject constructor(
    private val tokenManager: TokenManager
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val token: String = runBlocking {
            tokenManager.getAccessToken().first()
        } ?: return errorResponse(chain.request())

        val request = chain.request().newBuilder().header(AUTHORIZATION, "Bearer $token").build()

        return chain.proceed(request)
    }

    private fun errorResponse(request: Request): Response = Response.Builder()
        .request(request)
        .protocol(Protocol.HTTP_2)
        .code(NETWORK_ERROR)
        .message("")
        .body(ResponseBody.create(null, ""))
        .build()
}

1. tokenManager 에서 Access Token을 받아 온다.

   1-1. Access Token이 null일 경우 errorResponse를 return 해준다.

   1-2. Access Token에 JWT 토큰이 들어있다면 2번으로 이동한다.

2. Interceptor가 가져온 chain에서 request에 Builder를 만들어준다.

3. 헤더의 Authorization key에 Bearer를 붙여 Access Token 값을 넣어준다.

4. chain.proceed(requset)를 통해 HTTP 요청에 대한 응답을 만들고 return 한다.

Access Token을 넣어 보냈던 request의 Access Token이 만료되었다면 401(Unauthorized) http 상태 코드를 받게 된다. 앞서 말했듯 이를 처리해주는 클래스가 Authenticator이다. Authenticator는 401을 받았을 때만 호출되기 때문이다.

AuthAuthenticator

이제 AuthAuthenticator를 구현하자. Authenticator를 상속받아 클래스를 만들면 authenticate() 함수를 오버라이딩하라고 뜬다. authenticate() 함수를 채워보자.

구현할 내용은 Access Token을 Refresh Token으로 교체하여 API 재요청하는 부분이다.

class AuthAuthenticator @Inject constructor(
    private val tokenManager: TokenManager
) : Authenticator {
    override fun authenticate(route: Route?, response: Response): Request? {
        val refreshToken = runBlocking {
            tokenManager.getRefreshToken().first()
        }
 
        if (refreshToken == null || refreshToken == "LOGIN") {
            response.close()
            return null
        }

        return newRequestWithToken(refreshToken, response.request)
    }

    private fun newRequestWithToken(token: String, request: Request): Request =
        request.newBuilder()
            .header(AUTHORIZATION, token)
            .build()
}

1. Refresh Token을 tokenManager에서 가져오기

   1-1. refreshToken이 null이거나 “LOGIN”(로그인 전)이라면 API 재요청 request를 만들지 않고 닫아버린다.

   1-2. refreshToken에 JWT 토큰 값이 들어있으면 2번으로 이동한다.

2. request 헤더의 Authorization 값을 Refresh Token으로 교체하기

3. API 재요청

위 코드에서 주목할 부분은 runBlocking이다. refreshToken을 가져올 때 runBlocking을 사용하는데, 그 이유는 동기적인 순차 흐름을 만들기 위해서다. Refresh Token을 가져온 다음에 request API를 보낼 수 있기 때문이다.

참고로 .first()를 한 이유는 dataStore에 저장된 토큰이 flow로 전달되기 때문이다. 토큰은 하나밖에 없으므로 stream에서 첫번째로 들어온 값이 토큰이 된다.

AuthInterceptor

이제 다시 Interceptor에서 새로운 response를 받을 차례다. 내가 가진 Refresh Token이 유효한 토큰이라면 서버는 나에게 새로운 Access Token을 전달해줄 것이기 때문이다.

class AuthInterceptor @Inject constructor(
    private val tokenManager: TokenManager
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val token: String = runBlocking {
            tokenManager.getAccessToken().first()
        } ?: return errorResponse(chain.request())

        val request = chain.request().newBuilder().header(AUTHORIZATION, "Bearer $token").build()
        
				////////////////////////////////// 여기부터 추가된 코드 /////////////////////////////////////
		val response = chain.proceed(request)
		if (response.code == HTTP_OK) {
        	val newAccessToken: String = response.header(AUTHORIZATION, null) ?: return response
        	Timber.d("new Access Token = ${newAccessToken}")

        	CoroutineScope(Dispatchers.IO).launch {
            	val existedAccessToken = tokenManager.getAccessToken().first()
            	if (existedAccessToken != newAccessToken) {
                	tokenManager.saveAccessToken(newAccessToken)
                	Timber.d("newAccessToken = ${newAccessToken}\nExistedAccessToken = ${existedAccessToken}")
            	}
        	}
        } else {
            Timber.e("${response.code} : ${response.request} \n ${response.message}")
        }
	
        return response
    }

    ...
}

1. response code가 HTTP_OK(200)인지 확인한다

2. response 헤더에 Authorization 키 값이 존재하는 지 확인

   2-1. 존재하지 않으면 Refresh Token으로 request를 보낸 게 아니므로 토큰 업데이트가 필요없으니 return response를 하고 함수를 종료한다

   2-2. 존재한다면 3번으로 이동한다.

3. Authorization에 들어있는 새로운 Access Token과 tokenManager에 들어있는 Access Token을 비교해준다.

   3-1. 동일하다면 앞선 response에서 이미 업데이트해준 것이므로 따로 처리해줄 필요 없다.

   3-2. 동일하지 않다면 새로운 Access Token이므로 저장 작업을 수행한다.

👀 여기서 질문!

Q. 새로운 Access Token을 저장할 때 비동기(CoroutineScope(Dispatchers.IO))에서 작업한 이유는?

A. UI를 blocking하는 것보다는 백그라운드에서 2~3번 처리하는 게 더 낫기 때문이다.

물론 비동기로 처리하면 병렬적으로 response가 오므로 (HTTP/2의 특성) 해당 작업이 1번 이상 수행될 수도 있다. 그러나 이미 받은 response이므로 비동기로 작업한다고 해서 네트워크에 혼선이나 부하를 주지 않는다. 따라서 runBlocking을 사용하여 UI를 blocking하면서까지 동기적으로 작업할 필요가 없다고 느꼈고 백그라운드에서 처리하도록 구현했다.

결론

• Access Token의 흐름
  1. AccessToken을 DataStore에서 가져와 헤더에 넣어주기
  2. 만료되어 401 받으면 Authenticator에서 Access Token → Refresh Token으로 대체하여 API request 재요청
  3. response 헤더의 Authorization에 Access Token 들어있으면 DataStore의 Access Token 업데이트
• Access Token 만료 처리를 위해 구현한 클래스와 목적
  - AuthInterceptor : request 헤더에 Access Token 추가해주고, 새 Access Token 업데이트 해주기 위해
  - AuthAuthenticator : 401(Unauthorized) 상태코드 받았을 때 Access Token → Refresh Token으로 바꿔주는 작업 해주기 위해
  - TokenManager : Access Token CRUD 작업 비동기 & 동기적으로 처리 가능하게 하기 위해
  
  

---

고민 기록 1️⃣ : DataStore를 사용한 이유

기존에는 사실 DataStore 대신에 SharedPreference를 사용했었다. 그러나 다음과 같은 이유로 DataStore를 사용해 JWT 토큰을 저장하기로 했다.

1. 비동기 처리
SharedPreference와 달리 DataStore는 Flow로 데이터를 stream에 저장한다. 따라서 CoroutineScope 내에서 비동기로 백그라운드 처리가 가능했다. UI를 막지 않는다는 점이 가장 마음에 들었다.

2. 안전하고 효율적이다.
아직 위의 코드에서 나오지는 않았지만 로그아웃 기능을 수행할 때 로컬에 저장된 JWT 토큰을 다 지워주어야했다. 그런데 SharedPreference를 사용하면 UI를 막거나 (로그인 이동 화면 이동 작업 전에 이루어져야하므로) 제대로 안지워지는 경우가 생겼다. 비동기 처리 덕분에 안전하고 효율적이게 데이터 처리가 가능해진 것이다!

고민 기록 2️⃣ : Interceptor와 Authenticator 2개를 사용한 이유

사실 Interceptor만 사용해서도 Access Token 만료를 처리할 수 있다. 위에서 HTTP_OK를 확인한 것처럼 에러 코드가 UNAUTHORIZED인지 확인하면 되기 때문이다. 그런데 Refresh Token 만료를 처리할 때 어려움을 겪었고 2개를 사용하기로 한 것이다.

이 부분은 다음 챕터에서 자세히 다루도록 하겠다.

그럼 안녕히!!!👋