JSON 웹 토큰(JWT)을 언제 처음 보았는지는 잘 모르겠지만 그 이후로 많은 것을 보았습니다. 훈련되지 않은 사람의 눈에는 다음과 같이 왜곡된 컴퓨터 아웃풋처럼 보일 수 있습니다.
실제로 위에 설명한 내용과 일반적인 JWT는 클라우드 환경이든 온프레미스 환경이든 보안에 직접적인 영향을 주는 핵심 정보를 담고 있습니다. 이 정보는 사용자를 식별하고 인증하는 데 사용됩니다. JWT는 마이크로서비스 기반 솔루션을 작동시키는 데 필수적이며, 12요소 앱을 구현하는 데 중요한 구성 요소입니다
이 블로그 글에서는 JWT의 역사와 기본 개념을 소개하고, IBM Cloud에서의 일반적인 JWT 사용 사례를 살펴보겠습니다.
Think 뉴스레터
Think 뉴스레터를 통해 AI, 사이버 보안, 데이터 및 자동화에 대한 선별된 뉴스를 제공하는 보안 리더들과 함께하세요. 받은 편지함으로 직접 제공되는 전문가 튜토리얼과 설명서를 통해 빠르게 배울 수 있습니다. IBM 개인정보 보호정책을 참고하세요.
구독한 뉴스레터는 영어로 제공됩니다. 모든 뉴스레터에는 구독 취소 링크가 있습니다. 여기에서 구독을 관리하거나 취소할 수 있습니다. 자세한 정보는 IBM 개인정보 보호정책 을 참조하세요.
JSON 토큰의 첫 번째 초안은 이미 10년이 넘었습니다(2010년 12월에 작성됨). 초기 초안에는 다음과 같이 명시되어 있습니다. "JSON 웹 토큰(JWT)은 두 당사자 간에 전송되는 클레임을 인코딩할 수 있는 토큰 형식을 정의합니다. JWT의 클레임은 디지털 서명된 JSON 객체로 인코딩됩니다."
최신 버전인 IETF RFC 7519에서는 다음과 같이 정의됩니다. “JSON 웹 토큰(JWT)은 두 당사자 간에 전달될 클레임을 표현하기 위한 간결하고 URL에 안전한 방식입니다. JWT 내의 클레임은 JSON 객체로 인코딩되며, 이는 JSON 웹 서명(JWS) 구조의 페이로드로 사용되거나 JSON 웹 암호화(JWE) 구조의 평문으로 사용됩니다. 이로 인해 클레임은 디지털 서명되거나 메시지 인증 코드(MAC)를 통해 무결성이 보호되거나 암호화될 수 있습니다.”
새로운 설명은 JWT(종종 'jot'으로 발음)의 두 가지 표현, 즉 JSON 웹 서명(JWS) 또는 JSON 웹 암호화(JWE) 구조를 암시합니다. JWS는 RFC 7515에 정의되어 있고 JWE는 RFC 7516에 정의되어 있습니다. JOSE: JSON 객체 서명 및 암호화라는 작업 그룹에서 정의한 더 많은 관련 JSON 기반 보안 표준도 있습니다.
OAuth 2.0은 권한 부여를 위한 업계 표준입니다. 자세히 설명하지 않더라도, OAuth는 권한 부여 흐름과 액세스 토큰과 리프레시 토큰을 포함한 핵심 개념을 제공합니다. 반드시 사용해야 하는 것은 아니지만, 요즘은 일반적으로 JWT가 사용됩니다. 앞서 언급했듯이 OAuth는 권한 부여에 중점을 두지만, 종종 신원 확인 용도로 잘못 사용되기도 했습니다. OpenID Connect는 이 퍼즐의 빠진 조각을 채워주며, 신원 확인용 ID 토큰 개념을 도입합니다. ID 토큰은 JWT 형식으로 표현됩니다.
이러한 기록과 일부 표준을 기반으로 위의 JWT를 어떻게 처리할 수 있으며 이는 어떤 정보를 보유하고 있을까요?
위의 JWT는 점(‘.’)으로 각각 구분된 세 부분으로 구성됩니다.
헤더와 페이로드는 모두 base64url로 인코딩되며 가능한 패딩을 고려하지 않고 다음과 같이 디코딩할 수 있습니다.
henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}
henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input
헤더에는 사용된 알고리즘 정보가 포함되어 있으며, 여기서는 HS256(HMAC SHA256)을 사용합니다. 페이로드는 액세스/리프레시/ID 등의 토큰 유형에 따라 달라지며, 클레임으로 구성됩니다.이러한 사전 정의된 JOSE 헤더 및 페이로드 필드는 IANA에 의해 관리됩니다. 위의 예에서 필드와 클레임은 subj(ect), name, issued at (iat) 및 exp(iration time)입니다.
서명은 명시된 알고리즘을 헤더, ‘.’ 및 페이로드의 연결에 적용한 다음 결과를 인코딩하는 base64url을 적용하여 계산됩니다. 그런 다음 점으로 구분된 세 부분이 JWT를 구성합니다. 서명이 파생되는 방법에 대한 자세한 내용은 RFC 7515에 정의되어 있습니다.
JWT.io에서 이 JWT를 온라인 디버거로 확인해보실 수 있습니다. 처음에는 “Invalid Signature”(잘못된 서명)라는 메시지가 표시됩니다. 기본 시크릿 값을 !!!my-really-big-256-bit-secret!!!로 바꾸면 문제를 해결할 수 있습니다.
IBM Cloud는 카탈로그에서 많은 서비스를 제공하고 자체 구성 요소가 많은 인터넷 앱이기 때문에 토큰을 많이 사용합니다. IBM® Cloud Command Line Interface(CLI)와 ibmcloud iam oauth-tokens를 사용해 본 적이 있을 것입니다.
JWT로 구현된 현재 CLI 세션에 대한 OAuth 전달자 토큰(액세스 토큰)을 인쇄합니다. 이러한 토큰은 IAM 지원 클라우드 서비스에 액세스하는 데 사용됩니다.
외부 사용자를 클라우드 계정에 통합하려면, 이 경우에도 JWT가 사용됩니다. ID 토큰과 그 안에 포함된 클레임은 사용자를 인증하고 신원을 확인하는 데 사용됩니다. 많은 솔루션들이 IBM® Cloud App ID라는 보안 서비스를 활용합니다. 이 서비스는 사용자 인증과 리소스 보호를 돕습니다. OAuth 2.0 및 OpenID Connect 표준을 기반으로 하며, 액세스 토큰, ID 토큰, 리프레시 토큰을 처리합니다.
챗봇을 만들 때 많이 사용하는 인기 서비스 중 하나는 watsonx Assistant입니다. 웹 채팅을 보호하고 싶다면(예: 메시지 내용을 보호하고 출처를 검증하기 위해), JWT가 유용하게 사용됩니다.
물론 JWT를 활용하여 (보안) 클레임을 쉽게 교환하여 클라우드 솔루션의 보안을 강화하는 방법에 대한 더 많은 예가 있습니다.
JWT는 두 당사자 간에 청구를 교환할 수 있는 쉽고 독립적인 수단입니다. 클라우드와 온프레미스에서 흔히 볼 수 있는 데이터 구조입니다. 위의 내용이 여러분의 관심을 불러일으키는 데 도움이 되었기를 바랍니다(아직 관심을 갖지 않으셨다면!).
JWT를 직접 검사하고 수정하고 싶다면 https://jwt.io/ 같은 온라인 툴을 사용하여 시작하는 것이 좋습니다. 더 자세히 알고 싶다면 네트워크 모니터 또는 브라우저의 개발자 툴을 사용하여 JWT를 주시하세요. 다양한 보안 관련 튜토리얼을 포함한 IBM Cloud 튜토리얼을 확인해 보세요.
이 게시물에 대한 피드백, 제안 또는 질문이 있는 경우 Twitter(@data_henrik) 또는 LinkedIn에서 저에게 연락해 주세요.