[인증/인가] 쿠키, 세션, 토큰, JWT

개념정리

인증 (Authentication)

서비스를 이용하려는 유저가 등록된 회원인지 확인하는 것

 

인가 (Authorization)

인증을 받은 유저가 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 절차

 

HTTP의 관련 특성

1) 무상태 (stateless)

- HTTP 프로토콜은 무상태 프로토콜

- 각 요청이 독립적이며, 서버가 이전 요청에 대한 정보를 기억하지 않음 (이전에 인가된 요청이 왔는가? 모른다)

- 따라서 각 요청마다 상세 정보를 알려줘야 함

 

2) 비연결성 (connectionless)

- 서버와 클라이언트는 연결되어있지 않음

- 서버 입장에서는 매번 새로운 클라이언트의 요청을 받는 것

 

쿠키

- 브라우저에 저장되는 작은 데이터 조각, key-value 쌍으로 저장

- HTTP 무상태성과 비연결성 특성에도 불구하고, 쿠키를 사용해 서버가 클라이언트의 인증상태를 기억하는 것처럼 구현할 수 있음

- 쿠키는 별도로 삭제처리하거나, 유효기간이 만료되지 않는 한, 서버와 통신할 때 자동으로 주고받게 됨

- 서버에 HTTP 요청을 할 때마다 브라우저의 쿠키는 자동으로 서버에 보내짐

 

 

인증 방식

세션을 이용한 인증 방식

1) 세션

- 사용자와 서버 간의 연결이 활성화된 상태를 의미하는 개념 / 인증이 유지되고 있는 상태

- 로그인 성공시 서버에서 세션 생성 및 저장 (key-value)

- key(session ID)를 브라우저에서 응답 (by 쿠키)

 

2) 세션 인증 방식의 한계

- 확장성 문제

: 세션 정보는 서버의 메모리나 저장소에 저장되기 때문에, 서버가 많아질 수록 세션 동기화 문제 발생

여러 서버가 동일한 세션 정보를 공유해야 하므로 이를 관리하기 위한 추가적인 복잡성이 필요

서버가 많다면 어느 유저가 어느 서버로 로그인했는지 등을 별도로 기억해야하는 등 복잡해짐

 

- 메모리 사용량 증가

: 많은 사용자가 접속한 경우, 각 사용자의 세션 정보를 서버 메모리에 저장하는 방식은 메모리 사용량이 급증

이는 서버 성능 저하와 비용 증가를 초래할 수 있음 (서버가 메모리를 사용해 세션을 관리하는 경우)

 

- 상태 유지의 복잡성

: 세션은 서버에 상태를 저장하므로 서버가 무상태로 유지되기 어려움

RESTful 아키텍처의 원칙과 맞지 않음

 

- 보안문제

: 세션 ID가 탈취됐을 경우, 이를 통해 사용자의 세션을 가로채는 세션 하이재킹(Session Hijacking) 공격이 발생할 수 있음

 

이를 한계점들을 극복하기 위해 JWT(Json Web Token) 방식 등장

 

토큰을 이용한 인증 방식

1) 토큰

- 클라이언트에서 보관하는 암호화 또는 인코딩된 인증 정보

- 서버의 상태를 유지하지 않고도 클라이언트의 인증 상태를 확인할 수 있게 함

- 세션처럼 서버에서 인증 정보를 보관할 필요가 없어 서버 부담을 줄여줌

 

2) JWT

- 토큰 기반 인증 방식에서 사용되는 특별한 토큰

- Header: 어떤 종류의 토큰인지와 어떤 알고리즘으로 서명되었는지

- Payload: 실제로 중요한 데이터가 들어있는 부분 (사용자 ID 등)

- Verify signature: 서버만 알 수 있는 비밀키로 서명돼있음, 이 토큰이 위조되지 않았는지 확인하는 역할

 

3) JWT 특징

- 국제 인터넷 표준 인증 규격 중 하나

- 인코딩된 토큰을 누구나 복호화할 수 있으므로 중요한 정보를 추가하면 안됨