티스토리 뷰
세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 설명하세요.
1. 세션 기반 인증 (Session-based Authentication)
사용자의 인증 상태를 서버 측에서 관리하는 방식
기본 인증 흐름
1. 사용자의 로그인 요청 ->
2. 세션 생성 및 컨텍스트 저장 ->
3. 세션 ID 응답 ->
4. 후속 요청
장점
서버가 인증 상태를 관리하므로 보안 제어가 확실함.
사용자를 강제 로그아웃 시키거나, 동시 접속을 제한하는 등의 처리가 쉬움
단점
사용자가 증가할수록 서버의 메모리 부하가 커짐.
트래픽 분산을 위해 서버를 여러대 두는 환경에서는 세션 정보 불일치 이슈 발생 가능성이 있음
보안 고려사항
1. 세션 하이재킹을 막기 위한 HTTPS 통신 암호화 적용.
중간에 패킷을 가로채더라도 세션ID를 암호화 해 읽을수 없게 만들어야함
2. XSS(교차 사이트 스크립팅)를 통한 세션 탈취를 막기 위한 쿠키의 HttpOnly 속성 적용.
서버에서 쿠키를 발급할 때 HttpOnly 옵션을 설정해두면, JS코드로 쿠키에 접근하는것을 원천차단
3. 세션 고정을 이용한 권한 탈취를 막기 위한 로그인 시 세션 ID 재발급.
사용자가 로그인 성공 시 기존 세션 ID를 폐기하고, 새로운 세션 ID를 발급해 예전 세션 ID를 이용한 정보 탈취를 차단
4. CSRF(교차 사이트 요청 위조) 공격을 막기위한 CSRF 토큰 검증과 SameStie 쿠키 설정.
요청 시 쿠키 외에 폼(Form) 데이터에 별도의 CSRF 토큰을 함께 보내도록 검증하거나, 쿠키에 SameSite 속성을 설정하여 다른 도메인에서 날아오는 요청에는 쿠키가 묻어가지 않도록 차단
2. 토큰 기반 인증 (Token-based Authentication)
서버가 상태를 유지하지 않고, 사용자가 인증 정보(토큰)를 직접 보관하며 증명하는 방식
기본 인증 흐름
1. 사용자의 로그인 요청 ->
2. 토큰 발급 ->
3. 토큰 저장 ->
4. 후속 요청
장점
서버가 클라이언트의 상태를 기억할 필요가 없으므로 서버 확장에 유리함.
서버를 여러대 늘려도 토큰 검증만 하면 되므로 세션 불일치 문제가 발생하지 않음
단점
서버는 한번 발급된 토큰은 임의로 무효화하기 힘들어서, 통제가 까다로움
토큰 자체에 사용자 정보가 담겨 있어서, 보안 이슈 발생 시 문제가 커짐
보안 고려사항
1. XSS를 통한 토큰 탈취를 막기 위해 JS코드로 접근 불가능한 HttpOnly 속성을 적용한 쿠키에 토큰을 담아 통신
2. 탈취된 토큰의 무한 사용을 막기 위해 Acccess Token, Refresh Token 사용으로 분리 및 생명주기 관리
Access Token : 유효기간을 아주 짧게(15~30분) 설정하여 탈취 피해를 최소화
Refresh Token : 만료된 Access Token을 재발급받기 위한 용도로, 유효기간을 길게(1~2주) 잡고 안전한 곳에 보관
OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명하세요.
OAuth는 무엇인가?
사용자들이 비밀번호를 직접 제공하지 않고도, 웹사이트나 애플리케이션이 다른 서비스에 저장된 자신의 데이터에 접근할 수 있도록 접근 권한을 위임하는 개방형 표준 프로토콜
쉽게 말해, 애플리케이션 간에 안전하게 권한을 교환하기 위해 전 세계적으로 약속된 표준화된 규칙이다
OAuth 2.0 주요 컴포넌트
1. 자원 소유자(Resource Owner)
- 보호된 자원에 대한 접근 권한을 부여할 수 있는 주체. 일반적으로 서비스를 이용하는 '사용자'를 의미
2. 클라이언트(Client)
- 자원 소유자를 대신해 보호된 자원에 접근을 요청하는 애플리케이션. 웹 또는 모바일 애플리케이션이 이에 해당
3. 인가 서버(Authorization Server)
- 자원 소유자를 성공적으로 인증하고 권한 부여를 확인한 후, 클라이언트에게 Access Token을 발급하는 서버
4. 자원 서버(Resource Server)
- 보호된 자원(사용자의 데이터)을 호스팅하는 서버. Access Token을 검증하고, 유효한 경우 자원에 대한 접근을 허용
인가 코드 승인 방식(Authorization Code Grant)의 흐름
1. 로그인 시도
- 사용자가 웹 애플리케이션에서 로그인 등 OAuth 인증 버튼을 클릭
2. 인증 페이지로 이동
- 웹 애플리케이션은 사용자를 인가 서버의 로그인 화면으로 리다이렉트
3. 로그인 및 동의
- 사용자는 인가 서버에서 본인의 아이디/비밀번호로 로그인을 진행, 웹 애플리케이션이 자신의 어떤 정보(이메일, 프로필 등)에 접
근할지 확인한 후 권한을 동의
4. 인가 코드 발급
- 사용자가 동의를 마치면, 인가 서버는 사전에 약속된 콜백 URL로 사용자를 돌려보내면서 일회성 인가 코드를 함께 전달
5. 토큰 교환 요청
- 웹 애플리케이션의 백엔드 서버는 브라우저를 거치지 않고 직접 인가 서버로 찾아가, 방금 받은 인가 코드를 제출하며 액세스 토큰으로 교환요청
6. 액세스 토큰 발급
- 인가 서버는 요청(인가 코드, 클라이언트 정보 등)이 올바른지 철저히 검증한 후, 웹 애플리케이션에 실제 데이터 접근 권한이 담긴 액세스 토큰을 발급
7. 데이터 요청
- 웹 애플리케이션은 발급받은 액세스 토큰을 지참하여 리소스 서버에 보호된 데이터를 요청
8. 데이터 응답
- 리소스 서버는 전달받은 토큰의 유효성을 검증한 후, 토큰에 허락된 범위 내의 사용자 데이터(이메일, 이름 등)를 안전하게 응답
9. 로그인 완료
- 웹 애플리케이션은 받아온 사용자 정보를 바탕으로 자체적인 회원가입/로그인 처리를 완료 , 사용자에게 서비스 첫 화면을 보여줌