1. 기본 인증 (Basic Authentication)
- HTTP 초기부터 사용된 가장 기본적인 인증 방식이다.
- Base64로 인코딩된 사용자명과 비밀번호를 Authorization 헤더에 포함한다.
- 단점: 보안이 매우 취약하다 (Base64는 쉽게 디코딩 이 가능하다)
Salt,Pepper 작업을 해도 보안이 취약할까?
데이터에 추가 작업을 해줘도 보안은 여전히 취약하다.
인코딩 작업이 완료된 데이터는 여전히 노출되있고 손쉽게 디코딩할 수 있다.
base64 인코딩/디코딩 사이트
예를들어 다음과 같은 값을 인코딩하면 이런 값이 나오게 된다.
| 구분 | 값 |
|---|---|
| 원본 데이터 | username:password:Random_salt_3F8892 |
| Base64 인코딩 | dXNlcm5hbWU6cGFzc3dvcmQ6UmFuZG9tX3NhbHRfM0Y4ODky |
하지만 디코딩하면 다음과 같이 모든 값을 구분할 수 있게 된다.
| 구분 | 값 |
|---|---|
| 디코딩 전 데이터 | dXNlcm5hbWU6cGFzc3dvcmQ6UmFuZG9tX3NhbHRfM0Y4ODky |
| Base64 디코딩 | username:password:Random_salt_3F8892 |
| 사용자명 | username |
| 비밀번호 | password |
| 솔트값 | Random_salt_3F8892 |
2. 세션 기반 인증 (Session-based Authentication)
- 1990년대부터 널리 사용되었다.
- 서버에서 세션 ID를 생성하여 클라이언트에 쿠키로 전달하는 방식이다.
- 세션 정보를 Redis에 저장하여 관리하는 것이 일반적이다.
Redis (Remote Dictionary Server)
인메모리 데이터 스토어로, 고성능의 키-값 저장소이다.
빠른 읽기/쓰기 속도로 실시간 세션 처리에 적합하다.
자동 만료 기능으로 세션 수명 관리에 용이하다.
분산 환경에서 세션 공유가 쉽다.
- Redis 사용의 장점
- 메모리 기반으로 빠른 응답 속도
- 영구 저장소 대비 서버 부하 감소
- 클러스터링을 통한 확장성 제공
- 세션 데이터의 중앙 집중식 관리 가능
3. 토큰 기반 인증 (Token-based Authentication)
- 클라이언트가 서버로부터 토큰을 발급받아 인증에 사용하는 방식이다.
- 서버는 상태를 유지하지 않는 무상태(Stateless) 방식이다.
- 확장성이 좋고 서버 부하가 적다.
- 토큰 탈취 시 보안 위험이 있어 적절한 만료 시간 설정이 필요하다.
3.1 JWT (JSON Web Token)
2010년대 이후 널리 사용되는 토큰 표준
Header, Payload, Signature 3개 부분으로 구성된다.
Header: 토큰 타입과 알고리즘 정보
Payload: 사용자 정보와 메타데이터
Signature: 토큰의 유효성 검증을 위한 서명
- 장점
- 자체적으로 정보를 포함하여 DB 조회 불필요
- Base64로 인코딩되어 URL에서 사용 가능
- 다양한 언어에서 라이브러리 지원
- 단점
- 토큰 크기가 상대적으로 큼
- 한번 발급된 토큰은 만료 전까지 취소 어려움
- Payload가 암호화되지 않아 민감정보 포함 주의
3.2 OAuth
제3자 서비스 인증을 위한 표준 프로토콜
OAuth 1.0, 2.0 버전이 있으며 현재는 2.0이 표준이다.
인증 절차
1. 클라이언트가 사용자에게 인증 요청
2. 사용자가 인증 서버에서 인증
3. 인증 서버가 액세스 토큰 발급
4. 클라이언트가 토큰으로 리소스 접근
- 장점
- 검증된 대형 서비스의 인증 시스템 활용 가능
- 사용자 정보의 안전한 위임과 접근 제어
- 별도의 인증 시스템 구축 비용 절감
- 사용자에게 친숙한 로그인 경험 제공
- 단점
- 외부 서비스 의존성으로 인한 장애 가능성
- 구현 복잡도가 상대적으로 높음
- 인증 제공자의 정책 변경에 영향받음
- 네트워크 지연으로 인한 응답 시간 증가
- 활용 사례
- 소셜 로그인 (구글, 페이스북, 카카오 등)
- 외부 API 접근 권한 관리
- 서비스 간 안전한 인증 위임
4. 현대적인 인증 방식들
4.1 Multi-Factor Authentication (MFA)
- 여러 단계의 인증을 조합
- 비밀번호 + SMS/이메일 인증코드 등
4.2 Passwordless Authentication
- 이메일 매직 링크 (특정 링크로 접속시 인증 완료)
- 생체 인증 (지문, 얼굴인식)
4.3 API 키 인증
- 서버 간 통신에서 주로 사용
5. 최신 트렌드
5.1 OpenID Connect
- OAuth 2.0 기반의 ID 토큰 제공
- 구글, 페이스북 등 대형 서비스에서 사용
5.2 PASETO (Platform-Agnostic Security Tokens)
- JWT의 대안으로 등장
- 더 강력한 암호화 보장
보안 고려사항
-
HTTPS 사용 필수
- 모든 통신을 암호화하여 데이터 탈취와 변조를 방지
- SSL/TLS 인증서를 통한 서버 신원 확인
- 중간자 공격(MITM) 방지
-
토큰/세션 만료 시간 설정
- 인증 토큰과 세션에 적절한 만료 시간을 설정하여 보안 강화
- 장기간 미사용 세션의 자동 종료
- 토큰 갱신(refresh) 메커니즘 구현
-
CSRF(Cross-Site Request Forgery) 방어
- 사용자의 의도치 않은 요청을 방지
- CSRF 토큰 사용으로 요청 검증
- Same-Origin 정책 적용
- 중요 동작에 재인증 요구
-
XSS(Cross-Site Scripting) 방어
- 악성 스크립트 삽입 공격 방지
- 입력값 검증 및 이스케이프 처리
- Content Security Policy(CSP) 적용
- HttpOnly 쿠키 사용
-
비밀번호 해싱
- 안전한 해시 알고리즘 사용(bcrypt, Argon2 등)
- 솔트(Salt) 적용으로 레인보우 테이블 공격 방지
- 적절한 해싱 강도 설정
- 평문 비밀번호 저장 금지
-
레이트 리미팅
- API 호출 횟수 제한으로 서비스 남용 방지
- 무차별 대입 공격(Brute Force) 방어
- IP 기반 또는 사용자 기반 제한 설정
- 과도한 인증 시도 차단
비전공 개발 지망생의 벨로그입니다!