한국어
  • token
  • oidc
  • refresh token
  • access token
  • ID token

OpenID Connect (OIDC) 프로토콜에서 액세스 토큰, 리프레시 토큰 및 ID 토큰 이해하기

OpenID Connect (OIDC) 프로토콜은 신원 관리를 위한 널리 채택된 표준으로 자리 잡았습니다. 하지만 이 토큰들의 역할과 속성을 정말 이해하고 있나요?

Charles
Charles
Developer

OIDC, OAuth 2.0, 그리고 토큰들

OpenID Connect 프로토콜, 줄여서 OIDC라고도 불리며, 신원 관리를 위한 기본 프레임워크를 제공하는 널리 채택된 표준으로 자리 잡았습니다. 이는 잘 알려진 OAuth 2.0 프로토콜 위에 구축된 인증 계층입니다. OAuth 2.0은 단순히 자원 인증을 위한 것인 반면, OIDC는 새로 도입된 ID 토큰의 도움을 받아 클라이언트 인증을 표준화하고 강화하는 프로토콜입니다.

잠깐만요... OAuth 시대에 액세스 토큰과 리프레시 토큰을 들어본 적이 있을 텐데, 이제 OIDC에서 새로운 개념이 등장한다고요? 이러한 토큰들의 차이를 정말 이해하고 있나요?

OIDC에서 액세스 토큰, 리프레시 토큰 및 ID 토큰이란 무엇인가요?

실용적인 시나리오로 시작해 보죠.

여러분이 전형적인 클라이언트-서버 애플리케이션을 개발하고 있다고 상상해봅시다. 이 애플리케이션은 RESTful API를 통해 서로 통신합니다. 대부분의 API를 비공개로 유지하며, 인증된 클라이언트만 접근을 허용하고자 합니다. 여러분은 클라이언트를 인증하고 서버에 대한 API 요청을 승인할 수 있는 메커니즘이 필요합니다.

이상적으로는, 여러분의 RESTful API는 상태를 저장하지 않아야 합니다. 즉, 서버는 클라이언트 세션 정보를 저장하지 않아야 합니다. 유효한 요청이 들어올 때마다 서버는 요청된 데이터를 응답하면 됩니다. 이때 토큰이 역할을 하게 됩니다. 그러면 이 경우에는 어떤 유형의 토큰을 사용해야 할까요?

액세스 토큰은 여러분의 API를 보호하는 데 사용됩니다

OAuth 2.0 및 OIDC에서는 각 보호된 API가 자원으로 취급됩니다. 액세스 토큰은 클라이언트가 API 자원을 요청할 때 서버로 전달하는 바로 그 토큰으로, 일반적으로 요청 헤더를 통해 그리고 JWT 형식으로 전송됩니다.

서버 측에서는 요청이 들어올 때마다, 서버는 오는 요청이 유효한 액세스 토큰을 가지고 있는지만 검증하면 됩니다. 검증 과정은 일반적으로 JWT 토큰의 디코딩, 서명 및 만료 시간 확인, 그리고 클라이언트가 필요한 권한을 가지고 있는지를 보장하는 범위 주장을 포함합니다.

그러나 여러분은 생각할 수 있습니다: 클라이언트 애플리케이션이 성공적으로 로그인한 후에 유효한 액세스 토큰을 가지고 있고, 이 액세스 토큰을 사용하여 서버 API를 요청하면 충분하지 않은가? 왜 다른 토큰이 필요한가요?

정말 유효한 질문입니다. 단계별로 설명해 보겠습니다.

왜 리프레시 토큰이 필요한가요?

실제로 액세스 토큰은 시스템을 작동시키기에 최소한의 요건을 충족하지만, 보안상의 이유로 액세스 토큰의 유효성은 매우 짧은 기간(일반적으로 한 시간)입니다. 따라서 액세스 토큰만 있다면, 최종 사용자는 액세스 토큰이 만료될 때마다 다시 인증을 해야 합니다. 현대의 단일 페이지 웹 애플리케이션(SPA) 및 특히 모바일 애플리케이션에서는 자주 로그아웃하는 것이 매우 귀찮은 사용자 경험이 될 것입니다. 우리가 그들의 사용자 보안을 보호하려고 하는 것일 뿐이라고 해도 말이죠.

따라서 토큰 보안과 사용자 편의성을 균형 있게 유지해야 합니다. 그래서 리프레시 토큰이 도입되었습니다.

왜 리프레시 토큰은 더 긴 수명을 가질 수 있을까요?

액세스 토큰은 API 자원에 접근하기 위해 사용되므로, 짧은 수명의 특성은 유출되거나 손상될 위험을 줄이는 데 도움이 됩니다. 반면 리프레시 토큰은 새로운 액세스 토큰을 얻기 위해서만 사용되므로, 액세스 토큰만큼 자주 사용되지 않아 노출 위험이 줄어듭니다. 따라서 긴 유효 기간이 안전한 것으로 간주됩니다.

리프레시 토큰 보안 보장

리프레시 토큰은 클라이언트 측에 저장되므로, 공개 클라이언트(예: 단일 페이지 웹 애플리케이션(SPA) 및 모바일 앱)에서 비공개로 유지하는 것이 어렵습니다.

Logto에서는 리프레시 토큰에 대해 자동 회전 메커니즘이 기본적으로 활성화되어 있습니다. 이는 인증 서버가 조건을 충족하면 새로운 리프레시 토큰을 발급함을 의미합니다:

  • 단일 페이지 애플리케이션: 전송자 제약을 받지 않는 클라이언트로 인식되어 이 앱은 리프레시 토큰 회전을 요구합니다. 리프레시 토큰의 TTL은 명시될 수 없습니다.
  • 네이티브 앱과 전통적 웹 앱: 리프레시 토큰 회전이 본래부터 활성화되어 있으며, TTL의 70%에 도달하면 자동으로 갱신됩니다. Logto에서 리프레시 토큰 회전에 대해 더 알아보기

관리자 콘솔의 애플리케이션 세부 페이지에서 리프레시 토큰 회전을 비활성화할 수 있는 옵션이 있지만, 이 보호조치를 유지하는 것이 강력히 권장됩니다.

ID 토큰이란 무엇이며 왜 중요한가요?

ID 토큰은 인증된 사용자에 대한 신원 정보를 제공하는 OIDC의 고유한 기능입니다.

액세스 토큰은 보호된 자원에 접근하는 데 사용되며, 리프레시 토큰은 새로운 액세스 토큰을 얻는 데 사용되지만, ID 토큰은 보통 클라이언트 측에서 사용자 정보를 캐시하여, 인증 서버에 대한 추가 요청을 줄입니다. 대부분의 경우, ID 토큰을 갖는 것은 사용자가 인증되었다고 말할 수 있을 정도로 안전합니다.

토큰 처리에 대한 모범 사례

  • HTTPS 사용: 항상 클라이언트와 인증 서버 간의 통신을 보호하기 위해 HTTPS를 사용하세요. 이를 통해 무단자가 토큰을 가로채거나 훔치는 것을 방지할 수 있습니다.
  • 적절한 토큰 만료 시간 설정: 액세스 토큰은 노출 위험을 최소화하기 위해 짧은 수명을 가져야 합니다. 리프레시 토큰은 더 긴 유효 기간을 가질 수 있습니다.
  • 리프레시 토큰 회전 활성화: 리프레시 토큰 누출의 위험을 줄이기 위해 리프레시 토큰 회전을 구현하세요.
  • 정밀한 접근 제어 사용: 액세스 토큰의 권한을 제한하기 위해 정밀한 범위를 사용하세요. 클라이언트 애플리케이션에 필요한 권한만 요청하세요. 절대 필요한 경우를 제외하고 "all"이나 "admin" 범위를 사용하여 대부분의 권한 검사를 우회하지 않도록 하세요.

OIDC에서 액세스 토큰, 리프레시 토큰, ID 토큰의 주요 차이점 요약

OIDC 프로토콜에서 리프레시 토큰, 액세스 토큰, ID 토큰은 안전하고 원활한 사용자 인증을 제공합니다.

  • 액세스 토큰은 보호된 자원에 대한 권한을 부여합니다.
  • 리프레시 토큰은 새로운 액세스 토큰에 대한 사용자 개입을 제거합니다.
  • ID 토큰은 클라이언트에서 사용자 정보를 캐시하여 성능을 향상시킵니다.

이러한 토큰의 역할과 중요성을 이해하는 것은 애플리케이션에 OIDC 인증을 구현하는 개발자에게 매우 중요합니다.