SSL/TLS, JWT, OAuth는 무엇이 다를까?
HTTPS, JWT, OAuth 같은 보안 용어는 개발을 시작하면 거의 반드시 만나게 된다. 문제는 이름은 익숙한데 역할이 서로 섞여 보인다는 점이다. 어떤 문서는 JWT를 인증이라고 설명하고, 어떤 곳은 OAuth를 로그인이라고 부르며, 또 다른 곳에서는 HTTPS만 적용하면 안전하다고 말한다. 하지만 실제 서비스 구조에서는 세 기술이 서로 다른 계층에서 움직인다.
핵심은 데이터 흐름을 기준으로 이해하는 것이다. TLS는 통신 자체를 보호하고, JWT는 로그인 상태를 유지하며, OAuth는 외부 서비스 권한 위임을 담당한다. 역할만 명확히 구분해도 대부분의 인증 구조가 훨씬 단순하게 보이기 시작한다.
| 기술 | 핵심 역할 | 주 사용 위치 |
|---|---|---|
| SSL/TLS | 네트워크 통신 암호화 | HTTPS |
| JWT | 로그인 상태 유지 | API 인증 |
| OAuth | 외부 권한 위임 | 소셜 로그인 |
실제 서비스에서는 OAuth로 로그인을 수행하고, 서버는 자체 JWT를 발급하며, 전체 통신은 TLS 기반 HTTPS 위에서 이루어진다. 이 세 가지는 경쟁 기술이 아니라 하나의 인증 흐름 안에서 동시에 동작한다.
SSL/TLS, JWT, OAuth를 한 문장으로 구분하기
SSL/TLS는 데이터를 안전하게 전송하고, JWT는 로그인 상태를 표현하며, OAuth는 외부 권한 위임을 처리한다. 이 한 줄이 전체 구조의 핵심이다.
TLS는 브라우저와 서버 사이의 통신 내용을 암호화한다. 사용자가 로그인 정보를 입력하거나 결제 데이터를 전송하더라도 네트워크 중간에서 내용을 읽을 수 없게 만드는 역할이다. HTTPS 주소에서 사용하는 핵심 보안 기술도 바로 TLS다.
JWT는 로그인 이후 사용자가 누구인지 서버가 빠르게 확인하기 위해 사용하는 토큰 형식이다. 서버는 매 요청마다 JWT를 검증하면서 사용자의 인증 상태를 확인한다.
OAuth는 외부 서비스 계정을 안전하게 이용하기 위한 권한 위임 방식이다. 대표적으로 “구글로 로그인”, “카카오 로그인” 같은 기능이 OAuth 기반으로 동작한다. 서비스가 사용자의 비밀번호를 직접 저장하지 않아도 된다는 점이 핵심이다.
이 세 기술은 실제 로그인 흐름에서 자연스럽게 연결된다. 사용자가 소셜 로그인을 수행하면 OAuth 인증이 진행되고, 서버는 자체 JWT를 발급한다. 이후 클라이언트와 서버의 모든 요청은 HTTPS 환경에서 보호된다.
SSL/TLS는 데이터를 안전하게 오가게 만드는 기술
TLS는 인터넷 통신 자체를 보호하기 위한 암호화 프로토콜이다. 과거에는 SSL이라는 이름이 널리 사용됐지만 현재 대부분의 서비스는 TLS 기반으로 동작한다.
브라우저에서 HTTPS 주소로 접속하면 가장 먼저 TLS 핸드셰이크가 수행된다. 이 과정에서 서버 인증서 검증, 암호화 방식 협상, 세션 키 생성이 이루어진다. 이후부터는 네트워크 패킷이 암호화된 상태로 전송된다.
이 구조 덕분에 공용 와이파이나 중간 네트워크 장비를 거치더라도 로그인 정보와 쿠키 데이터를 쉽게 탈취하기 어렵다. 실제로 HTTPS가 제대로 적용되지 않았던 초기 웹 환경에서는 세션 쿠키 탈취 공격이 매우 자주 발생했다.
TLS의 역할은 단순 암호화만이 아니다. 서버 신뢰성 검증도 함께 수행한다. 브라우저는 인증서를 통해 “현재 접속한 서버가 실제 서비스 서버인지” 확인한다. 주소창의 자물쇠 표시가 중요한 이유도 여기에 있다.
과거 SSL 2.0과 SSL 3.0은 심각한 취약점이 발견되면서 대부분 폐기되었다. 하지만 여전히 업계에서는 “SSL 인증서”라는 표현이 남아 있다. 실제로는 TLS 인증서를 사용하면서 관습적으로 SSL이라는 이름을 유지하는 경우가 많다.
최근에는 TLS 1.3 사용이 빠르게 확대되면서 보안 수준뿐 아니라 연결 속도까지 개선되었다. CDN과 클라우드 플랫폼에서도 HTTPS 기본 적용이 일반화되면서 TLS는 이제 선택 기능이 아니라 기본 인프라에 가까워졌다.
JWT는 로그인 이후 사용자를 식별하는 토큰 구조
JWT는 JSON Web Token의 약자다. 로그인 이후 사용자의 상태를 서버가 확인하기 위해 자주 사용하는 토큰 형식이다.
전통적인 세션 방식에서는 서버가 로그인 상태를 직접 저장했다. 사용자가 많아질수록 세션 저장소 관리 비용이 증가하고 서버 확장도 복잡해진다. JWT는 서버 상태 저장 부담을 줄이기 위해 많이 사용된다.
JWT는 Header, Payload, Signature 세 부분으로 구성된다. Payload에는 사용자 ID, 권한 정보, 만료 시간 같은 데이터가 포함된다. 서버는 Signature를 검증해 토큰이 위변조되지 않았는지 확인한다.
입문 단계에서 가장 자주 발생하는 오해는 “JWT가 암호화 토큰”이라는 생각이다. 실제로 JWT는 기본적으로 인코딩 구조에 가깝다. 따라서 Payload 내부 데이터는 누구나 읽을 수 있다. 비밀번호나 민감한 개인정보를 직접 넣는 것은 매우 위험하다.
실무에서는 Access Token과 Refresh Token을 분리하는 방식이 자주 사용된다. Access Token은 짧은 시간만 유효하도록 만들고, Refresh Token으로 재발급을 처리한다. 토큰 탈취 위험을 줄이기 위한 구조다.
- localStorage 저장은 구현이 단순하지만 XSS 공격 위험이 존재한다.
- HttpOnly Cookie는 자바스크립트 접근을 차단해 상대적으로 안전하다.
- 보안 요구 수준이 높은 서비스일수록 Cookie 기반 인증 구조를 선호하는 경우가 많다.
다만 JWT가 항상 정답은 아니다. 로그아웃 처리나 강제 세션 만료 같은 기능은 오히려 복잡해질 수 있다. 실제 금융 시스템이나 관리자 서비스에서는 여전히 세션 기반 인증을 사용하는 경우도 많다.
OAuth는 비밀번호를 넘기지 않고 권한을 위임하는 방식
OAuth는 인증 시스템이라기보다 권한 위임 프레임워크에 가깝다. 외부 서비스 계정을 안전하게 활용하기 위한 구조라고 보는 편이 정확하다.
대표적인 예가 “구글 계정으로 로그인” 기능이다. 사용자는 직접 구글 로그인 화면에서 인증을 수행하고, 서비스는 인증 결과만 전달받는다. 비밀번호를 직접 저장하거나 처리하지 않아도 되기 때문에 보안 부담이 크게 줄어든다.
OAuth 구조에서는 Access Token이 핵심 역할을 한다. 서비스는 이 토큰을 이용해 외부 API 접근 권한을 확인한다. 예를 들어 프로필 조회, 이메일 읽기, 캘린더 접근 같은 권한 범위를 제한할 수 있다.
최근 서비스들이 “프로필 정보만 동의”, “메일 읽기 권한 허용” 같은 화면을 보여주는 이유도 OAuth의 Scope 구조 때문이다. 사용자는 허용 범위를 직접 선택할 수 있다.
실무에서는 OAuth와 OpenID Connect를 함께 사용하는 경우가 많다. OAuth 자체는 권한 위임 중심이라 사용자 식별 정보가 충분하지 않을 수 있기 때문이다. OpenID Connect는 사용자 인증 계층을 추가해 로그인 기능 구현을 쉽게 만든다.
실제 소셜 로그인 프로젝트에서는 Redirect URI 설정 실수가 자주 발생한다. 검증이 제대로 이루어지지 않으면 공격자가 피싱 페이지로 사용자를 유도할 수도 있다. OAuth는 편리하지만 설정 실수 하나가 큰 취약점으로 이어질 수 있는 구조이기도 하다.
현재 대부분의 소셜 로그인 서비스는 OAuth 2.0과 OpenID Connect 기반으로 동작한다. 구글, 애플, 네이버, 카카오 모두 유사한 구조를 사용한다.
SSL/TLS, JWT, OAuth는 경쟁 관계가 아니라 함께 쓰인다
실제 서비스에서는 이 세 기술이 하나의 흐름 안에서 동시에 동작한다.
- 사용자가 카카오 로그인 버튼을 누른다.
- OAuth 인증 절차가 진행된다.
- 서버가 사용자 정보를 확인한다.
- 자체 JWT를 발급한다.
- 이후 API 요청마다 JWT를 검증한다.
- 전체 통신은 HTTPS(TLS) 위에서 보호된다.
만약 TLS가 적용되지 않았다면 네트워크 중간에서 토큰 탈취가 발생할 수 있다. OAuth 설정이 잘못되면 공격자가 인증 흐름을 가로챌 수도 있다. JWT 만료 시간이 지나치게 길다면 탈취된 토큰이 장기간 악용될 가능성도 커진다.
실제 보안 사고 상당수는 기술 자체보다 역할 혼동이나 운영 설정 실수에서 발생한다. 인증 기술은 단독으로 안전해지는 것이 아니라 여러 계층이 함께 맞물려야 효과가 나온다.
최근에는 Zero Trust 보안 구조가 확산되면서 단순 로그인 여부보다 토큰 검증, 세션 만료, 디바이스 신뢰성 검증까지 함께 관리하는 방향으로 발전하고 있다.
입문자가 가장 자주 하는 보안 오해 정리
HTTPS를 적용했다고 해서 인증 구조 전체가 안전해지는 것은 아니다. TLS는 통신 구간을 보호할 뿐 사용자 권한 자체를 관리하지는 않는다.
JWT를 암호화 기술이라고 오해하는 경우도 많다. JWT는 기본적으로 인코딩 구조이며 Payload 내용을 누구나 확인할 수 있다. 민감 정보를 직접 저장하면 오히려 보안 문제가 커질 수 있다.
OAuth를 “로그인 기능 자체”로 이해하는 것도 흔한 착각이다. 정확히는 외부 권한 위임 구조에 가깝다. 실제 로그인 기능은 OpenID Connect 같은 추가 계층과 함께 구현된다.
“JWT가 세션보다 무조건 최신”이라는 생각 역시 단순화된 접근이다. 서비스 규모와 보안 정책에 따라 세션 방식이 훨씬 안정적일 수도 있다.
결국 중요한 것은 기술 이름이 아니라 데이터 흐름이다. TLS는 통신을 보호하고, JWT는 로그인 상태를 유지하며, OAuth는 외부 권한 위임을 처리한다. 역할을 분리해서 이해하면 인증 아키텍처 전체 구조가 훨씬 명확하게 보이기 시작한다.
보안 기술은 하나의 만능 솔루션으로 해결되지 않는다. 실제 서비스는 여러 계층의 기술이 서로 보완하는 형태로 동작한다. SSL/TLS, JWT, OAuth를 함께 이해해야 하는 이유도 바로 여기에 있다.