왜 등장했을까?
-
HTTP 통신은 요청(Request) → 응답(Response)이 종료되면 연결을 끊어버림
- Connectionless(비연결성): 클라이언트가 서버에 요청을 했을 때, 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식
- Stateless(무상태성): 클라이언트의 상태 정보를 가지지 않는 서버 처리방식
(클라이언트와 첫 번째 통신에 데이터를 주고 받았다 해도, 두 번째 통신에 이전 데이터를 유지하지 않음)
- 이를 보완하기 위해 쿠키, 세션, 토큰의 인증 방식을 사용
쿠키(Cookie)
- 공개 가능한 정보를 사용자의 브라우저에 저장
- 보안에 취약함(개인정보를 HTTP로 주고 받는 것은 위험)
캐시(Cache)
- 자주 사용하는 데이터를 미리 복사해두는 임의의 장소
- 데이터나 값을 미리 복사해 놓음으로써 빠르게 데이터에 접근 가능
세션(Session)
- 클라이언트에 대해 유일한 값(세션 id)를 부여, 세션 스토리지에 세션 정보를 저장
- 인증정보를 서버에 저장(사용자가 많다면 서버에 부하)
토큰(Token)
JWT(JSON Web Token)
- 인증에 필요한 정보들을 암호화시킨 토큰
- 쿠키/세션 방식과 유사하게 JWT(Access Token)를 HTTP 헤더에 실어 서버가 클라이언트를 식별
구조: Header.payload.signature(. 으로 구분)
- Header: JWT를 어떻게 검증(verify)하는가에 대한 내용
- payload: JWT의 내용(client id 및 유효기간 등)
- signature: 암호화된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성
장점
- header와 payload로 signaure를 생성하므로 데이터 위변조를 막을 수 있음
- 별도의 저장소가 필요없음(서버 부하 ↓)
- 토큰은 한 번 발급되면 유효기간이 만료 시까지 계속 사용 가능
단점
- 토큰의 길이가 길어 인증 요청이 많아질수록, 네트워크 부하가 심해짐
- payload 자제는 암호화되지 않기에 중요한 정보를 담으면 안됨
- 토큰이 유출되면 대처하기 어려움
- 특정 사용자의 접속을 강제로 만료하기 어려움
해결방안
- 짧은 만료기한 설정: 만료기한을 짧게 설정해서 유출될 위험을 줄임
- Refresh Token: 클라이언트가 로그인할 때 Access Token 및 Refresh Token을 발급
- Sliding Session: 클라이언트에게 자동으로 토큰 만료 기한을 늘려줌