로그인 인증/인가 방식 1. 세션 방식

세션과 토큰방식 로그인에 대해 알아보기 전에, 왜 필요한지를 먼저 알아보자.

→ 이를 위해, HTTP에 대해 알 필요가 있다.

 

# HTTP

1/ HTTP란?

- 웹 브라우저와 웹 서버간의 통신에 사용되는 프로토콜

- 클라이언트(웹브라우저)가 서버에 요청을 보내고, 서버가 클라이언트에게 데이터를 응답하는 방식으로 동작.

 

2/ HTTP 특징

HTTP의 여러 특징 중 하나는 바로, HTTP 프로토콜은 Connectionless와 Stateless이라는 것!

 

1. Connectionless Protocol : 비연결지향(비연결성)

클라이언트가 서버에 요청했을 때, 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식.

즉, 각 요청은 독립적으로 처리되고, 이전 요청과의 연결을 유지하지 않는다.

→ 그래서, 아래의 Stateless의 특징이 나타나게 된다.

 

2. Stateless Protocol : 무상태성, 상태 정보를 유지하지 않음

클라이언트와 첫번째 통신에서 데이터를 주고받았을지라도, 두번째 통신에서는 이전 데이터를 유지하지 않는다.

요청이 끝나면 서버는 클라이언트가 누군지 잊어버린다. 따라서 요청을 할 때마다 우리가 누군지 알려줘야한다.

 

이렇게, HTTP 프로토콜은 상태정보를 유지하고 있지 않는 Stateless특성을 가지므로,

로그인 상태를 유지하기 위해서는 서버에 요청을 보낼 때마다 내가 누구인지를 알려줘야 한다.

 

예를 들어, 내가 gmail에 로그인을 한 후, 받은 편지함에 들어가고 메일을 열어볼 때마다 일일이 다시 로그인을 하면 굉장히 번거롭다.

한번 로그인을 하면, 내가 현재 로그인 상태라는 것을 서버도 알고 있어야한다.

 

 

 

# 매 요청마다 id & password를 보내 로그인을 해서 유지하면 안되나?

→ 이렇게 하기에는 로그인이라는 과정은 꽤 무거운 작업이다.

로그인을 위해서는 Database에 저장된 사용자계정의 해시값 등을 꺼내온 다음, 이걸로 사용자의 password를 복잡한 알고리즘으로 계산한 값과 일치하는지 확인하는 과정을 거쳐야 한다.

계산도 복잡한데다 Database에서 해시값 등을 꺼내오는 작업도 시간과 자원을 많이 잡아먹는다.

또한, 매 요청마다 id와 password를 실어다니는건 보안상 위험.

그래서 매 요청마다 로그인 작업을 하는건 무리가 있다.

 

 

 

로그인을 유지하는 대표적인 방법 두가지는 바로 세션 방식, 그리고 토큰 방식.

이번 글에서는 '세션방식'을 알아보자.

 

# 세션 방식

- 기존의 전통적으로 많이 사용되어온 방식

 

## 세션 방식의 흐름

1. 클라이언트 : 사용자가 로그인 화면에서 로그인을 한다. 로그인 정보인 id, password를 서버로 request.

2. 서버 : DB에 저장된 id, password와 입력받은 id, password를 비교

3. 서버 : 일치할 경우, session id 생성한 후 session id, 사용자정보(id, 이름, 권한, 장바구니 내용, 설정 등), 세션 유효기간 등의 정보가 담긴 새로운 세션을 생성. 이 세션을 서버의 메모리 또는 세션 스토어 등에 저장

4. 서버 : 생성한 session id를 클라이언트에 header의 Set-Cookie로 전달

Set-Cookie: SESSIONID=66C....

 

** 여기서 잠깐! 쿠키의 유효기간에 대해서 알아보자.

 

 

쿠키의 유효기간(라이프타임)은 Session Cookie와 Permanent Cookie 두가지 방법이 있다.

보통 서버에서 클라이언트로 session id를 넘겨줄 때는 'Session 쿠키'로 보낸다.

 

[ Session 쿠키 vs Permanent 쿠키 ]

1/ Session cookie

- 웹 브라우저가 종료될 때 자동으로 제거되는 쿠키. 즉, 현재 세션이 끝날 때 삭제되는 쿠키.

- 브라우저 세션(사용자가 브라우저를 열고 닫을 때의시간)에만 유효.

- 설정 방법 : Set-Cookie 헤더에 Expires를 명시하지 않거나, Expires속성을 생략.

Set-Cookie: SESSIONID=66C....

 

2/ Permanent Cookie

- 브라우저가 종료되더라도 쿠키 유지. 설정한 기간동안 유효.

- 사용자 로그인 상태를 오랫동안 유지하고 싶은 경우, 이 쿠키를 사용.

- 설정 방법 : 쿠키를 생성할 때, Expires 또는 Max-Age 옵션을 추가하면 된다.

- Expires : 쿠키가 만료될 날짜 지정

- Max-Age : 현재 시간을 기준으로 얼마동안 쿠키를 유지시킬것인가 지정

Set-Cookie: SESSIONID=66C..; Expires=Wed, 26 Oct 2024 07:28:00 GMT;

 

 

5. 클라이언트 : 서버로부터 전달받은 session id를 클라이언트의 쿠키에 저장

Cookie: SESSIONID=66C..

 

6. 클라이언트 : 서버로 전송하는 모든 요청에 session id를 쿠키에 담아 전달

Cookie: SESSIONID=66C..

 

7. 서버 : 클라이언트로부터 받은 session id와 세션스토어에 저장되어있는 session id 일치여부 확인

8. 서버 : 일치 시, 해당 session id에 연결되어있는 세션 정보를 세션 스토어에서 검색

9. 서버 : 세션 정보를 활용하여 해당 사용자의 상태나 권한 확인. 요청에 맞는 작업 수행

 

 

여기서 중요 포인트는,

- 유저의 정보들은 서버 쪽에서 관리한다는 점!

 

 

## 장점

- 쿠키에 아무런 의미가 없는 session id가 저장되어있으므로, 탈취되더라고 해커가 해석이 불가능하다.

 

## 단점

- 해커가 중간에 가로챈 쿠키(session id)로 http 요청을 보낼 수 있는 hijacking 공격을 당할 수 있다.

→ 해결법

    -- HTTPS를 사용해 요청 자체를 탈취해도 정보를 읽기 힘들게 한다.

    -- session에 유효기간을 넣어, 정보를 탈취하더라도 유효기간이 끝나면 더이상 해커가 이용할 수 없도록 한다.

 

- 서버에 유저 정보를 전부 저장해놓으므로, 사용자가 다수일 경우 서버의 부하가 높아진다.

- 중앙 세션스토어가 아닌, 서버 컴퓨터의 메모리나 하드디스크에 저장 시, 확장성이 좋지 않다. (서버 컴퓨터를 추가할 경우, 각 서버컴퓨터마다 세션 정보를 공유해야하므로!)

- 서버 확장 시, 모든 서버가 접근할 수 있도록 별도의 중앙 세션 관리시스템(세션 스토어)이 필요하다.

 

 

다음 글에서는 '토큰 방식'에 대해서 알아보자!

 

**참고글

https://dream-and-develop.tistory.com/196

[Web] 웹 브라우저 쿠키(Cookie)와 세션(Session)의 개념

https://dooopark.tistory.com/6

서버 기반 인증, 토큰 기반 인증 (Session, Cookie / JSON Web Token)

https://80000coding.oopy.io/1f213f10-185c-4b4e-8372-119402fecdd0

로그인 인증방식 어떤게 좋을까? Session VS JWT