Session 기반 인증 | Token 기반 인증

Session 기반 인증 | Token 기반 인증을 알기 전에 인증(Authentication)과 인가(Authorization)에 대해 먼저 알아보고자 함

인증과 인가가 비슷하게 들릴 수 있지만 IAM(Identity and Access Management) 환경에서는 명확히 구분되는 보안 프로세스

 

인증(Authentication)

• 사용자의 신원확인
• 인증은 사용자의 신원을 검증하는 행위로서 보안 프로세스에서 첫 번째 단계

---

인증 프로세스

• 비밀번호: 사용자 이름과 비밀번호는 가장 많이 사용되는 인증 요소, 사용자가 데이터를 올바르게 입력하면 시스템은 아이덴티티가 유효하다고 판단하고 액세스를 허용함
• 일회용 핀: 단일 세션이나 트랜잭션에 한하여 액세스를 허용함
• 인증 앱: 액세스를 허용하는 외부 기관을 통해 보안 코드를 생성함
• 생체인식: 사용자가 시스템에 액세스하기 위해 지문이나 망막 스캔을 제출함

상황에 따라 인증 요소를 2가지 이상 성공적으로 확인해야만 시스템에 액세스할 수 있는 경우 발생

-> 다중 요소 인증(MFA) 요건이 배포되어 비밀번호의 한계를 넘어 보안을 강화하는 경우도 많음

---

인가(Authorization)

• 사용자에게 특정 리소스나 기능에 액세스할 수 있는 권한을 부여하는 프로세스
• 서버에서 특정 파일을 다운로드할 수 있는 권한을 부여, 개별 사용자에게 관리자 권한으로 애플리케이션에 액세스할 수 있는 권한을 부여하는 경우
• 권한 인증은 항상 인증 이후에 진행되어야 함

---

인증(Authentication)과 인가(Authorization)의 비교

집을 오래동안 비워 화초를 관리해야하는 상황

집 열쇠: 인증(Authentication) - 자격 증명을 정확하게 입력하는 사용자

출입허가에 대한 인증: 화초 영양제가 들어있는 창고를 열 수 있는 권한 인증 받게됨, 하지만 화초와 관련없는 소파에 누워 쉴 권한 없음

화초 주인은 집에 들어갈 수 있는 권한(인증) 존재, 특정 영역에 접근할 수 있음(권한 인증)

	인증(Authentication)	인가(Authorization)
기능	자격 증명 확인	권한 허가/거부
진행 방식	비밀번호, 생체인식, 일회용 핀 또는 앱	보안 팀에서 관리하는 설정 사용
사용자가 볼 수 있는가?	예	아니오
사용자가 직접 변경할 수 있는가?	부분적으로 가능	불가능
데이터 전송	ID 토큰 사용	엑세스 토콘 사용

---

Stateless | Stateful

• 상호 작용 상태가 얼마나 오래 기록되는지, 해당 정보가 어떤 식으로 저장되는지를 기준으로 구별

---

Stateless

• 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않는 것
• Stateless 구조에서 server는 단순히 요청이 오면 응답을 보내는 역할만 수행, 세션관리는 client에게 책임 있음
• client와의 세션 정보를 기억할 필요가 없으므로, 이러한 정보를 서버에 저장하지 않음(필요에 따라서 외부 DB에 저장하여 관리)
• 웹서버 통신 (http)특성상 사용자(브라우저)의 이전상태 client(쿠키) or Server(세션) 정보를 기록하지 않는 접속이란 의미
• 브라우저가 데이터를 전송할 때마다 연결하고 바로 끊어버리는 방식
• 스테이트리스 애플리케이션은 하나의 서비스 또는 기능을 제공
• 콘텐츠 전달 네트워크(CDN), 웹, 프린트 서버를 사용해 이러한 단기 요청을 처리
• 장점 : 서버의 확장성이 높기 때문에 대량의 트래픽이 발생 해도 대처를 수월하게 할 수 있음
• 단점 : 클라이언트의 요청에 상대적으로 Stateful보다 더 많은 데이터가 소모됨(매번 요청할 때마다 자신의 부가정보를 줘야하기 때문)
• 대표적인 Stateless 프로토콜: UDP, HTTP
• ex.  검색창에 질문을 입력하고 엔터키를 누르는 형식으로 진행되는 온라인 검색(트랜잭션이 우발적으로 중단되거나 종료되면 새롭게 시작, 단일 요청에 대해 하나의 응답)

---

Stateful

• 서버가 클라이언트의 상태를 보존
• 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태
• 온라인 뱅킹이나 이메일처럼 여러 번 반환
• 이전 트랜잭션의 컨텍스트에 따라 수행
• 현재 트랜잭션이 이전 트랜잭션에서 발생한 상황에 영향 받음
• 사용자에게 받은 요청을 처리할 때마다 같은 서버를 사용
• ex. 홈페이지에서 한번 로그인을 하면 페이지를 이동해도 로그인이 풀리지않고 계속 유지됨(일반적으로 브라우저의 쿠키(Cookie)에 저장되거나, 서버의 세션(Session) 메모리에 저장됨)

 

---

세션기반 인증 | 토큰기반 인증

• HTTP는 stateless한 특성을 가지기 때문에 각 통신의 상태가 저장되지 않음
• -> 그럼 새로운 페이지를 들어갈 때마다 로그인을 항상 해줘야하는가?
• -> 세션(Session)과 토큰(Token)필요

 

• 사용자(User)가 인증(Authentication)을 했다면 확인의 표시로 세션이나 토큰을 발급, 전달해줌
• -> 웹 브라우저에서 세션, 토큰의 정보를 보관하고 있음
• -> 새로운 요청을 보낼때 인가(Authorization)를 위해 해당 세션, 토큰을 보내줌

세션	DB서버에 저장
토큰	클라이언트 측에서만 저장

---

세션기반 인증 | 토큰기반 인증 차이점

1. 사이즈

세션 < 토큰
세션	세션을 주고 받는 세션 id의 크기 매우 작음(id를 쿠키에 저장하면 6바이트)
토큰	(JWT 기준) 토큰은 데이터를 담고 있어도 크기가 큼(304 바이트)

 

2. 안정성

세션	- 세션은 서버측에서 저장/관리하기 때문에 상대적으로 온전한 상태를 유지하기 유리함 - 여전히 공격의 위험이 있기에 유효기간, HttpOnly, Secure 옵션 등을 주어 쿠키에 저장함
토큰	- 토큰은 웹 브라우저측 (local storage, 혹은 쿠키 등)에 저장되기 때문에 공격에 노출될 가능성이 더 큼 -> 토큰에는 민감한 정보를 담지 않는다 - 유효기간을 짧게 설정해 공격에 노출될 수 있는 시간을 최소화함 -> 짧은 주기로 토큰이 무효화되면 서비스 사용자는 계속 로그인을 해줘야 하는 번거로움이 있음(로그인[인증]시 refresh token이라는 것을 추가적으로 발급)  - refresh token은 좀 더 긴 유효기간을 가졌으며 최대한 안전한 곳에 저장됨 - 기존의 토큰이 만료되거나 변질되면 refresh token을 통해 토큰을 재발급

 

3. 확장성

• 최근 대부분의 웹 서비스가 토큰 방식을 선택하게 된 이유가 바로 확장성에 있음
• 세션은 서버에 저장되기 때문에 한꺼번에 다중 접속자가 발생한다면 과부하가 걸릴 수 있음
  • -> 과부하를 덜어주기 위해 서버를 여러 대를 둠 <=> 서버가 여러 대라면 세션을 쓰기가 복잡해짐
•  HTTP는 stateless, connectionless 하기 때문에 요청마다 내가 접속한 서버가 달라질 수도 있음
  • -> 세션 정보가 없는 다른 서버에 접속할 때마다 계속 로그인(sticky session, session clustering과 같은 방안: 처리 비용발생)
  • => 토큰은 위와 같은 걱정 필요 없이 사용 가능

---

세션 동작 방식

---

토큰 동작 방식

 

 

 

---

참고자료

불타는 키보드, [인증/인가]Session(세션)과 Token(토큰)(JWT)의 차이점

okta Developer, Why JWTs Suck as Session Tokens

Red Hat, 스테이트풀과 스테이트리스 비교

camillesn.log,인증(Authentication) & 인가(Authorization)

irostrub, Stateful과 Stateless의 이해

strongdm, The Definitive Guide to Authentication

okta, 인증과 인가 (권한 부여) 비교 – 특징 및 차이점