1. 쿠키 (Cookie)
정의
- 쿠키는 웹 서버가 클라이언트(주로 브라우저)에 저장하도록 보내는 작은 텍스트 파일입니다.
- 클라이언트는 이후 같은 사이트에 접속할 때 쿠키 데이터를 함께 전송하여 서버가 사용자의 상태를 파악하도록 돕습니다.
주요 특징
- 저장 위치: 클라이언트(브라우저)의 로컬 저장소.
- 수명: 만료 시간(Expiration)을 지정할 수 있으며, 만료 시간이 지나면 자동으로 삭제됨. (세션 쿠키는 브라우저 종료 시 삭제됨)
- 보안: HTTPOnly, Secure, SameSite 등의 속성을 통해 보안 강화가 가능하지만, 기본적으로 클라이언트에 저장되므로 민감 정보를 저장하는 것은 권장되지 않음.
- 크기 제한: 개별 쿠키는 보통 몇 KB 크기로 제한되며, 브라우저마다 저장 가능한 쿠키 수에도 제한이 있음.
사용 사례
- 사용자 맞춤 설정: 언어 선택, 테마 등 사용자 선호 정보 저장.
- 세션 관리: 로그인 후 세션 ID를 쿠키에 저장하여 사용자를 식별.
- 광고 추적: 방문 기록이나 광고 노출 기록 등을 저장.
비유: "방문 기록 스티커"
- 설명:
웹사이트가 사용자의 컴퓨터(브라우저)에 작은 메모(쿠키)를 남기는 것과 같아요. 이 메모에는 사용자의 선호, 로그인 상태, 방문 기록 등이 담겨 있을 수 있습니다. - 비유 설명:
마치 동네 카페에 들어갈 때, 직원이 "지난번에 오셨던 분이네요. 저번에 좋아하셨던 커피는 XX였죠?"라고 기억하기 위해 손님에게 스티커를 붙여두는 것과 비슷합니다. 이 스티커(쿠키)는 카페(웹사이트)가 손님(사용자)에 대한 정보를 기억하게 도와줍니다.
2. 세션 (Session)
정의
- 세션은 서버 측에서 사용자와 관련된 정보를 저장하는 방법입니다.
- 사용자가 웹 사이트에 접속하면 서버는 고유한 세션 ID를 생성하고, 이 ID를 클라이언트(보통 쿠키에 저장)에 전달하여 사용자를 구분합니다.
- 이후 사용자가 요청을 보낼 때마다 세션 ID를 전달받아 서버는 해당 세션에 저장된 정보를 참조합니다.
주요 특징
- 저장 위치: 주로 서버 메모리나 데이터베이스 등 서버 측 저장소.
- 보안성: 중요한 사용자 데이터가 서버에 저장되므로 쿠키보다 보안성이 높습니다.
- 유효 기간: 일정 시간 동안 사용자가 활동하지 않으면 세션이 만료되어 삭제됩니다.
- 리소스 사용: 서버 메모리를 사용하기 때문에 동시에 많은 사용자가 접속하면 리소스 부담이 커질 수 있습니다.
사용 사례
- 로그인 상태 유지: 사용자가 로그인한 후, 서버에 세션 정보를 저장해 사용자의 인증 상태를 유지.
- 쇼핑 카트: 온라인 쇼핑몰에서 사용자의 장바구니 정보 저장.
- 사용자 맞춤 데이터: 사용자별로 임시 데이터를 서버에 저장.
비유: "호텔 예약 기록"
- 설명:
세션은 서버 측에서 사용자의 상태나 정보를 저장하는 공간이에요. 사용자가 웹사이트에 로그인하면, 서버는 해당 사용자의 세션을 생성하여 그 동안의 활동이나 상태를 관리합니다. - 비유 설명:
호텔에 예약을 하고 체크인을 하면, 호텔은 고객의 예약 정보와 숙박 기록을 자체 시스템에 저장합니다. 이 기록은 호텔 내부에서만 관리되고, 고객은 객실 열쇠(또는 키카드)를 받게 됩니다. 고객이 객실에 들어갈 때마다 호텔 시스템이 키카드 정보를 확인하여 고객의 신원을 확인하는 것처럼, 세션은 서버에서 사용자의 상태를 관리하며, 보통 쿠키를 통해 세션 ID를 클라이언트에 전달합니다.
3. 토큰 (Token)
정의
- 토큰은 사용자의 인증 및 권한 부여를 위해 사용되는 암호화된 문자열입니다.
- 서버는 사용자가 로그인하면 토큰을 생성하여 클라이언트에게 전달합니다.
- 클라이언트는 이후 요청 시 HTTP 헤더(예: Authorization 헤더)에 토큰을 포함하여 보냅니다.
주요 특징
- 저장 위치: 클라이언트 측(예: 로컬 스토리지, 세션 스토리지) 또는 쿠키에 저장할 수 있습니다.
- 무상태성(Stateless): 토큰 기반 인증은 서버가 별도의 세션 상태를 유지하지 않아도 되므로 확장성이 높습니다.
- 보안: JWT(JSON Web Token)와 같은 토큰은 서명 및 암호화를 통해 변조를 방지할 수 있습니다.
- 유효 기간: 토큰에는 만료 시간이 포함되며, 만료되면 새로운 토큰을 발급 받아야 합니다.
사용 사례
- REST API 인증: 토큰을 사용하여 API 요청 시 인증 및 권한 확인.
- 싱글 페이지 애플리케이션(SPA): 클라이언트에서 토큰을 저장하고 사용하여, 서버와의 통신 시 인증 정보를 전달.
- OAuth: 외부 서비스와의 인증 및 권한 위임을 위해 토큰 기반 인증을 사용.
비유: "멤버십 카드"
- 설명:
토큰 기반 인증은 사용자가 로그인 후 서버로부터 받은 암호화된 문자열(토큰)을 클라이언트에 저장하고, 이후 요청 시 이 토큰을 첨부하여 인증받는 방식입니다. 서버는 토큰을 검증해 사용자의 신원을 확인합니다. - 비유 설명:
마치 헬스클럽에 가입하면 멤버십 카드가 발급되는 것과 같아요. 이 카드에는 회원의 신분을 증명할 수 있는 정보가 담겨 있어, 클럽 입구에서 카드를 보여주면 "네, 회원이시군요!"라고 확인하는 과정을 거칩니다. 토큰은 이 멤버십 카드처럼 사용자가 누구인지를 증명하는 역할을 하며, 클라이언트와 서버가 주고받으며 인증을 진행합니다.
쿠키, 세션, 토큰 비교
특징 | 쿠키 | 세션 | 토큰 |
저장 위치 | 클라이언트(브라우저) | 서버(메모리, 데이터베이스 등) | 클라이언트(로컬 스토리지, 쿠키 등) |
보안 | 상대적으로 취약 (민감 정보 저장 X) | 서버에 저장되어 비교적 안전 | 암호화/서명되어 있어 안전 (JWT 등 사용) |
상태 | 상태 정보를 저장하여 클라이언트를 구분 | 서버가 상태 정보를 유지 (상태 기반) | 무상태(stateless): 서버가 상태를 유지하지 않음 |
유효 기간 | 만료 시간 설정 가능 (세션 쿠키: 브라우저 종료 시 삭제) | 일정 시간 후 만료, 서버 리소스 소모 | 만료 시간이 포함되어 있어 갱신 필요 |
용도 | 간단한 사용자 정보, 세션 ID 전달 등 | 로그인 상태 유지, 사용자별 임시 데이터 저장 등 | API 인증, 권한 부여, SPA 및 모바일 앱 등에서 주로 사용 |
결론
- 쿠키: 클라이언트에 데이터를 저장하여 사용자 상태를 식별. 간단한 정보와 세션 ID 전달에 적합.
- 세션: 서버에서 사용자 상태를 관리하여 보안성을 높이며, 로그인과 같은 기능에서 사용.
- 토큰: 무상태 인증 방식으로, 분산 시스템이나 RESTful API에서 사용자 인증과 권한 부여를 위한 안전한 방법을 제공합니다.
각 방식은 보안, 성능, 확장성 등 다양한 요구사항에 따라 적절히 선택되어 사용됩니다.
일반적으로 한 웹페이지나 애플리케이션에서는 하나의 주된 상태 관리 또는 인증 메커니즘을 선택해서 사용합니다. 다만, 실제 환경에서는 목적에 따라 두 가지 이상을 혼용하는 경우도 있습니다.
전통적인 웹 애플리케이션에서는 보통 서버가 세션을 관리하고, 클라이언트에는 세션 ID를 저장하기 위해 쿠키를 사용합니다.
→ 즉, 쿠키와 세션은 보완적인 관계로 함께 사용됩니다.
RESTful API 기반의 애플리케이션이나 SPA(Single Page Application)에서는 토큰(JWT 등) 기반 인증 방식을 사용하는 경우가 많습니다. 이 경우 토큰을 쿠키나 로컬 스토리지에 저장할 수 있지만, 주된 인증 방식은 토큰입니다.
따라서 한 웹페이지에서 쿠키, 세션, 토큰을 동시에 모두 사용하는 경우는 드물며, 보통 특정 목적(예: 인증, 상태 관리)에 맞게 하나 또는 두 개의 방식을 선택해 사용합니다.
네이버의 자동 로그인 기능은 토큰 기반 인증 방식을 사용합니다.
✅ 네이버 자동 로그인 방식
OAuth 2.0(인증을 위한 개방형 표준 프로토콜) 기반 인증
- 네이버는 OAuth 2.0을 사용하여 로그인 및 인증을 처리합니다.
- 사용자가 네이버 로그인을 하면 액세스 토큰(Access Token) 이 발급됩니다.
- 이후 API 호출 시 토큰을 사용하여 사용자 인증을 수행합니다.
- 리프레시 토큰(Refresh Token) 활용
- 액세스 토큰은 보안상 일정 시간이 지나면 만료됩니다.
- 자동 로그인을 유지하려면 리프레시 토큰을 사용하여 새로운 액세스 토큰을 발급받습니다.
- 즉, 네이버 자동 로그인은 리프레시 토큰을 활용한 토큰 갱신 방식을 사용합니다.
- 쿠키와 세션 활용 가능
- 웹 브라우저에서는 쿠키에 인증 정보를 저장하여 자동 로그인을 지원하기도 합니다.
- 하지만 보안 강화를 위해 주요 API 요청은 토큰 기반으로 처리됩니다.
✅ 결론
네이버 자동 로그인은 토큰 기반 인증(OAuth 2.0) 을 사용하며, 리프레시 토큰을 활용하여 자동 로그인을 유지하는 방식입니다. (토큰 방식의 인증 방식이 맞음).
'멋쟁이사자처럼_부트캠프 > Spring' 카테고리의 다른 글
[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 41일차 웹 프로그램 실습-1 (1) | 2025.02.07 |
---|---|
[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 40일차 스트림 (0) | 2025.02.06 |
Spring AOP 개념 심화 (1) | 2025.01.21 |
[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 32일차 Spring 2 (0) | 2025.01.20 |
[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 30일차 Spring (1) | 2025.01.16 |