Ktor Client의 인증 및 인가
필수 의존성: io.ktor:ktor-client-auth
Ktor는 클라이언트 애플리케이션에서 인증(authentication) 및 인가(authorization)를 처리하기 위해 Auth 플러그인을 제공합니다. 전형적인 사용 시나리오에는 사용자 로그인 및 특정 리소스에 대한 접근 권한 획득 등이 포함됩니다.
서버 측에서 Ktor는 인증 및 인가 처리를 위해
Authentication플러그인을 제공합니다.
지원되는 인증 유형
HTTP는 접근 제어 및 인증을 위한 일반적인 프레임워크를 제공합니다. Ktor 클라이언트를 사용하면 다음과 같은 HTTP 인증 스킴을 사용할 수 있습니다:
- Basic -
Base64인코딩을 사용하여 사용자 이름과 비밀번호를 제공합니다. HTTPS와 함께 사용하지 않는 한 일반적으로 권장되지 않습니다. - Digest - 사용자 자격 증명(credentials)에 해시 함수를 적용하여 암호화된 형태로 통신하는 인증 방식입니다.
- Bearer - 베어러 토큰(bearer tokens)이라고 불리는 보안 토큰을 사용하는 인증 스킴입니다. 예를 들어, Google, Facebook, X(구 Twitter) 등과 같은 외부 제공업체를 사용하여 애플리케이션 사용자를 인증하는 OAuth 흐름의 일부로 이 스킴을 사용할 수 있습니다.
의존성 추가
인증 기능을 활성화하려면 빌드 스크립트에 ktor-client-auth 아티팩트를 포함해야 합니다:
TIP
Ktor 클라이언트에 필요한 아티팩트에 대한 자세한 내용은Auth 설치
Auth 플러그인을 설치하려면, 클라이언트 설정 블록 내부의 install() 함수에 전달합니다:
import io.ktor.client.*
import io.ktor.client.engine.cio.*
import io.ktor.client.plugins.auth.*
//...
val client = HttpClient(CIO) {
install(Auth) {
// 인증 설정
}
}인증 설정
인증 제공자 선택
특정 인증 제공자(basic, digest, 또는 bearer)를 사용하려면 install {} 블록 내부에서 해당 함수를 호출해야 합니다.
예를 들어, basic 인증을 설정하려면 basic {} 함수를 사용합니다:
install(Auth) {
basic {
// basic 인증 설정
}
}블록 내부에서 해당 제공자에 특화된 설정을 구성할 수 있습니다.
제공자별 상세 설정은 해당 주제를 참조하세요:
영역(realm) 설정
선택 사항으로, realm 속성을 사용하여 영역을 설정할 수 있습니다:
install(Auth) {
basic {
realm = "Access to the '/' path"
// ...
}
}서로 다른 리소스에 접근하기 위해 다른 영역을 가진 여러 제공자를 생성할 수 있습니다:
install(Auth) {
basic {
realm = "Access to the '/' path"
// ...
}
basic {
realm = "Access to the '/admin' path"
// ...
}
}이 경우, 클라이언트는 영역 정보가 포함된 WWW-Authenticate 응답 헤더를 기반으로 필요한 제공자를 선택합니다.
제공자 선택
서버가 401 Unauthorized를 반환하면, 클라이언트는 WWW-Authenticate 응답 헤더를 기반으로 인증 제공자를 선택합니다. 이 헤더는 서버가 수용하는 인증 스킴을 명시합니다.
클라이언트에 인증 제공자가 하나만 설치된 경우, WWW-Authenticate 헤더가 없거나 다른 스킴을 명시하더라도 Auth 플러그인은 서버가 401 Unauthorized를 반환할 때 항상 해당 제공자를 시도합니다.
클라이언트에 여러 인증 제공자가 설치된 경우, 클라이언트는 WWW-Authenticate 헤더를 기반으로 제공자를 선택합니다.
토큰 캐싱 및 캐시 제어
Basic 및 Bearer 인증 제공자는 내부적인 자격 증명(credential) 또는 토큰 캐시를 유지합니다. 이 캐시를 통해 클라이언트는 매 요청마다 인증 데이터를 다시 로드하는 대신 이전에 로드된 데이터를 재사용할 수 있어, 자격 증명이 변경될 때의 제어권을 유지하면서도 성능을 향상시킬 수 있습니다.
인증 제공자 접근하기
클라이언트 세션 중에 인증 상태를 동적으로 업데이트해야 하는 경우, authProvider 확장 함수를 사용하여 특정 제공자에 접근할 수 있습니다:
val provider = client.authProvider<BearerAuthProvider>()설치된 모든 제공자를 가져오려면 authProviders 속성을 사용합니다:
val providers = client.authProviders이러한 유틸리티를 사용하면 프로그래밍 방식으로 제공자를 검사하거나 캐시된 토큰을 삭제할 수 있습니다.
캐시된 토큰 삭제하기
단일 제공자에 대해 캐시된 자격 증명을 삭제하려면 .clearToken() 함수를 사용합니다:
val provider = client.authProvider<BasicAuthProvider>()
provider?.clearToken()캐시 삭제를 지원하는 모든 인증 제공자 전체에서 캐시된 토큰을 삭제하려면 .clearAuthTokens() 함수를 사용합니다:
client.clearAuthTokens()캐시된 토큰 삭제는 일반적으로 다음과 같은 시나리오에서 사용됩니다:
- 사용자가 로그아웃할 때.
- 애플리케이션에 저장된 자격 증명이나 토큰이 변경될 때.
- 다음 요청 시 제공자가 인증 상태를 강제로 다시 로드하도록 해야 할 때.
다음은 사용자가 로그아웃할 때 캐시된 토큰을 삭제하는 예시입니다:
fun logout() {
client.clearAuthTokens()
storage.deleteCredentials()
}캐싱 동작 제어하기
Basic 및 Bearer 인증 제공자 모두 cacheTokens 옵션을 사용하여 요청 간에 토큰이나 자격 증명을 캐시할지 여부를 제어할 수 있습니다.
예를 들어, 자격 증명이 동적으로 제공되는 경우 캐싱을 비활성화할 수 있습니다:
basic {
cacheTokens = false // 매 요청마다 자격 증명을 다시 로드함
credentials {
loadCurrentCredentials()
}
}토큰 캐싱 비활성화는 인증 데이터가 자주 변경되거나 가장 최신 상태를 반영해야 하는 경우에 특히 유용합니다.
