대부분의 OAuth 2.0 서비스에서 JWT를 사용하는 이유

OAuth 2.0은 오늘날 널리 사용되고 있습니다. 인증 서비스의 핵심 프레임워크로서, OAuth 2.0의 주요 책임 중 하나는 사용자에 대한 액세스 토큰을 발급하는 것입니다. 우리는 시장의 많은 OAuth 서비스 제공자가 JWT 형식의 액세스 토큰을 발급하는 것을 주목했습니다.

이 기사에서는 JWT가 무엇인지, 그리고 자주 액세스 토큰 형식으로 사용되는 이유를 설명합니다.

JWT 소개#

JWT는 JSON 웹 토큰의 약자로, RFC 7519에 다음과 같이 정의되어 있습니다:

JSON Web Token (JWT)은 두 당사자 간에 전달될 클레임을 나타내는 간편하고 URL-안전한 수단입니다.

이 정의는 JWT가 서로 다른 당사자 간에 클레임을 전달하는 데 사용되는 토큰임을 명확히 합니다.

JWT는 여러 당사자 간에 전달되므로, 데이터의 무결성과 인증을 보장하기 위해 서명됩니다.

서명된 JWT는 다음과 같은 형식을 갖습니다:

이것은 .으로 구분된 헤더, 페이로드 및 서명, 세 부분으로 구성됩니다.

다음은 실제 JWT 예시입니다:

다음에서 파싱해볼 수 있습니다: https://jwt.io:

이미지에서 보이는 것처럼, JWT의 헤더 섹션에는 서명 알고리즘 사용 및 토큰 유형에 대한 정보가 포함되어 있습니다. 페이로드 섹션에는 JWT가 전달하는 클레임이 포함되어 있으며, 서명은 JWT의 무결성을 검증하는 데 사용됩니다.

이제 JWT가 무엇인지, 그 각 부분의 의미를 이해했으므로, 이제 왜 많은 OAuth 인증 서비스들이 JWT를 액세스 토큰으로 선택하는지 설명하겠습니다.

JWT 사용의 장점#

JWT와 전통적 무작위로 생성된 문자열 기반 토큰 간의 주요 차이점은 JWT가 정보를 전달할 수 있으며, 디코딩을 통해 검증할 수 있다는 것입니다. 이러한 차이점은 두 가지 주요 이점을 제공합니다:

• 자원 효율성: JWT는 사용자나 세션에 관한 정보를 전달할 수 있어 빈번한 데이터베이스 조회의 필요성을 제거합니다. 이러한 효율성은 서비스의 자원 소비를 줄일 수 있습니다.
• 향상된 가용성 및 확장성: JWT는 서버 상태 관리에 대한 의존도를 줄입니다. 이는 서비스가 더 비상태화되게 만들어 가용성과 확장성을 향상시킵니다.

전통적인 무작위 문자열 기반 토큰을 사용할 때, 일반적인 검증 및 인증 프로세스는 다음과 같습니다:

다이어그램에서 보이는 것처럼, 시스템에 많은 사용자가 있고 다양한 리소스 서버가 있을 때, 인증 서버에 많은 토큰 검증 요청이 발생할 수 있습니다.

시간이 지남에 따라 시스템이 성장하면, 인증 서버는 쉽게 병목 현상이 될 수 있으며 전체 서비스 가용성에 도전이 될 수 있습니다.

그러나 JWT를 도입하면, 검증 프로세스가 다음과 같이 변합니다:

디코딩을 통한 검증이 가능한 JWT의 기능 덕분에, 리소스 서버는 인증 서버와 상호작용할 필요 없이 JWT의 무결성을 검증하고 사용자 정보를 추출할 수 있습니다 (JWT의 디코딩 및 검증 방법에 대한 자세한 내용은 Logto 문서를 참조하십시오).

JWT의 제한점#

JWT가 현대 소프트웨어 아키텍처에서 많은 이점을 제공하는 반면, 고려해야 할 제한점도 있습니다.

쉽게 노출되는 페이로드#

앞서 언급했듯이, JWT는 헤더, 페이로드, 서명 이렇게 세 부분으로 구성됩니다. 이 구성 요소들은 어떻게 생성될까요? 이전 예시에서 JWT를 가져와 JWT 생성 프로세스를 설명하겠습니다:

위의 코드에서 보이듯이, JWT의 헤더와 페이로드는 기본적으로 base64 문자열로 인코딩됩니다.

즉, 누군가가 토큰에 접근할 수 있다면, JWT 페이로드의 base64 문자열을 쉽게 디코딩하여 포함된 정보를 볼 수 있습니다. 반대로, 페이로드를 위조하고 원래 JWT의 페이로드를 조작된 것으로 교체하기도 상대적으로 쉽습니다.

JWT의 페이로드가 상대적으로 쉽게 위조될 수 있다는 것은 사실이지만, JWT의 서명 부분은 비밀 서명 키가 필요하기 때문에 위조된 내용으로 교체할 수 없습니다. 따라서 올바른 서명이 없으면 JWT는 검증을 통과할 수 없습니다.

따라서 JWT를 사용할 때 다음 고려사항을 염두에 두는 것이 중요합니다:

1. 항상 SSL 사용: JWT 정보가 전송 중에 누출되지 않도록 SSL(보안 소켓 계층) 또는 그 후속 기술인 TLS(전송 계층 보안)를 사용하여 데이터를 암호화하는 것이 중요합니다.
2. 민감한 데이터 저장 금지: JWT 페이로드에 민감한 데이터를 저장하는 것은 추천하지 않습니다. 페이로드는 쉽게 디코딩될 수 있으므로 주로 민감하지 않은, 관련된 클레임만 포함해야 합니다.
3. JWT 검증: JWT 안의 정보에 의존하기 전에 서명 검증 및 토큰 만료 확인 등 올바르고 안전한 검증 과정을 거친 상태인지 확인해야 합니다. 이는 조작되었거나 승인되지 않은 토큰 사용을 방지하는 데 도움이 됩니다.

철회하기 어려움#

일반적으로, 액세스 토큰은 만료 시간이 있습니다. 무작위 문자열로 나타내어진 액세스 토큰의 경우, 인증 서버에서의 각 검증 동안 토큰이 철회되었는지 확인할 수 있습니다.

그러나 JWT는 JWT 자체에 만료 정보를 포함하고 있으며, JWT 검증이 인증 서버에 의존하지 않으므로, 인증 서버에서 JWT 형식의 액세스 토큰을 발급한 후 해당 토큰의 상태를 사용 중에 변경할 수 없습니다.

JWT 토큰이 자연히 만료된 후, 리프레시 토큰을 사용하여 인증 서버에서 새로운 JWT를 얻을 수 있습니다 (리프레시 토큰에 대한 정보는 Logto 블로그를 참조하십시오).

그러나 사용자가 권한을 철회하거나 비밀번호를 변경하는 등 특정 상황에서는 만료되지 않은 이미 발급된 토큰을 철회할 필요가 있을 때, 간단한 해결책이 없습니다.

토큰 철회의 영향을 중간에 완화하는 두 가지 일반적인 접근 방식이 있습니다:

1. 액세스 토큰의 만료 시간을 더 짧게 설정하고, 토큰 리프레시 메커니즘을 사용하여 토큰 상태를 즉시 새로 고침합니다.

액세스 토큰의 만료 시간이 더 짧기 때문에 사용자가 액세스 토큰이 만료된 것을 발견했을 때, 인증 서비스로부터 리프레시 토큰으로 새로운 액세스 토큰을 요청할 수 있습니다. 이렇게 하면 사용자의 토큰 상태가 백엔드와 가능한 한 빨리 동기화될 수 있습니다. 그러나 이 접근 방식은 추가적인 오버헤드를 유발할 수 있으며, 사용자는 이를 고려해야 합니다.

2. 액세스 토큰에 대한 철회 목록을 유지하고 각 검증 시 해당 토큰이 목록에 있는지 확인합니다.

이 방법은 특정 제한이 있습니다. JWT의 장점 중 하나는 서버가 상태 정보를 저장할 필요가 없다는 것이며, JWT는 일반적으로 무상태입니다. 그러나 철회 목록을 유지하기 위해서는 추가적인 저장 메커니즘에 의존해야 하며, 이는 JWT의 장점을 희생시키고 잠재적으로 성능 문제를 초래할 수 있습니다. 따라서 토큰 철회 메커니즘은 개발자가 특정 사용 사례에 적합한 방식으로 구현해야 합니다.

요약#

이 기사에서는 JWT에 대한 간단한 소개와 그 장점 및 제한점을 강조했습니다. 이제 JWT와 일반적으로 사용되는 시나리오에 대해 더 깊은 이해를 가지고 있을 것입니다. JWT는 특정 도전 과제를 갖고 있지만, OAuth 2.0 서비스에서 토큰 형식으로 사용할 때 제공하는 이점은 단점보다 훨씬 큽니다.

Logto는 급성장하는 신원 인증 서비스로, JWT를 액세스 토큰 형식으로 채택하고 있습니다. 여러 인증 및 인증 프로토콜을 엄격히 준수하며, 제품에 신원 인증 서비스를 쉽게 통합할 수 있게 해줍니다. Logto의 SaaS 서비스가 공식적으로 출시되었으며, 오늘 무료로 시도해볼 수 있습니다.