안녕하세요, 오늘도 그거입니다.
세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.
세션 기반 인증과 토큰 기반 인증은 모두 사용자의 신원을 확인하고 보호된 자원에 접근할 수 있도록 하는 인증 방식이지만, 그 구현 방식과 작동 원리가 다릅니다. 아래는 이 두 방식의 주요 차이점을 설명한 것입니다.
세션 기반 인증
- 동작 원리:
- 사용자가 로그인하면 서버는 사용자를 인증하고, 서버 측에 세션을 생성합니다.
- 서버는 세션 ID를 생성하고 이를 사용자에게 쿠키로 전달합니다.
- 사용자는 이후 요청 시 이 세션 ID를 쿠키에 포함시켜 서버에 전송합니다.
- 서버는 전달받은 세션 ID를 사용하여 세션 스토리지에서 해당 세션을 조회하고 사용자를 인증합니다.
- 특징:
- 서버 중심: 세션 정보는 서버에 저장되며, 서버가 모든 세션 데이터를 관리합니다.
- 상태 유지: 서버는 각 사용자의 상태를 유지하기 위해 세션을 사용합니다.
- 확장성 제한: 서버가 모든 세션 데이터를 유지해야 하므로, 사용자가 많아지면 서버의 메모리와 성능에 부담이 됩니다.
- 쿠키 의존성: 세션 ID는 쿠키를 통해 클라이언트와 서버 간에 전달됩니다.
- 보안:
- 서버에서 세션 데이터를 관리하므로, 세션 탈취 공격(Session Hijacking)에 취약할 수 있습니다.
- 세션 타임아웃 설정을 통해 보안을 강화할 수 있습니다.
토큰 기반 인증
- 동작 원리:
- 사용자가 로그인하면 서버는 사용자를 인증하고, JWT(JSON Web Token)와 같은 토큰을 생성합니다.
- 이 토큰은 사용자가 인증되었음을 증명하는 서명된 정보로 구성됩니다.
- 서버는 이 토큰을 클라이언트에게 전달하고, 클라이언트는 이후 요청 시 이 토큰을 HTTP 헤더에 포함시켜 서버에 전송합니다.
- 서버는 토큰을 검증하여 사용자를 인증합니다.
- 특징:
- 클라이언트 중심: 토큰은 클라이언트에 저장되고, 서버는 상태를 유지하지 않습니다.
- 무상태: 서버는 세션을 유지하지 않으므로, 확장성이 뛰어납니다.
- 분산 시스템에 적합: 여러 서버나 마이크로서비스 환경에서도 쉽게 사용할 수 있습니다.
- 자급 자족: 토큰에는 필요한 정보가 포함되어 있어, 추가적인 데이터베이스 조회 없이 사용자를 인증할 수 있습니다.
- 보안:
- 토큰은 기본적으로 서명되어 있어 변조를 방지하지만, 탈취되면 악용될 수 있습니다.
- 토큰의 유효기간을 설정하고, HTTPS를 통해 전송하여 보안을 강화할 수 있습니다.
- 필요에 따라 토큰을 폐기하거나 갱신할 수 있습니다.
결론
세션 기반 인증은 서버가 상태를 유지하며 관리하는 방식으로, 단일 서버 환경에서 간단하게 구현할 수 있지만, 확장성에 제약이 있습니다. 반면 토큰 기반 인증은 무상태 방식으로, 확장성이 뛰어나고 분산 시스템에 적합하지만, 토큰 탈취에 대한 보안 대책이 필요합니다. 각 방식은 특정 상황과 요구사항에 따라 적합하게 선택될 수 있습니다.
JWT, Refresh, Access Token에 대해서 설명해주세요.
JWT, Refresh Token, Access Token은 현대 웹 애플리케이션에서 인증 및 권한 부여를 관리하는 중요한 구성 요소입니다. 각 토큰의 역할과 특성은 다음과 같습니다.
JWT (JSON Web Token)
- 개념:
- JWT는 JSON 객체를 안전하게 전송하기 위한 컴팩트하고 URL-안전한 방법입니다.
- 일반적으로 사용자의 인증 및 정보 교환에 사용됩니다.
- 구조:
- Header: 토큰의 유형과 서명 알고리즘 정보를 포함합니다.
- Payload: 사용자 정보 및 클레임(Claims)을 포함합니다. 예를 들어, 사용자 ID, 발급 시간, 만료 시간 등이 포함될 수 있습니다.
- Signature: Header와 Payload를 비밀키로 서명한 부분으로, 토큰의 무결성을 확인하는 데 사용됩니다.
- 특징:
- Self-contained: 필요한 모든 정보가 포함되어 있어, 별도의 데이터베이스 조회 없이도 유효성을 검증할 수 있습니다.
- 무상태(Stateless): 서버는 토큰의 상태를 유지할 필요가 없습니다.
- Signed: 토큰의 무결성을 보장하기 위해 서명되어 있으며, 변조를 방지합니다.
Access Token
- 개념:
- Access Token은 클라이언트가 보호된 리소스에 접근할 수 있도록 허용하는 토큰입니다.
- 일반적으로 짧은 유효기간을 가지며, 서버는 이 토큰을 사용해 클라이언트의 요청을 인증합니다.
- 사용 예시:
- 클라이언트가 API 요청 시 Access Token을 HTTP 헤더에 포함시켜 서버에 전송합니다.
- 서버는 토큰을 검증하고, 요청된 리소스에 대한 접근 권한을 부여합니다.
- 특징:
- 단기 유효성: 짧은 기간 동안 유효하여, 만료 시 보안 위험을 줄입니다.
- 경량화: 요청 시마다 전송되므로, 가능한 한 작은 크기로 유지하는 것이 좋습니다.
Refresh Token
- 개념:
- Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용되는 토큰입니다.
- 일반적으로 긴 유효기간을 가지며, 클라이언트가 서버와의 인증 세션을 지속적으로 유지하는 데 사용됩니다.
- 사용 예시:
- Access Token이 만료되면, 클라이언트는 Refresh Token을 서버에 전송하여 새로운 Access Token을 요청합니다.
- 서버는 Refresh Token의 유효성을 검증하고, 새로운 Access Token을 발급합니다.
- 특징:
- 장기 유효성: 긴 기간 동안 유효하여, 사용자가 자주 로그인하지 않아도 됩니다.
- 보안 강화: Refresh Token을 통해 짧은 유효기간의 Access Token을 자주 갱신함으로써 보안을 강화합니다.
요약
- JWT (JSON Web Token): 인증 및 정보 교환을 위한 자가 포함된 서명된 토큰.
- Access Token: 보호된 리소스에 대한 접근 권한을 부여하는 단기 유효성 토큰.
- Refresh Token: Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위한 장기 유효성 토큰.
이 세 가지 토큰은 서로 보완적으로 사용되어, 웹 애플리케이션의 보안과 사용자 경험을 향상시킵니다.
최종프로젝트
진행상황 체크
프론트 구현
발표관련 회의
트러블슈팅
- 프론트에서 백엔드 데이터를 못불러옴
- 인증인가 문제인가 -> WebSecurityConfig permitAll 실험실패
- 페이지네이션 문제인가 -> 페이지네이션 로직 삭제 실험실패
- 프론트 디자인 문제인가 -> 백엔드 로직 기반 프론트 디자인 실험실패
- components 에 넣어야 하는 디렉토리 구조 문제인가 -> 디렉토리 변경 실험실패
- 토큰 문제인가 -> 토큰이 들어가지 않아서 생긴 문제였다.
새로운 시작~!