세션과 쿠키를 이용한 인증 flow

프론트엔드 기초지식을 복습하는과정에서 

현업에서 인턴 경험에서 로그인을 구현할 때 썼던 방법인 세션과 쿠키를 이용한 인증flow에 대해서 

다시 복습할 기회가 되어 이렇게 정리를 해 보았다.

 

 

용어 정리 

---

Session 

: 동일한 클라이언트(사용자)가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나의 상태로 보고, 그 상태를 일정하게 유지하여 클라이언트와 웹 서버가 연결된 상태를 말한다. 

 

 

Session ID 

: 서버는 Session에 대한 정보를 저장하고 클라이언트에게는 Sesssion을 구분할 수 있는 ID를 부여하는데 이것을 Session ID 라고 한다. 

 

 

Cookie

: 클라이언트의 컴퓨터에 저장되는 데이터 파일로,  Cookie에는 이름, 값, 만료 날짜/시간(저장기간), 경로 정보 등으로 구성이 되어있다.

(Cookie는 하나의 도메인 당 20개를 가질 수 있으며, 1개 당 4Kbyte를 넘길 수 없다는 특징을 가지고 있다)

 

 

Token

: 제한된 리소스에 대해 일정 기간 동안 접근 할 수 있는 권한을 캡슐화 한 것으로 의미를 알 수 없는 임의의 문자열 형태로 사용자에게 발급 한다.

또한, 제한된 리소스에 대한 접근 권한을 캡슐화 할 뿐만 아니라 접근 할 수 있는 리소스의 범위와 접근 가능한 기간을 통제 할 수 있다.

 

 

CORS

MDN- 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

 

CORS오류가 나는 이유?

- 동일 출처 정책(Same-Origin Policy): 웹 브라우저는 보안상의 이유로 스크립트에서 다른 도메인, 포트, 프로토콜로 리소스를 요청하는 것을 제한합니다. 웹 페이지가 다른 출처로 리소스를 요청하려고 하면 브라우저가 CORS 정책을 적용하여 요청을 차단하고 오류를 생성합니다.

- CORS 정책 설정 부족: 서버 측에서 CORS 정책을 설정하지 않은 경우 브라우저는 기본적으로 리소스 요청을 거부합니다. 서버는 적절한 CORS 헤더를 포함하여 다른 출처에서 오는 요청을 허용해야 합니다.

- 잘못된 CORS 설정: 서버에서 잘못된 CORS 설정이 이루어진 경우, 브라우저는 요청을 거부할 수 있습니다. 예를 들어, 허용되지 않은 출처를 허용하도록 설정되어 있거나, 요청 헤더가 잘못되어 있는 경우 등이 해당합니다.

- 인증 정보 문제: 기본적으로, 브라우저는 인증 정보를 포함한 요청을 CORS 요청에 대해 차단합니다. 인증 정보를 사용해야 하는 경우, 서버 측에서 특정 헤더를 설정하여 허용해야 합니다.

 

 

 

Stateless

: Session 방식처럼 상태 정보를 서버측에서 관리 하지 않고, 사용자 측에서 관리하기 때문에 서버의 상태를 Stateless하게 유지하게 되므로 서버측에서는 사용자로부터 받은 Request만을 가지고 작업을 수행 할 수 있습니다.

 

 

Session과 Cookie를 이용한 인증 Flow

---

1. 사용자가 로그인을 하기 위해 인증 정보를 가지고 인증 과정을 요청 한다.
2. 인증이 완료 되면 사용자의 Session 정보를 서버의 메모리에 저장 후 해당 Session을 식별할 수 있는 Session ID 발급 한다.
3. 발급한 Session ID가 Cookie에 저장 될 수 있도록 HTTP Response Header의 Set-Cookie 속성을 이용하여 사용자에게 전달 한다.
4. 전달받은 Session ID는 브라우저의 Cookie에 저장 되고, Request를 서버에 보낼 때 함께 전달 된다.
5. 서버는 사용자가 보낸 Session ID 와 서버 메모리에서 관리하고 있는 Session ID를 비교하여 Verification을 수행 후 권한을 인가 한다.

https://study.wecode.co.kr/session/content/320

 

 

간단정리 

Session을 이용할 경우, 인증이 완료 되면 사용자의 Session 정보를 서버에 저장하고 해당 Session 정보를 식별할 수 있는 session_id를 클라이언트에게 전달한다.

 이 때, 클라이언트와 서버는 cookie를 이용하여 session_id를 주고받는다.

 

 

 

세션 기반 인증의 특징

---

장점

• Session ID 자체에는 유의미한 개인정보를 담고 있지 않아 안전하다.
• 서버에서 정보를 관리하기 때문에 데이터의 손상 우려에 대해 안전하다.
• 서버에서 상태를 유지하고 있으므로, 사용자의 로그인 여부 확인이 쉽고, 경우에 따라서 강제 로그아웃 등의 제재를 가할 수 있다.
  
  

단점

• 서버에서 모든 사용자의 상태를 관리해야 되므로 사용자의 수가 증가 할 수록 서버에 가해지는 부하가 증가한다.
• 사용자가 증가하여 서버의 Scale Out을 해야 할 때 Session의 관리가 어려워 진다.
• 모바일 기기와 브라우저에서 공동 사용 할 때 중복 로그인 처리가 되지 않는 문제 등 신경 써줘야 할 부분 들이 증가한다.

 

 

 

 

 

 Token을 이용한 인증 Flow

---

1. 사용자가 로그인을 하기 위해 인증 정보를 가지고 인증 과정을 요청한다. 
2. 인증이 완료 되면 서버의 메모리에 Session을 저장하는 대신에 사용자의 식별 정보를 가지고 있는 Token을 발급한다.
3. 발급한 Token은 Response의 Body에 담아 사용자에게 전달한다.
4. 사용자는 발급된 Token을 local storage에 저장 한다.
5. 사용자는 Request를 할 때마다 저장된 Token을 Header 에 포함시켜 서버로 보낸다.
6. 서버는 사용자로부터 전달받은 Header의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가 한다.

 

 

 

 

Token 기반 인증의 특징

---

장점

• Token을 사용자 측에서 저장하므로 서버의 메모리나 DB 등의 부담이 없다.
• 사용자의 상태 정보를 서버에서 관리하지 않기 때문에 서버의 Scale Out에 용이 하다.
• 서버의 상태를 Stateless 하게 유지 할 수 있어 서버 확장에 유리하다.
• 모바일과 브라우저의 멀티 환경에서 사용이 용이 하다. 
• Token의 만료 시간을 짧게 설정하여 안정성을 높일 수 있다.
• CORS 방식을 사용하기 용이 하다.

단점

• 서버에서 사용자의 상태를 저장하고 있지 않기 때문에 사용자의 로그인 여부 확인, 경우에 따른 강제 로그아웃 등의 제재를 가하기 어렵다.
• 사용자가 임의로 토큰을 수정하거나 구조가 변경되게 되면 서버에서 확인할 수가 없다.
• Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가 한다.