Notice
Recent Posts
Recent Comments
«   2025/02   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28
관리 메뉴

0strich

[Authentication] Cookie / Session 인증 본문

카테고리 없음

[Authentication] Cookie / Session 인증

0strich 2020. 4. 18. 22:33

프로젝트에 필요한 로그인, 회원가입 구현을 위해 인증에 대해 학습해 보자

이번 글에서는 클라이언트, 서버 간의 인증 방법들과 왜 이러한 인증이 필요한지에 대해서 알아볼 것이다.

HTTP 특징과 쿠키/세션을 사용하는 이유

쿠키/세션에 대해 알아보기 전에 어째서 사용하는지에 대해 알아보자

HTTP는 Connectionless, Stateless 한 특징이 있다. 이러한 특징이자 약점을 보완하기 위해 쿠키와 세션을 사용한다.

 

Connectionless : 요청 응답이 한번 이루어지면 연결을 끊음

Stateless : 통신이 끝나면 상태를 유지하지 않음

 

위와 같은 특징으로 인해 사용자가 로그인을 했음에도 불구하고 페이지를 이동할 때마다 로그인을 해야 하는 불편함이 생길 수 있다.

이러한 점을 보완하기 위해 쿠키와 세션을 사용하여 동일한 유저의 로그인 상태를 유지할 수 있다.

1. Cookie

로컬 스토리지에 저장되는 키와 값이 들어있는 텍스트 형태의 데이터

쿠키는 HTTP 헤더에 자동으로 넣어져서 발송된다.

쿠키 인증방식은 쿠키에 인증정보(ID, PW)를 넣어서 발송하는 방식이다.

페이지가 전환될 때마다 쿠키를 자동으로 헤더에 실어서 보내기 때문에 악의적인 의도를 가진 해커가 중간에서 헤더를 가로채게 된다면 인증정보가 그대로 노출되기 때문에 매우 취약한 인증방식이다.

실제 서비스에서는 사용하지 않는 방식이다. 간단한 인증 테스트에서만 사용하는 것이 좋다.

2. Session / Cookie

매번 인증정보를 헤더에 실어서 보내는 쿠키 인증 방식을 보완하기 위해 나온 인증방식이다.

 

세션 : 서버에 저장되는 데이터(사용자 인증정보)

쿠키 : 서버로부터 발급받은 세션 ID를 쿠키에 저장

성공적으로 인증이 이루어지는 순서는 다음과 같다.

 

클라이언트

* 로그인 시도

서버

* 계정 정보 확인

* 확인된 회원정보로 세션 저장소에 세션 생성

* 세션 ID 발급 후 응답

클라이언트

* 발급받은 세션 ID를 쿠키에 저장 후, 인증이 필요할 때마다 서버의 헤더에 쿠키를 실어서 요청

서버

* 쿠키에 저장된 세션 ID 가 검증이 되면 유저 정보 응답

 

장점

* 세션/쿠키 인증방식은 쿠키 인증방식과 다르게 세션 ID로 서버로부터 사용자 정보를 받아오는 것이기 때문에 

  쿠키를 탈취당하더라도 직접적으로 사용자 인증 정보가 유출되지 않음

* 각각의 사용자마다 세션 ID를 발급하기 때문에 요청이 들어올 때마다 일일이 회원정보를 조회하지 않아 됨(서버 자원 접근 용이)

 

단점

* 쿠키를 탈취당했을 때 직접적으로 사용자 인증 정보가 노출되지는 않지만 탈취한 쿠키로 서버에 요청을 보낼 수 있음

  (세션 하이재킹)

※ solution : 세션 암호화, 세션 유효기간 설정

* 서버에서 세션 저장소를 사용하기 때문에 사용자가 많아지면 서버에 과부하가 걸릴 수 있음

 

다음 글에서는 JWT Token 인증에 대해 알아보자

Comments