1. 공개키 & 개인키 비대칭 암호화
- 공개키와 개인키를 사용하는 암호화 방식
- 공개키는 자유롭게 공유 가능, 개인키는 각 사용자만이 보유하여 메시지를 복호화 가능
- A와 B의 공개키/개인키 쌍
- A와 B는 각각 공개키와 개인키를 가지고 있음
- A = B의 공개키를 사용해 데이터 암호화, B = 그 데이터를 자신의 개인키로 복호화 가능
- 반대로 B도 A의 공개키를 사용해 데이터 암호화 및, A는 자신의 개인키로 복호화
- 메시지 암호화 과정
- A → B 어떤 정보를 전달하려고 함. A는 B의 공개키를 이용해 데이터 암호화, B는 그 데이터를 자신의 개인키로 복호화
- B → A 데이터 전송시, A의 공개키를 이용해 암호화하고 A는 자신의 개인키로 복호화
- C (Confidentiality) : 정보가 외부에 노출되지 않도록 안전하게 보호하는 것 → 암호화를 통해 기밀성 유지
- I (Integrity) : 데이터가 전송 중 변조되지 않았다는 것을 보장하는 것
- A (Availability) : 시스템이나 데이터에 대한 접근이 요구될 때 언제나 가능한 상태
2. SSL 인증서, CA 기관을 통한 인증 절차
- CA 기관 (Certificate Authority)
- 신뢰할 수 있는 제 3자, 웹 서버가 자신이 주장하는 대로 실제 그 서버가 맞는지 확인해주는 역할
- 공개키와 개인키를 포함한 SSL 인증서를 발급
- Blog Server
- 사용자의 데이터를 안전하게 처리, 통신 암호화를 위해 CA 기관에 인증서 요청
- 인증서 발급 후 서버는 그 인증서를 통해 클라이언트와 안전한 통신을 설정
- Client(shin)
- Blog Server에 접속할 때 SSL 인증서 확인, 그 인증서를 통해 신뢰할 수 있는 서버 확인
- 서버의 공개키를 사용해 데이터를 암호화 해서 전송
- SSL 인증서 발급 과정
- Blog Server는 CA 기관에 인증서 요청을 보냄
- CA 기관은 Blog Server 신원 검증 및 SSL 인증서 발급. (이 인증서에는 서버의 공개키 포함)
- Blog Server는 발급받은 인증서를 클라이언트와 통신에 사용
- 통신 과정
- 클라이언트가 Blog Server에 접속하면 서버의 SSL 인증서를 다운받아 인증서 검증
- 검증된 인증서의 공개키로 데이터를 암호화해서 서버로 전송
- 서버는 자신의 개인키로 클라이언트의 암호화된 데이터를 복호화
중요 보안 요소
- SSL 인증서
- 서버와 클라이언트 간 통신 암호화에 사용, 서버의 신뢰성 보장
- 중간자(배신자) 공격 방지, 클라이언트는 안전하게 데이터 전송 가능
- 공개키/개인키 암호화
- 클라이언트는 서버의 공개키로 데이터 암호화 및 전송
- 서버는 자신의 개인키로 그 데이터를 복호화 → 비대칭 암호화 방식
- 세션 관리
- 세션 ID (JSessionID)를 통해 서버는 각 클라이언트를 고유하게 식별, 여러 요청이 하나의 사용자를 기준으로 처리되도록 함 → 클라이언트와 서버가 계속 상호작용에 중요 역할
정리
- 클라이언트는 서버가 신뢰할 수 있는지 SSL 인증서를 통해 확인, 공개키를 사용해 암호화된 데이터 전송
- 서버는 개인키로 이 데이터를 복호화, 세션 관리를 통해 클라이언트와의 지속적인 연결 유지
3. JWT 기반의 인증 시스템 & 로드 밸런서(LB)를 통한 서버 간 트래픽 분배
- Client
- 서버와 통신할 때 JWT를 사용해 인증 → 이 JWT는 클라이언트의 Local Storage에 저장
- JWT는 클라이언트가 서버와 상호작용할 때 서버에게 자신이 인증된 사용자임을 증명
- 클라이언트가 서버에 요청을 보낼 때, HTTP 헤더에 Authorization을 포함해 자신을 인증
- Local Storage
- 클라이언트가 로그인 후 서버로부터 받은 JWT를 Local Storage에 저장
- 이후 서버와의 모든 요청에는 이 JWT를 포함시켜 인증된 상태 유지
- LB
- 클라이언트의 요청을 여러 서버에 나누어 처리할 수 있도록 분배하는 역할
- 클라이언트는 특정 서버에 직접 연결되지 않고 LB를 통해 적절한 서버에 연결
- LB를 통해 트래픽이 고르게 분산돼서 서버 부하 줄일 수 있음
- Server
- LB를 통해 요청이 도착하면 서버는 JWT를 사용해 클라이언트의 인증 확인
- 서버는 자신이 가진 개인키로 JWT를 검증하여 클라이언트의 신원 확인
- 여러 서버가 동일한 역할을 해서 클라이언트는 LB를 통해 어떤 서버에 연결되든 상관없이 동일한 인증 과정 거침
JWT 기반 인증 과정
- 로그인 및 JWT 발급
- 사용자가 로그인 시도 → 서버는 사용자 인증 후 JWT 발급 (이 JWT는 클라이언트의 Local Storage에 저장)
- JWT 전송
- 이후 클라이언트는 서버에 요청을 보낼 때 JWT를 포함하여 전송 → 이 JWT는 클라이언트의 인증 정보를 담고 있고 요청 시마다 포함
- 서버에서 JWT 검증
- 서버는 클라이언트가 보낸 JWT를 자신의 개인키로 검증
- JWT 유효 → 요청 처리 / 유효 x → 인증 실패로 처리
- LB를 통한 요청 분배
- 클라이언트의 요청은 LB를 거쳐 여러 서버 중 하나로 분배
- 각 서버는 동일한 JWT 인증 절차 수행
정리
- 클라이언트는 JWT를 사용해 인증된 상태 유지, 요청이 들어올 때 서버는 JWT를 검증
- LB를 통해 서버에 트래픽을 분산시켜 서버 부하를 관리하는 구조
4. 카카오 OAuth 2.0 로그인
- 회원 정보 (JWT)
- 사용자의 회원 정보는 JWT 토큰을 이용해 관리됨
- 이 JWT는 사용자가 성공적으로 인증을 마친 후 발급, 이후 요청 시 인증 수단 사용
- Blog
- 사용자가 접근하는 서비스
- 사용자는 카카오를 통해 인증 완료, Blog는 이를 바탕으로 사용자에게 접근 권한 부여
- Blog는 사용자의 JWT를 확인 → 유효하면 서비스에 접근 가능하게 함
- Browser
- 사용자가 실제로 Blog에 접근하는 인터페이스
- 사용자는 브라우저를 통해 Blog에 로그인, 이 로그인 과정에서 카카오 OAuth 활용
- 사용자가 Blog에 로그인할 때 Blog는 카카오를 통해 사용자의 인증 정보 요청
- Kakao
- OAuth 2.0을 사용해 사용자 인증을 처리하는 역할
- 사용자가 카카오 계정으로 로그인 시도 시 카카오는 Access Token을 발급해서 Blog에 전달
- Blog는 카카오로부터 받은 Access Token을 이용해 사용자의 이메일, PK, 프로필 사진 등의 정보를 가져옴
- 인증 과정 요약
- 시용자가 Blog에 로그인 시도 시 브라우저는 Blog에 요청을 보냄
- Blog는 카카오에 사용자 인증을 위임, 카카오는 사용자에게 로그인 페이지를 출력
- 사용자가 카카오에 로그인 → 카카오는 Access Token을 발급해 Blog에 전달
- Blog는 이 Access Token을 사용해 카카오로부터 사용자의 정보를 요청하고 필요한 데이터 수신 (이메일, 사진 등)
정리
- 사용자는 카카오 계정으로 로그인
- Blog는 카카오로부터 Access Token을 받아 사용자의 정보를 안전하게 가져옴
- 이 과정은 사용자가 자신의 자격 증명을 Blog에 직접 제공하지 않고 카카오를 통해 위임된 방식으로 인증 진행
Share article
