프론트엔드 기초지식을 복습하는과정에서
현업에서 인턴 경험에서 로그인을 구현할 때 썼던 방법인 세션과 쿠키를 이용한 인증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
- 사용자가 로그인을 하기 위해 인증 정보를 가지고 인증 과정을 요청 한다.
- 인증이 완료 되면 사용자의 Session 정보를 서버의 메모리에 저장 후 해당 Session을 식별할 수 있는 Session ID 발급 한다.
- 발급한 Session ID가 Cookie에 저장 될 수 있도록 HTTP Response Header의 Set-Cookie 속성을 이용하여 사용자에게 전달 한다.
- 전달받은 Session ID는 브라우저의 Cookie에 저장 되고, Request를 서버에 보낼 때 함께 전달 된다.
- 서버는 사용자가 보낸 Session ID 와 서버 메모리에서 관리하고 있는 Session ID를 비교하여 Verification을 수행 후 권한을 인가 한다.
간단정리
Session을 이용할 경우, 인증이 완료 되면 사용자의 Session 정보를 서버에 저장하고 해당 Session 정보를 식별할 수 있는 session_id를 클라이언트에게 전달한다.
이 때, 클라이언트와 서버는 cookie를 이용하여 session_id를 주고받는다.
세션 기반 인증의 특징
장점
- Session ID 자체에는 유의미한 개인정보를 담고 있지 않아 안전하다.
- 서버에서 정보를 관리하기 때문에 데이터의 손상 우려에 대해 안전하다.
- 서버에서 상태를 유지하고 있으므로, 사용자의 로그인 여부 확인이 쉽고, 경우에 따라서 강제 로그아웃 등의 제재를 가할 수 있다.
단점
- 서버에서 모든 사용자의 상태를 관리해야 되므로 사용자의 수가 증가 할 수록 서버에 가해지는 부하가 증가한다.
- 사용자가 증가하여 서버의 Scale Out을 해야 할 때 Session의 관리가 어려워 진다.
- 모바일 기기와 브라우저에서 공동 사용 할 때 중복 로그인 처리가 되지 않는 문제 등 신경 써줘야 할 부분 들이 증가한다.
Token을 이용한 인증 Flow
- 사용자가 로그인을 하기 위해 인증 정보를 가지고 인증 과정을 요청한다.
- 인증이 완료 되면 서버의 메모리에 Session을 저장하는 대신에 사용자의 식별 정보를 가지고 있는 Token을 발급한다.
- 발급한 Token은 Response의 Body에 담아 사용자에게 전달한다.
- 사용자는 발급된 Token을 local storage에 저장 한다.
- 사용자는 Request를 할 때마다 저장된 Token을 Header 에 포함시켜 서버로 보낸다.
- 서버는 사용자로부터 전달받은 Header의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가 한다.
Token 기반 인증의 특징
장점
- Token을 사용자 측에서 저장하므로 서버의 메모리나 DB 등의 부담이 없다.
- 사용자의 상태 정보를 서버에서 관리하지 않기 때문에 서버의 Scale Out에 용이 하다.
- 서버의 상태를 Stateless 하게 유지 할 수 있어 서버 확장에 유리하다.
- 모바일과 브라우저의 멀티 환경에서 사용이 용이 하다.
- Token의 만료 시간을 짧게 설정하여 안정성을 높일 수 있다.
- CORS 방식을 사용하기 용이 하다.
단점
- 서버에서 사용자의 상태를 저장하고 있지 않기 때문에 사용자의 로그인 여부 확인, 경우에 따른 강제 로그아웃 등의 제재를 가하기 어렵다.
- 사용자가 임의로 토큰을 수정하거나 구조가 변경되게 되면 서버에서 확인할 수가 없다.
- Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가 한다.
'프론트앤드 > 이것저것' 카테고리의 다른 글
| 웹 성능 최적화 (0) | 2023.07.18 |
|---|---|
| JWT(JSON Web Token) (0) | 2023.07.18 |
| [2차 프로젝트] small box read me + 회고록 (0) | 2023.04.08 |
| [Git branch] (0) | 2023.02.23 |
| [1차 프로젝트 회고] (0) | 2023.02.20 |