『한 권으로 읽는 컴퓨터 구조와 프로그래밍』 12~13장
1️⃣ JWT, OAuth, Session – 인증 방식 전쟁의 서막
🧭 들어가며 – 왜 인증 방식을 이해해야 할까?
현대 웹 서비스에서 가장 중요한 질문 중 하나는 이것이다.
"당신은 누구십니까?"
이 질문에 시스템이 스스로 답할 수 없다면? 해커가 누구든지 '관리자'라고 주장할 수 있고, 다른 사용자의 정보를 마구 탈취해 갈 수도 있다.
그래서 우리는 인증(Authentication)을 한다. 하지만 이 인증의 방식은 여러 갈래로 진화해 왔고, 오늘날 대표적으로 사용되는 방법이 바로 이 세 가지다:
세션 기반 인증 (Session)
토큰 기반 인증 (JWT)
권한 위임 인증 (OAuth)
지금부터 이 세 방식이 왜 등장했고, 어떻게 다르고, 무엇을 해결하려 했는지를 차근차근 풀어본다.
1. 📌 Session – 가장 오래된 믿음직한 친구
🧾 1) 어떻게 동작할까?
세션은 서버가 ‘너 누구야?’라는 질문에 직접 답을 기억해주는 방식이다.
사용자가 로그인하면 서버가 사용자에게 고유한 세션 ID를 발급한다.
이 세션 ID는 사용자의 브라우저 쿠키에 저장된다.
이후 요청마다 브라우저가 쿠키에 담긴 세션 ID를 서버에 보낸다.
서버는 그 ID를 보고 ‘아 이 사용자구나’라고 식별한다.
즉, 상태 정보(Session State)는 서버가 보관한다.
💡 2) 장점과 단점
서버가 모든 인증 상태를 직접 관리하므로 보안적으로 안정적
서버 메모리에 세션 정보가 저장되므로 확장성(Scale-out)이 어려움
클라이언트는 세션 ID만 관리하면 되므로 구현이 단순
서버가 죽으면 세션 정보도 날아감 – 영속성 부족
세션 하이재킹(탈취) 방지 등 다양한 보안 수단 연계 가능
모바일, API 기반 통신에는 적합하지 않음
2. 📌 JWT – 무상태(stateless)의 역습
세션 방식은 서버가 모든 걸 기억한다. 하지만 시스템이 커지고, 서버가 여러 대로 늘어나면 문제가 생긴다. 그래서 등장한 방식이 『한 권으로 읽는 컴퓨터 구조와 프로그래밍』 12~13이다.
🧾 1) 어떻게 동작할까?
사용자가 로그인하면 서버는 인증 정보를 바탕으로 JWT 토큰을 만든다.
이 토큰은 Base64로 인코딩된 JSON + **서명(Signature)**으로 구성된다.
이 토큰을 클라이언트가 저장하고, 이후 요청마다
Authorization: Bearer <토큰>형태로 보낸다.서버는 토큰을 복호화하고 서명 검증을 통해 유효성을 판단한다.
중요한 차이: JWT는 인증 정보를 서버가 ‘기억’하는 게 아니라 토큰 자체에 담아서 보낸다.
🧠 JWT 구조
[헤더].[페이로드].[서명]Header: 토큰 타입, 해싱 알고리즘
Payload: 사용자 정보 (예: id, role, 만료 시간 등)
Signature: 비밀키로 서명한 부분 → 위조 방지
💡 2) 장점과 단점
서버가 인증 상태를 저장하지 않으므로 수평 확장에 강함
클라이언트에 모든 정보가 담기므로 탈취되면 큰일
API 서버, 모바일 등 다양한 플랫폼과 잘 맞음
토큰 자체가 무거움 (모든 정보 내장)
특정 기간 동안만 유효 → 자동 로그아웃 구현 쉬움
만료 이전에는 강제 로그아웃 불가 (서버가 상태를 기억 안 하므로)
3. 📌 OAuth – ‘나 말고 저 사람에게 맡길게요’
🧾 1) 어떤 상황에서 등장했을까?
내 서비스에서 ‘구글로 로그인’, ‘카카오로 로그인’ 같은 걸 본 적 있지?
이건 ‘인증’을 제3자에게 위임하는 구조다.
OAuth는 권한 위임(Authorization Delegation)을 위한 프레임워크다.
서드파티 앱(예: 내 웹사이트)이 자원 소유자(예: 구글 사용자)의 권한을 받아, 구글 API에 접근할 수 있게 한다.
💬 비유로 이해해보자
“카카오톡에서 내 친구 목록을 보여주는 기능을 쓰고 싶어.”
→ 그런데 나는 카카오톡 비밀번호를 개발자에게 알려주기 싫어. → 그래서 카카오톡에 “이 앱이 친구 목록만 보게 해줘”라고 요청해. → 카카오는 나를 인증하고, 이 앱에게 ‘친구 목록 조회만 가능한 토큰’을 발급해준다.
→ 이렇게 비밀번호를 넘기지 않고 권한만 위임하는 것이 바로 OAuth다.
🧠 OAuth 2.0의 핵심 흐름
사용자 → 인증 서버에서 로그인
인증 서버 → 사용자에게 인가 코드 발급
클라이언트 → 인가 코드로 엑세스 토큰 요청
클라이언트 → 이 토큰을 사용해 자원 서버(API) 호출
→ 토큰은 일정 시간 후 만료되며, 리프레시 토큰을 통해 갱신 가능
💡 2) 장점과 단점
비밀번호 노출 없이 인증 위임 가능
구현이 복잡하고 흐름이 길다
다양한 권한 범위 설정 가능 (scope)
리프레시 토큰 관리 등 보안 신경 써야 함
보안 강화 + 유연한 접근 제어
사용자 인증과 권한 위임 개념이 혼재될 수 있음
📊 세 방식 비교 요약
상태 관리 방식
서버가 저장
클라이언트가 저장
인증 위임 프레임워크
확장성
낮음
높음
높음
보안
안정적
토큰 탈취 위험 있음
제3자 인증 활용 가능
사용 예
일반 웹 로그인
API 인증, 모바일 앱
소셜 로그인, API 위임
로그아웃 처리
서버에서 세션 제거 가능
만료까지 유지됨
리프레시 토큰 관리 필요
🧩 실전에서는 어떻게 선택할까?
내부 서비스 or 단일 서버 → Session이 편하다
모바일 or REST API → JWT가 적합
외부 서비스와 연동 → OAuth를 써야 한다
그리고 때로는 혼합해서도 쓴다:
OAuth로 로그인 → JWT로 토큰 발급 → 클라이언트는 JWT로 인증 유지
✍️ 마무리하며
인증 방식은 단순한 기술 선택이 아니라, 서비스의 보안, 확장성, 사용자 경험을 좌우하는 전략이다. Session은 간단하지만 서버 의존적이고, JWT는 자유롭지만 보안 관리가 필요하며, OAuth는 권한 위임의 표준이다.
"당신이 누구인지를 증명하는 방식이 곧, 당신의 시스템이 어떤 존재인지를 결정한다."
2️⃣ 토큰의 진화 – Refresh Token과 Rotation 전략
🧭 들어가며 – "왜 로그인은 유지되어야 하는가?"
사용자가 로그인한 뒤 갑자기 로그아웃된다면 얼마나 불편할까요? 우리는 대부분 로그인한 상태가 몇 시간, 혹은 며칠간 유지되길 원합니다. 하지만 보안을 위해 토큰은 일정 시간 후에 반드시 만료되어야 하죠.
여기서 등장한 것이 바로 Refresh Token입니다.
1. 📌 Access Token vs Refresh Token
역할
실제 API 접근에 사용
새로운 Access Token을 발급받는 용도
수명
짧음 (보통 15분~1시간)
김 (보통 며칠~수주)
저장 위치
브라우저 메모리, 쿠키 등
서버 or HttpOnly 쿠키
위험 시 대응
만료됨 → 로그인 필요
서버에서 Refresh Token 폐기 가능
Access Token이 도어락의 "임시 비밀번호"라면, Refresh Token은 문 열쇠를 복사할 수 있는 본사 마스터 키에 해당합니다.
2. 📦 왜 Refresh Token이 필요한가?
😵💫 문제 상황
JWT는 "무상태"이기 때문에 서버는 사용자의 세션을 기억하지 않음
Access Token이 만료되면 로그인 정보를 기억하는 방법이 없음
→ 이때 Refresh Token이 있으면 다시 로그인하지 않고도 새로운 토큰을 재발급받을 수 있음
3. 🔁 Refresh Token 재발급 흐름
[사용자 로그인]
↓
[Access Token + Refresh Token 발급]
↓
[시간이 지나 Access Token 만료]
↓
[클라이언트 → Refresh Token으로 토큰 재요청]
↓
[서버 → Access Token 재발급]이 과정을 통해 사용자는 끊김 없이 로그인 상태 유지가 가능해집니다.
4. 🔒 Refresh Token의 보안 문제
“그럼 Refresh Token만 탈취하면 무한 로그인 아닌가요?”
맞습니다. 그래서 Refresh Token은 꼭 안전하게 HttpOnly 쿠키에 저장해야 하고, 데이터베이스에 저장하여 탈취 시 폐기 가능하게 관리해야 합니다.
5. 🔄 Rotation 전략이란?
🤔 왜 Rotation이 필요한가?
일반적으로 Refresh Token은 다음과 같은 문제를 일으킬 수 있습니다.
탈취되면 장기간 악용될 수 있음
동일 토큰을 여러 번 재사용하면 위험
그래서 등장한 개념이 Refresh Token Rotation입니다.
🔁 Rotation 방식이란?
Refresh Token을 사용할 때마다 새로운 Refresh Token을 함께 발급하고, 이전 토큰은 서버에서 즉시 폐기하는 전략입니다.
✅ 예시 흐름
로그인 시: 서버 → Access + Refresh 발급 → 클라이언트 저장
Access Token 만료: 클라이언트 → 이전 Refresh Token 제출
서버 → 새 Access + 새 Refresh 발급
이전 Refresh Token은 서버에서 폐기
클라이언트 → 새 Refresh Token으로 교체
💥 탈취 탐지 가능!
이전 토큰으로 다시 요청이 들어오면 → 탈취로 판단 가능
→ 계정 차단 or 경고 가능
6. 🧠 구현 팁 & 고려사항
🔐 저장 위치는?
Access Token: LocalStorage or Memory
Refresh Token: HttpOnly + Secure 쿠키
🕵️ 서버 관리
Refresh Token은 반드시 서버에서 DB 등으로 관리해야 함
토큰에는 사용자 ID, 만료일, 토큰 고유 ID(jti) 등을 포함해야 함
💣 위험 관리
Refresh Token 탈취
HttpOnly + Rotation
Access Token 탈취
짧은 수명, 암호화
토큰 재사용 공격
Rotation + 이전 토큰 폐기
📊 정리 요약
Refresh Token 도입 이유
짧은 Access Token 만료 시 재로그인 없이 연장 가능
저장 방식
HttpOnly 쿠키, DB 관리
Rotation 전략
매 요청마다 Refresh Token 갱신 + 이전 토큰 무효화
보안 효과
탈취 탐지 가능 + 재사용 방지
위험 요소
Refresh Token 자체가 위험하므로 항상 서버-클라이언트 양쪽 보안 필요
🧩 마무리하며
“토큰을 오래 유지하고 싶지만, 보안은 포기할 수 없다!”
이 욕망 사이에서 균형을 잡아주는 것이 Refresh Token과 Rotation 전략입니다. 한 번의 로그인으로 오랫동안, 하지만 안전하게 사용자를 유지하기 위한 오늘날의 필수 구조죠.
3️⃣ 스테가노그래피와 크립토그래피 – 숨기는 것과 뒤섞는 것의 기술
🧭 들어가며 – “숨길 것인가, 뒤섞을 것인가?”
우리가 누군가에게 메시지를 보내면서 가장 두려운 것은 무엇일까요? 바로 그 내용이 제3자에게 보이거나 조작되는 것입니다.
이를 막기 위해 인류는 오래전부터 ‘정보 은닉 기술’을 발전시켜 왔고, 그 결과 두 가지 대표 기술이 등장했습니다.
크립토그래피(Cryptography): 메시지를 뒤섞어서 못 알아보게 하는 기술
스테가노그래피(Steganography): 메시지를 숨겨서 존재 자체를 모르게 하는 기술
1. 🔐 크립토그래피 – 정보를 뒤섞어 보이지 않게 만들기
핵심 질문: "정보가 보이더라도, 이해하지 못하게 만들 수 있을까?"
🔹 정의
송신자가 데이터를 암호화하여, 정해진 수신자만 내용을 해독할 수 있게 만드는 기술
🔹 주요 기능
기밀성
제3자가 내용을 알 수 없음
무결성
중간에서 내용이 바뀌었는지 확인 가능
인증
송신자가 누구인지 검증 가능
부인 방지
“내가 안 보냈다”는 변명이 통하지 않음
🔹 예시 기술
대칭키 암호 (AES 등)
공개키 암호 (RSA, ECC)
해시, 전자서명
💡 비유: 내용을 외우고 외운 사람만 알 수 있는 비밀 주문처럼 동작
2. 스테가노그래피 – 정보를 몰래 숨기기
핵심 질문: "정보의 존재조차 들키지 않게 할 수 있을까?"
🔹 정의
메시지를 다른 데이터 속에 몰래 감춰서, 존재 자체를 눈치채지 못하게 하는 기술
🔹 활용 방식
이미지 스테가노그래피
이미지의 픽셀 값 중 **최하위 비트(LSB)**에 메시지를 삽입
오디오/비디오 스테가노그래피
프레임이나 음파 중 일부에 비밀 정보 삽입
텍스트 스테가노그래피
공백, 특수 문자, 글자 간격 등에 정보 삽입
🔹 실제 사용 사례
스파이 활동, 영화 유출자 추적 (디지털 워터마크)
프린터의 노란 점 추적
광고 회사를 통한 웹 감시
💡 비유: 일반 그림 속에 보이지 않는 투명 메시지를 감춰 둔 것
3. 🎯 크립토그래피 vs 스테가노그래피 – 비교
목표
내용 보호
존재 은폐
탐지 난이도
보이지만 해독 어려움
아예 존재 자체를 모르게
활용 상황
보안 통신, 인증
비밀 통신, 감시 우회
보완 가능성
해독 시 정보 유출
탐지되면 즉시 정보 유출
✅ 현실에서는 이 둘을 조합해서 사용하는 것이 일반적입니다. 예) 메시지를 암호화한 뒤 → 이미지에 숨겨서 전달
4. 🧪 실제 예시 – 이미지 LSB 숨김 방식
원래 이미지 픽셀 (8비트 그레이스케일):
10110010
비밀 메시지 비트:
1
→ 삽입 후 픽셀:
10110011 (마지막 비트만 바뀜)
肉眼으로는 차이 없음!사람 눈은 LSB가 바뀐 것을 구분할 수 없기 때문에 정보 은폐에 매우 적합합니다.
5. ⚠️ 스테가노그래피의 위험성
최근 딥웹/다크웹에서 스테가노그래피를 악성코드 은닉에 활용하기도 함
텔레그램/이미지 서버 등을 통해 은닉된 공격 명령 전달 가능
프라이버시 침해와 감시에 악용된 사례도 존재
6. 🤖 크립토그래피의 윤리적 문제 – 누가 신뢰할 것인가?
일부 국가기관(NIST+NSA)은 암호 알고리즘에 의도적으로 백도어를 설치한 이력 있음
기업에서 자체 루트킷을 설치하거나, 하드코딩된 암호 키를 배포한 사건도 존재
👉 투명성의 중요성 대두: 오픈소스 암호 기술의 확산 "수천 개의 눈이 코드를 보면, 취약점은 사라진다"
🧩 마무리하며
정보 보호의 두 축은 “숨기는 것”과 “뒤섞는 것”입니다.
크립토그래피는 누가 봐도 알아볼 수 없게 만드는 것
스테가노그래피는 누가 봐도 정보가 있다는 걸 모르게 만드는 것
현대 보안 시스템은 이 두 기술을 적절히 혼합해 사용합니다. 정보가 진짜 중요한 시대일수록, 은폐와 암호화의 균형 감각이 핵심이 됩니다.
Last updated