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

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

OpenID Connect (OIDC) 프로토콜은 ID 관리에 널리 채택된 표준으로 부상했습니다. 그러나 정말로 이러한 토큰의 역할과 속성을 이해하고 있습니까?

Charles
Charles
Developer

OIDC, OAuth 2.0, 및 토큰

OpenID Connect Protocol(OIDC)은 ID 관리를 위한 기본 프레임워크를 제공하는 널리 채택된 표준으로 부상했습니다. 이는 잘 알려진 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%에 도달하면 자동으로 갱신됩니다. 자세히 알아보기

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

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

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

액세스 토큰이 보호된 리소스에 접근하는 데 사용되고 리프레시 토큰이 새 액세스 토큰을 얻는 데 사용되는 반면, ID 토큰은 일반적으로 클라이언트 측에서 사용자 정보를 캐시하는 데 사용되어 사용자 데이터에 대한 추가 요청을 인증 서버로 보낼 필요를 줄입니다. 대부분의 경우, ID 토큰을 소유하는 것이 사용자가 인증된 것과 동일하다고 안전하게 말할 수 있습니다.

토큰 처리의 모범 사례

  • HTTPS 사용: 항상 클라이언트와 인증 서버 간의 통신을 보호하기 위해 HTTPS를 사용하십시오. 이렇게 하면 승인되지 않은 당사자가 토큰을 가로채서 훔치는 것을 방지할 수 있습니다.
  • 적절한 토큰 만료 시간 설정: 노출 위험을 최소화하기 위해 액세스 토큰의 수명을 짧게 설정하십시오. 리프레시 토큰은 더 긴 유효성 기간을 가질 수 있습니다.
  • 리프레시 토큰 회전 활성화: 리프레시 토큰 누출 위험을 완화하기 위해 리프레시 토큰 회전을 구현하십시오.
  • 세밀한 액세스 제어 사용: 액세스 토큰의 권한을 제한하기 위해 세밀한 범위를 사용하십시오. 클라이언트 애플리케이션에 필요한 권한만 요청하십시오. "all" 또는 "admin" 범위를 사용하여 대부분의 권한 검사를 우회하는 것을 피하십시오, 필요한 경우가 아니라면.

OIDC에서 액세스 토큰, 리프레시 토큰 및 ID 토큰의 주요 차이를 요약합니다

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

  • 액세스 토큰은 보호된 리소스에 접속하는 권한을 제공합니다.
  • 리프레시 토큰은 사용자 개입 없이 새 액세스 토큰을 발급받습니다.
  • ID 토큰은 클라이언트에 캐시된 사용자 정보를 제공하여 성능을 향상시킵니다.

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