세션 기반 로그인에 대한 설명

날짜: 2023년 3월 13일
태그: 교육, 원티드 프리온보딩

세션 기반 로그인 구현과 JWT와의 비교 및 인프라스트럭쳐

세션이란 무엇인가?

세션이란 단어는 무엇을 의미 하는가? 토큰의 의미를 다시 한번 새겨 보자

이처럼 토큰은 명백한 뜻이 있고 정의를 내릴 수 있다. 그렇다면 세션은..?

세션(session)은 컴퓨터 과학에서, 특히 네트워크 분야에서 반영구적이고 상호작용적인 정보 교환을 전제하는 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결상태를 의미하는 보안적인 다이얼로그(dialogue) 및 시간대를 가리킨다.

(출처 : 위키백과)

 

위의 정의를 보고 다양한 생각이 들 수 있는데,,

1. 데이터 저장 방식?
2. 통신 프로토콜?
3. 인증 방법론?
4. 암호화 방식?

“아무튼 로그인에 쓰이는 방법 아닌가요???”

우리가 생각하는 세션은 로그인에 사용하는 방법인데, 그렇다면 토큰 방식 로그인을 돌아보자

토큰 기반 로그인

토큰 기반 로그인에서는 토큰🪙을 발급하고 사용자가 기능 요청 통신을 전송할때 토큰🪙을 같이 보낸다. 이 토큰을 서버에서 확인하고 사용자가 누군지 인식한다.

그렇다면? 세션 기반 로그인이란…

 

특히 네트워크 분야에서 반영구적이고 상호작용적인 정보 교환을 전제하는 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결상태

 

세션기반 로그인 인증은 위의 세션의 정의와 함께 생각 해보면 다음과 같은 결론을 내릴 수 있다.

 

 

세션:

사용자의 로그인 이후 로그아웃 혹은 로그인 만료까지의 기간

세션 방식 로그인:

사용자 로그인이 유요한 시간 동안 서버에 세션 아이디를 기록해 두고 인증에 사용하는 방식

 

 

사용자가 성공적으로 로그인을 마치면, 서버에서 사용자의 세션을 저장하고, 요청마다 세션의 있는 정보를 이용할 수 있다는 것이다.

 

세션은 어떤 방식으로 기록을 하나?

쿠키

쿠키의 역할은 다음과 같다.

• 서버가 사용자의 웹브라우저에 전송하는 작은 데이터 조각
• 쿠키는 두요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용
• 상태가 없는 HTTP 프로토콜에서 주로 사용된다.
• 세션관리 (Session Management) : 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보관리
• 세션 로그인 방식은 쿠키에 sid (세션아이디)를 담아서 전송하게 될것이다.

 

 

브라우저에 쿠키를 저장하는 방법은 …. 서버에서 발급된 sid로 자동으로 담아 진다. 서버에서 응답이 올때 Set-Cookie헤더에 sid가 담아져서 전송이 되고 이 헤더는 차후에 http 전송을 날릴 때 자동으로 담겨져서 날라간다. 이 때 여러가지 세션 쿠키에 관한 정책들(보안, 만료기간,,,)은 서버에서 설정하게 된다!

 

쿠키 관련 정책 지정하기

프론트에서는 http 통신을 할때 관련 정책을 지정할 수 있다.

 

SameSite

쿠키의 정책으로 None, Lax, Strict 세 가지 종류를 선택할 수 있고, 각각 동작하는 방식이 다름

1. None : None으로 설정된 쿠키의 경우 크로스 사이트 요청의 경우에도 항상 전송됨. 보안적으로도 SameSite 적용을 하지 않은 쿠키와 마찬가지로 문제가 있는 방식임
2. Strict : 가장 보수적인 정책 Strict로 설정된 쿠키는 크로스 사이트 요청에는 항상 전송되지 않음.
3. Lax : Strict에 비해 상대적으로 느슨한 정책 Lax로 설정된 경우, 몇 가지 예외적인 요청에 전송됨
   • 동일출처사이트 가능
   • "안전한" HTTP 메서드 요청 가능 (get method)

httpOnly

• document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막는다.
• 서버로 HTTP Request 요청을 보낼때만 쿠키를 전송한다.
• 이를 통해 XSS(Cross Site Scripting) 공격을 차단할 수 있다.

Secure

• 웹브라우저와 웹서버가 HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송하는 옵션

보안정책을 적재적소에 따라 수행해 안전한 웹 개발을 하자 !

 

CORS 이슈

악명 높은 cors 이슈… 어떤걸까..?

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

말그대로 주소(포트포함)가 다르면 cors 경고가 뜨면서 통신이 되지 않는다.

 

해결방법은?

프론트엔드에서 해야 하는 일

• 베포됐을 경우에는… 별 일 할 수 없다.
• 로컬 환경에서는 브라우저의 보안 기능꺼서 해결 가능

벡엔드에서 해야 하는 일

• cors를 허용하는 도메인을 설정해줄 수 있다.

세션 로그인을 구현할 때, 자주 뜰 수 있는 오류이니 당황하지 말고 cors 옵션을 잘 설정하자!

---

세션의 로그인 흐름

 

• 브라우저에 접속하면 세션이 유효한지(서버에서) 검증함
• 유효하면 세션을 계속 유지 함
• 유효하지 않으면 로그인을 진행해서 새로운 세션을 발급받음

 

세션의 사용하기위한 추가 기능

로그아웃

• 세션을 서버에 저장하기 때문에 만료시키거나, 세션파괴를 통해 세션을 관리 해야할것

권한 관리

• 세션에 따라 서버에 접근할 수 있는 권한을 설정해야 할것이다.

 

---

세션 vs JWT

JWT 기반 인증	세션 기반 인증
• 서버/백엔드 비용 감소 • 프론트엔드 복잡도 높아짐 • 보안 상 세션보다 조금 더 위험	• 서버 백엔드 비용 대폭증가 • 프론트엔드 인증 쉬워짐 • 보안상 약간의 향상

 

무슨 방법을 선택해야 하는가?

어떤 기준으로 생각해야 하는가? 다음과 같은 기준으로 생각해보길 바란다.

• 동시접속사 수
• 서비스 규모
• 앱/웹 동시운용 여부
• 팀 내 인력 구성
• 일정

---