1. 인증(Authentication)과 인가(Authorization)의 차이에 대해 설명해 주세요.
인증
-
어떤 사용자인지 검증하는 과정
- 회원가입 한 사용자인지 id와 pasward를 검증
-
세션방식 인증, 토큰방식 인증
인가
-
인증 받은 유저의 권한에 대한 검증
-
역할 기반 접근 제어(Role-Based Access Control, RBAC)
3. 세션과 쿠키 그리고 토큰 인증 방식에 대해 설명해 주세요.
세션 기반 인증 (+쿠키)
- 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식
세션 기반 자격 증명의 특징
-
세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.
-
생성된 사용자 세션의 고유한 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 요청을 보낼 때 인증된 사용자인지를 증명하는 수단으로 사용된다.
-
SSR(Server Side Rendering) 애플리케이션에 적합한 방식이다.
- 인증 상태를 서버에서 관리하기 떄문
세션 기반 인증 절차
세션 인증
- 사용자가 로그인 한다.
- 서버는 사용자의 ID와 함께 고유한 세션 ID를 생성한다.
- 서버는 세션 ID를 사용자에게 전달한다.
- 사용자는 이후 요청에서 세션 ID를 포함하여 보낸다.
- 서버는 세션 ID를 확인하고 사용자를 인증한다.
토큰 기반 인증
-
세션기반 인증방식으로 생기는 서버의 부담을 "클라이언트에게 넘겨줄순 없을까?"하는 생각에서 토큰 기반 인증이 고안되었다.
(대표적인 토큰기반 인증 = JWT) -
클라이언트 측에 인증된 사용자의 정보를 토큰 형태로 저장하는 방식
- 토큰: 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근할 수 있게 하는 역할
토큰 기반 자격 증명의 특징
-
토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도로 관리되지 않는다.
-
생성된 토큰을 헤더에 포함시켜 요청을 보낼 때, 인증된 사용자인지를 증명하는 수단으로 사용된다.
-
토큰에 포함된 사용자 정보는 토큰의 특성상 암호화되어 있지 않기 때문에, 공격자가 토큰을 탈취하면 사용자 정보가 그대로 제공된다. 따라서 민감한 정보는 토큰에 포함시키지 않아야 한다.
-
토큰은 기본적으로 만료될 때까지 무효화될 수 없다.
-
CSR(Client Side Rendering) 기반 애플리케이션에 적합한 방식이다.
- 인증 상태를 클라이언트에서 관리하기 떄문
토큰 기반 인증 절차
- 사용자 로그인
- 서버가 사용자 ID와 함께 고유한 토큰을 생성
- 서버는 생성된 토큰을 사용자에게 전달
- 사용자가 이후 요청에 토큰을 포함하여 전송 (일반적으로 HTTP 헤더에 포함)
- 서버는 토큰을 확인하고 사용자를 인증
요약: 토큰 기반 인증은 사용자의 인증 정보를 서버가 아닌 클라이언트 측에서 토큰 형태로 관리하는 방식이다. 이 방식은 서버의 메모리 부담이 줄어들고 확장성이 좋으며, 상태를 유지하지 않는 구조에 적합하다. 하지만 토큰이 탈취되면 보안에 취약할 수 있다.
4. 세션과 토큰 인증 방식 중 각각의 장단점을 말씀해 주세요.
세션 인증 방식
장점
-
클라이언트 측에서는 세션 ID만을 사용하기 때문에, 네트워크 트래픽 부담이 비교적 적다.
-
세션 정보는 서버 측에서 관리되기 때문에, 보안 측면에서 약간의 이점이 있다.
단점
-
서버 확장성 측면에서는 세션 불일치 문제가 발생할 가능성이 있다.
-
세션 데이터 양이 증가하면 서버 부하가 증가할 수 있다.
토큰 인증 방식
장점
-
서버의 메모리 부담이 줄어들고 확장성이 좋다.
-
인증된 사용자 요청의 상태를 유지할 필요가 없기 때문에 세션 불일치와 같은 문제를 일으키지 않으므로 서버의 확장성 측면에서 이점이 있다.
단점
-
토큰은 인증된 사용자 정보 등을 포함하기 때문에 세션보다 비교적 많은 네트워크 트래픽을 사용한다.
-
토큰은 기본적으로 서버 측에서 관리되지 않기 때문에 보안 측면에서 약간의 불리함이 있다.
- 이러한 보안 취약점을 보완하기 위해 토큰의 만료 시간 관리가 필요
꼬리질문 리스트
- 세션 불일치 문제란 무엇이고 해결방안은 무엇이냐
세션 기반 인증방식이 SSR(Server Side Rendering) 애플리케이션에 적합하고, 토큰 기반 인증방식이 CSR 애플리케이션에 적합한 이유는?
세션 불일치 문제
세션 불일치 문제는 여러 서버에 분산된 환경에서 발생하는 세션 관리 문제를 말한다.
세션 불일치 문제가 발생하는 상황
-
로드 밸런싱
- 사용자 요청이 여러 서버 중 하나로 전달되는 경우, 각 서버가 세션 정보를 동기화하지 못해 사용자 인증 상태가 일관되지 않는 문제가 발생할 수 있다.
-
서버 장애 및 복구
- 서버가 다운되거나 복구되는 과정에서 세션 정보가 손실되면 사용자가 다시 로그인해야 하는 문제가 발생할 수 있다.
세션 불일치 문제를 해결하기 위한 방법
-
세션 스티키
- 로드 밸런서가 사용자를 처음 요청을 처리한 서버에 계속 연결시키는 방식으로, 해당 서버에만 세션 정보를 유지하게 한다. 하지만 이 방법은 서버에 과부하가 발생할 수 있다.
-
세션 저장소 공유
- 여러 서버가 공유하는 세션 저장소(예: Redis, Memcached)를 사용하여 세션 정보를 동기화한다. 이 방법은 서버 간 세션 정보를 일관되게 유지할 수 있지만, 저장소에 대한 추가적인 관리와 리소스가 필요하다.
-
토큰 기반 인증
- 서버가 아닌 클라이언트 측에서 사용자 인증 정보를 토큰 형태로 관리하는 방식으로, 서버 간 세션 동기화 문제를 회피할 수 있다. 이 방법은 인증 상태를 유지하는데 필요한 서버 자원을 줄일 수 있지만, 토큰 노출에 따른 보안 문제에 주의해야 한다.
세션, 토큰 그리고 SSR, CSR
세션 기반 인증방식이 SSR(Server Side Rendering) 애플리케이션에 적합하고,
토큰 기반 인증방식이 CSR 애플리케이션에 적합한 이유는?
SSR은 서버에서 렌더링되어 사용자에게 페이지를 전달하니까 인증 상태를 서버에서 관리하는 세션 기반 인증방식이 유리한 것!
마찬가지로 토큰은 클라이언트에 저장하니까! CSR에 적합!
