웹 애플리케이션 보안을 강화하는 데 있어 JWT와 OAuth는 모두 중요한 역할을 합니다. 이 두 가지 기술 모두 보안 인증 및 권한 부여 기능을 제공하지만, 어떤 것을 선택해야 할까요? 이 글에서는 JWT와 OAuth의 차이점을 자세히 살펴보고, 웹 애플리케이션에 적합한 보안 솔루션을 선택하는 데 도움을 드립니다.
이 글을 통해 JWT와 OAuth의 기본 개념, 이점, 차이점, 그리고 웹 애플리케이션 보안 강화를 위한 최적의 구현 방법에 대한 명확한 이해를 얻으실 수 있을 것입니다.
자세히 알아볼까요?
JWT란 무엇인가?
JWT (JSON Web Token)는 두 당사자 간에 JSON 객체 형태로 정보를 안전하게 교환하기 위한 개방형 표준입니다. 디지털 서명이 적용되어 있어, 정보를 수신하는 측은 토큰의 진위 여부를 검증하고 신뢰할 수 있습니다.
JWT는 비교적 작은 크기로, POST 파라미터, URL 또는 HTTP 헤더를 통해 전송할 수 있습니다. JWT는 헤더, 페이로드, 서명 세 부분으로 구성됩니다.
헤더는 토큰의 유형과 서명 알고리즘 정보를 제공합니다. 페이로드는 사용자 정보 및 기타 관련 데이터를 담고 있는 클레임으로 구성됩니다.
서명 부분은 토큰이 전송 과정에서 변조되지 않았음을 확인하는 역할을 합니다.
JWT 작동 방식
이미지 출처: 개발
JWT의 작동 방식은 다음과 같습니다.
사용자 로그인
사용자는 사용자 이름과 비밀번호를 입력하여 웹 애플리케이션에 로그인합니다. 이 로그인 정보는 인증 서버로 전송됩니다.
토큰 생성
인증 서버는 사용자 로그인 정보를 확인한 후, 사용자에게 JWT를 발급합니다. 이 JWT에는 사용자 및 인증 세션 정보가 포함될 수 있습니다. 사용자는 로컬 환경에 이 JWT를 저장합니다. 서버는 보안 강화를 위해 공유 비밀 키 또는 개인 키를 사용하여 JWT에 서명할 수 있습니다.
토큰 검증
사용자가 애플리케이션 서버에 리소스 접근을 요청할 때, 요청에 JWT가 포함됩니다. 애플리케이션 서버는 JWT 서명을 확인하고, 페이로드의 클레임을 검토하여 사용자가 해당 리소스에 접근 권한이 있는지 확인합니다.
JWT가 유효하면, 사용자에게 요청한 웹 애플리케이션 리소스에 대한 접근 권한이 부여됩니다.
JWT 활용 사례
JWT는 다음과 같은 다양한 방법으로 활용됩니다.
#1. 권한 부여
사용자가 로그인 엔드포인트를 통해 웹 애플리케이션에 성공적으로 로그인하면 인증 서버에서 JWT를 발급합니다. 사용자는 이 JWT를 사용하여 애플리케이션 내 리소스에 접근할 수 있으며, 이때 신원 확인을 위한 인증 절차가 필요합니다.
당사자 간 정보 교환
JWT는 유효한 사용자 간에 정보를 안전하게 전송하는 데 효과적인 방법입니다. JWT는 서명되어 정보의 출처를 확인할 수 있으며, 정보가 전송 과정에서 변조되지 않았는지 확인할 수 있습니다.
JWT의 이점
웹 애플리케이션에 JWT를 도입했을 때 얻을 수 있는 주요 이점은 다음과 같습니다.
- JWT는 SAML 토큰에 비해 가볍기 때문에 HTML 및 HTTP 환경에서 빠르게 구현할 수 있습니다. 따라서 모바일 애플리케이션과 같은 클라이언트 애플리케이션에 적합합니다.
- JWT는 강력한 보안을 제공합니다. 공유 비밀 키를 사용하는 HMAC 알고리즘이나 비대칭 서명 방식인 개인 키를 사용하여 JWT를 대칭적으로 서명할 수 있습니다.
- JWT에는 만료 메커니즘이 내장되어 있어, 토큰 만료 기간을 설정하여 보안을 강화할 수 있습니다.
- JWT는 다양한 Single Sign-On 솔루션에서 널리 사용되므로, 비교적 쉽게 작업할 수 있습니다.
또한 JWT는 서버가 토큰만 생성하고 클라이언트 측에 저장하기 때문에 데이터베이스 저장 공간을 절약할 수 있습니다. JWT는 데이터베이스 조회가 필요하지 않기 때문에 빠르게 검증하여 사용자 경험을 개선할 수 있습니다.
JWT의 한계
JWT는 사용자 권한 부여에 유용하지만, 몇 가지 제한 사항이 있습니다.
- 암호화 키의 보안은 사용자의 책임입니다. 해커가 JWT 서명 키를 획득하면 가짜 토큰을 생성하여 사용자 데이터를 손상시킬 수 있으며, 이는 심각한 보안 위험을 초래합니다.
- JWT는 각 검증 시 데이터베이스 호출이 필요하지 않지만, 즉시 취소해야 하는 경우 블랙리스트에 등록해야 합니다. 이 과정은 빠르고 간단하지 않습니다.
- JWT가 만료되면 단순히 만료 시간을 연장하는 것이 아니라, 시스템은 사용자에게 새로운 토큰을 발급받기 위해 다시 로그인하도록 요청해야 합니다. 이로 인해 전체 프로세스가 복잡해지고, 사용자 경험과 보안 흐름을 더 깊이 고민해야 합니다. 사용자 경험을 개선하기 위해 JWT와 함께 새로 고침 토큰을 사용할 수 있습니다. 액세스 토큰이 만료되면, 클라이언트는 로그인 자격 증명을 다시 입력하지 않고 새로 고침 토큰을 사용하여 새로운 액세스 토큰을 요청할 수 있습니다.
- 웹 애플리케이션에 JWT를 구현하는 것은 복잡한 작업입니다. 토큰 생성 프로세스를 설정하고, 적절한 서명 메커니즘을 선택하고, 기존 아키텍처와 통합하는 추가적인 노력이 필요합니다.
JWT는 단일 솔루션이 아니라 세심한 계획과 실행이 필요한 프로젝트입니다.
OAuth란 무엇인가?
OAuth (Open Authorization)는 인증을 위한 개방형 표준 인증 프로토콜입니다. 이를 통해 웹 애플리케이션은 사용자가 타사 애플리케이션에 로그인 정보를 직접 제공하지 않고도 해당 사용자를 대신하여 타사 애플리케이션에서 호스팅하는 리소스에 접근할 수 있습니다.
OAuth의 최신 버전인 OAuth 2.0은 인증 서버를 통해 사용자를 인증하는 데 널리 사용됩니다.
예를 들어, OAuth를 사용하면 사용자는 Facebook 또는 Google 계정으로 애플리케이션에 로그인할 수 있습니다. 이때, 사용자는 Facebook이나 Google 계정에만 로그인 정보를 입력합니다.
OAuth 작동 방식
이미지 출처: 조호
예를 들어, 시간 관리 앱을 개발했다고 가정해 보겠습니다. 사용자가 앱을 효율적으로 사용하기 위해 이메일 받은 편지함에 접근할 수 있어야 합니다. 과거에는 사용자가 앱이 받은 편지함에 접근할 수 있도록 로그인 자격 증명을 공유해야 했습니다. OAuth 2.0은 이 문제를 해결했습니다.
OAuth 2.0 워크플로우는 다음과 같습니다.
- 시간 관리 앱(클라이언트)이 보호된 리소스(사용자의 받은 편지함)에 대한 접근을 요청합니다. 이를 위해 앱은 사용자를 인증된 엔드포인트로 보냅니다.
- 리소스 소유자(사용자)는 시간 관리 앱의 리소스 접근 요청을 승인합니다. 클라이언트(앱)는 승인된 엔드포인트로부터 승인 부여를 받습니다.
- 애플리케이션은 사용자의 받은 편지함에 접근하기 위해 인증 서버에 액세스 토큰을 요청합니다. 이때 승인 부여를 제출하고, 자체 신원을 인증합니다.
- 앱의 ID가 인증되고, 승인 부여가 유효하면 앱은 사용자의 받은 편지함에 접근할 수 있는 액세스 토큰을 받습니다.
- 액세스 토큰이 유효하면 앱은 액세스 토큰을 제출하여 사용자 데이터(사용자의 받은 편지함)에 접근할 수 있습니다.
이제 시간 관리 앱은 사용자의 받은 편지함에 접근할 수 있습니다. OAuth와 마찬가지로 다양한 승인 부여 유형을 가지고 있으며, 승인 흐름은 승인 부여 유형에 따라 약간 다를 수 있습니다.
OAuth의 이점
OAuth 사용의 주요 이점은 다음과 같습니다.
- OAuth는 널리 사용되는 표준이며, 대부분의 주요 인증 서비스에서 OAuth를 이해하고 사용합니다.
- OAuth는 폭넓은 호환성을 제공하며, 사용자는 다양한 OAuth 플러그인과 기능을 선택할 수 있습니다.
- OAuth는 거의 모든 프로그래밍 언어 및 웹 프레임워크에서 테스트된 클라이언트 라이브러리를 제공하므로, 원하는 언어를 자유롭게 사용할 수 있습니다.
- OAuth는 매우 안전하고 철저하게 검증되었으며, 보안 전문가들이 이미 발생 가능한 모든 보안 위험을 고려했습니다.
- OAuth는 코드 분리에 유용합니다. 인증 작업을 처리할 때 기본 애플리케이션 코드가 복잡해지지 않으므로, 앱을 장기적으로 더 쉽게 관리하고 업데이트할 수 있습니다.
OAuth 활용 사례
다음은 OAuth의 일반적인 활용 사례입니다.
- OAuth 2.0은 타사 애플리케이션이 사용자 계정에 접근하는 가장 일반적인 방법입니다. 사용자는 제3자에게 로그인 자격 증명을 제공하지 않고도 다양한 서비스에 저장된 데이터에 접근할 수 있도록 권한을 부여할 수 있습니다.
- 웹 애플리케이션 소유자는 OAuth 2.0을 사용하여 Single Sign-On을 구현할 수 있으며, 오픈 소스 OAuth 솔루션을 통해 프로젝트에 적용할 수 있습니다.
- API 게이트웨이에 OAuth 2.0을 구현하여 API 게이트웨이가 인증 서버 역할을 하도록 할 수 있습니다. 이로써 API 게이트웨이는 유효한 액세스 토큰을 사용하여 클라이언트 요청을 전달할 수 있습니다.
- OAuth 2.0은 IoT 및 스마트 장치가 사용자를 대신하여 타사 API와 상호 작용할 수 있도록 지원합니다. 특히 스마트 TV나 게임 콘솔과 같이 키보드가 없는 장치에서 앱에 로그인할 때 유용합니다.
OAuth의 한계
OAuth를 처음 접하는 사람들에게는 사용 가능한 다양한 흐름이 복잡하게 느껴질 수 있습니다. 특정 요구 사항을 충족하기 위해 여러 흐름을 조합해야 할 수도 있습니다. 이러한 복잡성 때문에 초보자는 어디서부터 시작해야 할지, 무엇을 사용해야 할지, 효과적으로 통합하는 방법을 알기 어려울 수 있습니다.
각 흐름은 모바일 앱, 서버 간 통신, 웹 애플리케이션 등 고유한 용도로 사용되므로, 사용 전에 특정 요구 사항을 면밀히 분석하는 것이 필수적입니다.
OAuth 2.0은 SSL/TLS를 사용하여 보안을 유지합니다. SSL/TLS가 올바르게 설정되지 않으면 OAuth 2.0의 보안이 취약해질 수 있습니다.
또한 OAuth는 특히 사용자 활동을 추적할 때 개인 정보 보호 문제를 야기할 수 있습니다. ‘Google로 로그인’과 같은 서비스를 사용하는 경우, Google은 해당 제3자 사이트에서의 사용자의 활동을 파악할 수 있습니다. Google은 사용자가 로그인했음을 알 수 있을 뿐만 아니라, 사용자가 해당 사이트와 상호 작용하는 빈도와 시기를 추적할 수 있습니다.
또한 OAuth는 프런트엔드와 백엔드만 있는 간단한 앱과 같은 경우에는 과도할 수 있습니다. 이러한 경우, 복잡성이 불필요할 수도 있습니다.
JWT와 OAuth의 차이점
JWT와 OAuth는 사용자 신원을 확인하고 리소스 접근 권한을 부여하는 중요한 기능을 제공합니다. 이 두 가지는 보안 환경에서 필수적인 도구이지만, 범위, 복잡성, 적용 분야가 다릅니다.
| 기능 | JWT | OAuth |
| 주요 용도 | 주로 API에 중점을 둡니다. | 웹, 브라우저, API 및 기타 앱을 처리합니다. |
| 토큰 대 프로토콜 | 토큰 형식입니다. | 인증 프로토콜입니다. |
| 스토리지 | 클라이언트 측 저장소에만 의존합니다. | 클라이언트 측 및 서버 측 저장소를 모두 사용합니다. |
| 유연성 | 범위가 더 제한적입니다. | 더욱 유연하고 폭넓은 사용 사례를 제공합니다. |
| 사용 용이성 | 더 간단하고 이해하기 쉽습니다. | 더 복잡합니다. |
JWT는 더 간단하고 API 보안에 특화되어 있는 반면, OAuth는 다양한 시나리오에 적응할 수 있는 포괄적인 인증 메커니즘 솔루션을 제공합니다.
또한 OAuth는 사용자가 로그인 정보를 공개하지 않고도 타사 앱이 다른 플랫폼의 데이터에 접근할 수 있도록 합니다.
어떤 기술이 더 나은지는 시스템 또는 네트워크의 특정 요구 사항에 따라 달라집니다.
JWT와 OAuth를 함께 사용할 수 있나요?
JWT와 OAuth는 서로 다른 목적으로 사용되지만, 함께 결합하여 사용할 수 있습니다.
OAuth 프로토콜은 사용해야 하는 특정 토큰 형식을 규정하지 않습니다. 따라서 OAuth에서 JWT를 구현할 수 있습니다.
예를 들어, OAuth2 인증 서버는 JWT를 포함하는 액세스 토큰을 발급할 수 있습니다. 이 JWT는 페이로드에 추가 정보를 포함하여 성능을 향상시킬 수 있습니다. 이는 인증 서버와 리소스 서버 간의 왕복 횟수를 줄여주기 때문입니다.
JWT와 OAuth2 결합은 이중 토큰 방식을 통해서도 이루어질 수 있습니다. OAuth2는 이 방식으로 두 개의 개별 토큰 (access_token 및 JWT)을 발급합니다. JWT에는 추가 식별 정보가 포함되어 있습니다. 이 방식은 사용자 접근 및 데이터에 대한 더 많은 제어와 함께 추가적인 정보 계층을 제공합니다.
이 이중 토큰 전략을 선택할 때 OpenID Connect를 사용하는 것이 중요합니다. OpenID Connect는 OAuth2를 기반으로 하며, 토큰에 더욱 표준화된 필드를 추가합니다.
OAuth2 대신 JWT를 사용하면 특정 작업의 프로세스를 더 빠르고 덜 복잡하게 만들 수 있습니다. 그러나 개발을 더욱 어렵게 만들 수도 있습니다.
OAuth2와 함께 JWT를 사용하기로 결정할 때, 속도 향상이 개발 시 추가 작업을 정당화하는지 신중하게 고려해야 합니다.
결론
JWT와 OAuth 중 어떤 것이 웹 보안에 더 적합한지에 대한 논의에서, 각 기술은 고유한 장단점을 가지고 있습니다. JWT는 상태 저장 없이 빠르고 효율적인 인증에 탁월하지만, 기본 제공 취소 기능이 없는 등의 제약이 있습니다. OAuth는 복잡한 인증 시나리오에 적합하지만, 단순한 프로젝트에는 과도할 수 있습니다.
강력한 권한 부여 및 효율적인 인증이 필요한 경우 OpenID Connect를 통해 JWT와 OAuth를 결합하는 것을 고려해 볼 수 있습니다.
가장 적절한 선택은 이러한 기술에 대한 과대 광고보다는 프로젝트의 특정 요구 사항에 따라 결정되어야 합니다.
또한, 다양한 사용자 인증 플랫폼을 탐색하여 애플리케이션에 가장 적합한 솔루션을 선택할 수 있습니다.