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