네트워크에서는 요청, 응답 사이에 시스템이 연결되어있다는 것을 증명할 장치가 있어야 연결이 유지되었다고 할 수 있다. 만약 연결을 위한 정보가 없다면?
통신의 연속성이 없다.
- 연결 정보는 연결이 되어 있고, 연결한 사용자가 누구인지에 대한 정보가 들어있다.
- 이러한 정보가 없다면, 통신하고 있는 주체가 누구인지, 언제부터 통신했는지 알 수 없다.
- 연결 정보가 없다면, 현재 인터넷에서 우리가 사용하는 것과 같은
연속적인 통신이 어렵다.
연결을 수시로 진행한다면, 서버에 부담이 발생한다.
- 연결이 연속적이지 않다고 하여 계속 다시 연결을 시도한다면, 서버에 불필요한 연산작업이 늘어나게 된다.
- 이는 서버의 성능 저하로 연결되며, 통신 장애로 이어질 수 있다.
쿠키, 세션, 토큰이 사용되는 이유?
→쿠키, 세션, 토큰 모두 웹 어플리케이션에서 사용자 인증 및 상태 유지를 위해 사용
웹 어플리케이션은 클라이언트↔서버 간의 상호작용을 통해 동작
이때 사용자의 로그인 상태, 세션 정보, 권한 등의 정보를 저장하고 유지하는 것이 필요
이를 위해 쿠키, 세션, 토큰 등의 방법이 사용되며, 이들을 사용하여 사용자의 인증 및 상태 유지를 쉽게 할 수 있음
정보 저장 위치
- 쿠키: 브라우저 측(클라이언트), 다시 웹사이트 접속 시 상태유지 가능
- 세션: 서버 측(보안성 우수)
- 토큰: JWT 형태로 사용, 클라이언트 측, 클라이언트→서버로 인증 정보를 전송시에 사용
🫓쿠키
쿠키는 서버에서 클라이언트(보통 웹 브라우저)에게 정보를 저장하기 위해 사용하는 작은 파일
HTTP 프로토콜을 사용하는 인터넷 사용자가 어떠한 웹사이트에 방문할 경우, 사용자와 서버 사이의 연결을 확인하기 위한 정보이며 이 정보를 통해 서버는사용자가 누구인지 특정할 수 있다.
쿠키는 특정한 정보일뿐, 프로그램 X, 따라서 컴퓨터 내에서 프로그램처럼 실행될 수 없으며, 바이러스를 옮길수도, 악성코드를 설치할 수도 X
클라이언트 측에 쿠키가 저장되는 과정
- 사용자가 서버에 연결 요청을 보낸다.
- 서버는 이때 쿠키(Cookie)를 생성한다.
- 그리고 쿠키와 함께 연결 응답 정보를 전송한다.
- 사용자는 다음에 연결을 수행할 때 쿠키와 함께 데이터를 요청한다.
- 서버는 이때 쿠키를 확인하고 사용자가 누구인지 확인한 후 그에 따른 응답을 하게 된다.
자주 방문한 사이트에
ID, PW가 자동입력되어 있거나, 팝업창에서 “오늘은 다시 보지 않기”를 클릭하는 것 등모두 쿠키를 활용한 사례
→ 첫 방문 시점에 저장해두고, 이후 동일 사이트 방문시
서버는 쿠키 정보를 바탕으로
ID, PW가 입력된 사이트, 팝업창이 생략된 사이트를 보여주는 것
클라이언트 측에서 쿠키의 이름, 값, 만료 날짜 등의 정보를 저장
대게 특정 웹사이트에서만 유효하며, 만료 날짜가 지나면 자동으로 삭제
👏쿠키의 장점
- 사용자 경험 개선: 쿠키를 이용하면 사용자의 로그인 정보, 화면 설정 등을 저장해 놓고, 사용자가 다시 방문했을 때 이전 상태를 바로 유지할 수 있다. 이로 인해 사용자는 웹사이트를 보다 편리하게 이용할 수 있다.
- 성능 개선: 서버에서 클라이언트에게 정보를 전달하는 것보다 쿠키를 이용하여 정보를 저장하는 것이 더 빠르다. 이로 인해 웹페이지 로딩 시간이 단축되어 사용자의 경험이 개선될 수 있다.
👎쿠키의 단점
- 보안 문제: 쿠키에 저장된 정보가 탈취되면 사용자의 개인정보가 노출될 수 있다. 따라서 중요한 정보는 쿠키에 저장하지 않는 것이 좋다.
- 크로스 사이트 스크립팅(Cross-site scripting, XSS) 공격에 취약: 악의적인 사용자가 쿠키의 값을 변경하여 공격할 수 있다. 이를 방지하기 위해 쿠키를 사용할 때는 쿠키 값의 유효성을 검증하고, XSS 방어 기능을 활용해야 한다.
- 용량 제한: 쿠키에 저장할 수 있는 정보의 양에는 제한이 있습니다. 이를 넘으면 쿠키가 작동하지 않을 수 있습니다.
쿠키의 취약성🤮
- 사용자(Client) A ~ C가 서버와 통신을 하고, 이로인해 서버에는 A,B,C의 쿠키 정보가 저장되어 있다.
- 쿠키에는 사용자의 민감한 정보가 들어 있다.
- 이러한 쿠키의 구조를 알았을 경우, 사용자는 다른 사용자의 정보를 추측하여 자신의 쿠키 정보를 변조할 수 있다.
- 공격을 수행할(요청을 보낼) 때, 변경된 쿠키를 입력하여 패킷을 전송한다.
- 패킷을 전송받은 서버는, 악의적인 사용자를 정상적인 사용자일 것으로 판단하여, 요청한 정보를 응답한다.
사용자가 악의적인 목적으로 쿠키값을 변조한다면 다른 사용자로 둔갑하여 정보를 요청할 수 있다. 때문에 쿠키값을 통해서 민감한 정보나 사용자 구별 정보를 삽입해두면, 보다 쉽게 공격이 가능해진다.
- 즉, 연결 지속성을 가지고 있는 정보를
사용자의 쿠키 값에 오롯이 의지하여 통신을 수행할 경우, 공격에 쉽게 노출될 가능성이 매우 높다.이를 보완하기 위한 개념으로 Session이라는 개념이 생겨났다.
🌐세션
세션(Session)이란 HTTP 프로토콜을 사용하는 인터넷 사용자가 어떤 웹사이트를 방문할 경우, 사용자와 서버 사이의 연결을 확인하기 위한 정보
세션은 서버 내부에 저장되며,
저장된 값은 반영구적이며, 사용자가 특정 시간동안 사용되지 않을 경우 폐기될 수 있는 정보이다.세션은 쿠키와 마찬가지로 연결 지향 통신을 수행하는데에 기초적인 요구사항이다.
사용자(Client)가 세션을 생성하고 이를 이용한 통신 과정
- 사용자가 서버에 연결 요청을 보낸다.
- 서버는 이때 세션(Session)ID를 생성 및 저장한다
- 그리고 이러한 세션 정보를 쿠키에 입력하여, 함께 연결 응답 정보를 전송한다.
- 사용자는 다음에 연결을 수행할 때 쿠키와 함께 데이터를 요청한다.
- 서버는 이때 쿠키를 확인하고, 쿠키에 입력된 세션정보를 통해 사용자가 누구인지 확인한 후 응답을 하게된다.
👏세션의 장점
- 높은 보안성: 세션은 서버에서 관리되므로 클라이언트가 세션 데이터를 직접 조작할 수 없다. 또한, 세션 ID를 이용하여 서버가 클라이언트를 식별하기 때문에, 사용자의 정보를 안전하게 유지할 수 있다.
- 많은 양의 데이터를 저장: 쿠키는 보통 작은 크기의 데이터만 저장할 수 있다. 하지만 세션은 서버에서 관리되므로 많은 양의 데이터를 저장할 수 있다.
- 정보를 안전하게 보호: 세션은 클라이언트의 브라우저에 저장되는 쿠키와 달리, 서버에서 관리되므로 정보가 안전하게 보호된다.
👎세션의 단점
- 서버 자원을 많이 소모: 세션은 서버에서 유지되므로, 사용자가 많아질수록 서버 자원을 많이 사용하게 된다.
- 별도의 메모리 공간 필요: 세션 데이터를 저장하기 위해서는 서버 측에서 별도의 메모리 공간이 필요하다. 이는 성능에 영향을 미칠 수 있다.
- 서버에 과부하: 서버에 과부하가 걸릴 경우, 세션 정보를 유지하기 어렵게 된다. 이 경우, 세션이 종료되어 사용자가 다시 로그인해야 하는 경우가 발생할 수 있다.
세션 탈취🤮
사용자의 PC가 감염될 경우, 서버가 감염될 경우, 사용자의 정보를 서버의 취약점을 통해 가져올 수 있을 경우 등이 있다. 탈취되는 정보는 아직
활성화 되어 있는 세션 정보다.사용자가 정상적으로 로그인을 한 정보가 아직 유지돼 있을 경우, 해당 세션의 정보로 변조가 가능할 시, 정상 사용자로 둔갑할 수 있다.
🟢토큰(ft. JWT)
토큰을 왜 사용할까?
대표적인 비연결 지향 프로토콜인 HTTP의 특성때문에, 한번의 요청-응답 사이클이 완료되면 연결이 종료되어 동일한 클라이언트가 요청을 아무리 많이해도 프로토콜은 모두 처음보는것 마냥 인지 → STATELESS
- STATEFUL(상태유지) 해지기 위해 위의
세션, 쿠키와 같은 많은 시도가 있었지만 이는 인증에 필요한 유저 정보를 서버 OR DB에 저장하기에 서버, DB의 부담 증가
- CORS 문제도 존재, 웹 어플리케이션에서 세션 관리시 자주 사용되는 쿠키는 도메인 및 서브 도메인에서만 작동하도록 설계, 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거로움
그러나 토큰 기반 인증 시스템은 STATELESS(무상태)
즉, 상태유지를 하지않는다. 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않아
서버의 부담이 감소하고 보안성도 높고, 여러 플랫폼 및 도메인에서 적용 가능하다는 장점이 있다.
대표적인 토큰 기반 인증 시스템인 JWT는 웹 표준으로서 많이 사용
⭐JWT(JSON Web Token)⭐
유저를 인증하고 식별하기 위한 토큰 기반 인증
클라이언트 측에 저장되어, 메모리나 스토리지 등을 통해 세션을 관리했던 서버의 부담 감소
핵심적인 특징:
토큰 자체에 사용자의 권한 정보나 서비스를 사용하기 위한 정보를 포함JWT는 서명된 토큰: 공개/개인 키를 쌍으로 사용하여 토큰에 서명할 경우 서명된 토큰은 개인 키를 보유한 서버가 이 서명된 토큰이 정상적인 토큰인지 인증할 수 있다.
JWT를 클라이언트에 저장하고 요청시 단순히 HTTP 헤더에 토큰을 첨부하는 것만으로 데이터를 요청하고 응답을 받아올 수 있다.
세션기반인증 & 토큰기반인증 비교
토큰 기반 인증과정
- 사용자가 로그인을 한다.
- 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣습니다.
- JWT 토큰의 유효기간을 설정합니다.
- 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급합니다.
- 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
- 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인합니다.
- 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옵니다.
#암호화된 토큰의 예시
JWT는 기본적으로 header, payload, signature로 구성된다.
1. header
토큰 타입(JWT 고정값), 해싱 알고리즘(토큰 검증시 사용되는 signature에서 사용, HS256..)
2. payload(내용)
토큰명, 발급자, 만료시간, 고유식별자 등등에 대한 정보 (Claim이라고 한다)Base64
3. signature(서명)
Header와 Payload의 데이터 무결성과 변조 방지를 위한 서명헤더의 인코딩값 + 정보의 인코딩값 => 비밀키로 해쉬 생성=> 즉
서버만 알고 있다. (비밀키를 통해 해킹 방지)서명 값과 계산값이 일치하고 유효기간이 지나지 않았다면 OK
Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화되지 않는다.
따라서 JWT 토큰에서 Header, Payload는 누구나 디코딩하여 확인할 수 있고
여기서 누구나 디코딩할 수 있다는 말은 Payload에는 유저의 중요한 정보(비밀번호)가 들어가면 쉽게 노출될 수 있다는 말이 된다.
하지만, Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다.
예시 설명
A 사용자가 토큰을 조작하여 B 사용자의 데이터를 훔쳐보고 싶다고 가정한다. 그래서 payload에 있던 A의 ID를 B의 ID로 바꿔서 다시 인코딩한 후 토큰을 서버로 보냈다. 그러면 서버는 처음에 암호화된 Verify Signature를 검사하게 된다. 여기서 Payload는 B사용자의 정보가 들어가 있으나 Verify Signature는 A의 Payload를 기반으로 암호화되었기 때문에 유효하지 않는 토큰으로 간주하게 된다. 여기서 A사용자는 SECRET KEY를 알지 못하는 이상 토큰을 조작할 수 없다는 걸 확인할 수 있다.
웹 브라우저의 성능향상, 사용성 증대를 위해 다양한 디바이스 클라이언트들을 하나의 백엔드 API로 대응하기 위한 REST 아키텍쳐가 사용되는 상황
REST 아키텍쳐는 무상태성(STATELESS)의 구현을 위해 클라이언트 쪽에 토큰이 저장되는 토큰 기반인증이 많이 쓰이게 되었다.
👏토큰의 장점
- 간편: 세션/쿠키는 별도의 저장소 관리가 필요하지만 JWT는 발급 후 검증만 하면 되기때문에 추가 저장소가 필요없다. 이는 STATELESS한 서버를 만드는데에 큰 강점이 있다. 서버를 확장하거나 유지, 보수하는데에 유리하다.
- 그냥 세션/쿠키의 단점을 거의 커버쳐준다~
👎토큰의 단점
- 서버의 부하: 토큰 기반 인증은 매 요청마다 토큰을 검증해야 하기 때문에, 서버의 부하가 발생할 수 있다.
- 토큰 크기의 한계: 토큰의 정보가 많을수록 토큰의 크기가 커지게 되어, 전송 속도가 느려질 수 있다. 이 때문에 필요한 정보만 담는 것이 중요하다.
- 토큰 만료 시간 관리: 토큰은 만료 시간이 있기 때문에, 이를 관리하는 추가적인 작업이 필요하다. 만료 시간이 지난 토큰은 다시 발급해야 하기 때문이다.
백엔드 개발 진행 시 JWT를 사용하게 될것이므로 토큰에 대해 잘 이해해야 함.
Share article
