쿠키, 세션, JWT

HTTP의 특징 중 다음 두 가지의 특징이 있다.

• Connectionless : 클라이언트와 서버는 요청과 응답을 하고 나면 연결이 끊긴다.
• Stateless : 연결이 끊기고 나면 상태는 유지되지 않는다.

예를 들어 메인페이지에서 로그인을 하고 다른 페이지로 가면 상태가 없기 때문에 다시 로그인을 해야한다.
하지만 우린 한 번 로그인하면 일정 시간동안 로그인이 계속 유지된다. 이런 걸 어떻게 한걸까?
=> 쿠키, 세션, JWT를 통해 사용자 인증에 대한 정보를 유지하는 것!

세션

• 서버에 저장 : 보안성 높음. 브라우저 종료 시 삭제. 서버 공간 차지

<동작과정>

1. 클라이언트가 서버에게 로그인 요청.
2. 서버는 DB에서 사용자를 확인한 후 세션 저장소에 저장을 하고 이 요청에 대한 세션ID를 발급. 세션ID와 함께 클라이언트에 응답.
3. 클라이언트는 세션ID를 쿠키(세션 쿠키)로 저장.
4. 클라이언트는 헤더에 세션 쿠키를 포함시켜 요청을 함.
5. 서버는 세션 저장소에서 쿠키를 검증하고 대응하는 정보를 가져옴.
6. 인증이 완료되고 서버는 응답해줌.

쿠키

• 클라이언트에 저장 : 보안성 낮음. 유효기간 설정하여 그 기간동안 보존.

<동작과정>

1. 클라이언트 서버에 요청.
2. 쿠키가 없으므로 서버에서 통신 상태를 저장한 쿠키 생성하고 헤더에 쿠키를 포함하여 응답함.
3. 클라이언트에서 쿠키를 보관
4. 동일 사이트를 이용할 때마다, 클라이언트는 정보(로그인 유지 등)들이 담긴 쿠키와 함께 서버에 요청

JWT(Json Web Token)

• 인증에 필요한 정보들을 암호화시킨 토큰

<구성>

• Header : 정보를 암호화할 방식(alg), 타입(type)
• Payload : 서버에서 보낼 데이터, 유저의 고유ID값, 유효기간
• Verify Signature : 인코딩한 Header, Payload. SECRET KEY

<동작과정>

1. 사용자 로그인(클라이언트 요청)
2. 서버에서 사용자 확인 후, 부여한 유저의 고유ID값, 보낼 데이터, JWT토큰의 유효기간을 Payload에 넣음.
3. 암호화할 SECRET KEY를 이용해서 JWT를 발급
4. 클라이언트는 JWT를 저장, 인증이 필요한 요청마다 JWT를 헤더에 실어 요청
5. 서버에서 검증하고, Payload를 디코딩하여 유저의 ID에 맞는 데이터를 응답.

<장단점>

• 장점 : 발급한 후 검증만 받으면 되기 때문에 간편하다. 확장성 뛰어남. ex) Facebook 로그인, Google 로그인 등은 토큰을 통한 인증방식.
• 단점 : Payload 정보가 제한적. Payload는 암호화되지 않기때문에 유저의 중요한 정보를 넣을 수 없음.