Authentication과 Identity

Authentication은 “요청자가 주장한 identity가 맞는가”를 검증하는 절차이고, Principal은 검증 후 서버가 사용하는 실행 주체 표현이다.
로그인 보안은 비밀번호 해시 하나로 끝나지 않는다. 계정 식별자 처리, credential 검증, 위험 평가, 세션 발급, MFA, 실패 로그가 하나의 경계다.
공격자는 계정 열거, credential stuffing, session fixation, MFA fatigue, 실패 로그 누락을 이용해 인증 경계를 넘으려 한다.

Identity는 사용자나 시스템을 구분하는 속성이다. 이메일은 로그인 식별자가 될 수 있지만 변경 가능한 값이므로 내부 불변 subject id와 분리하는 편이 안전하다.
Credential은 identity 주장을 증명하는 값이다. 비밀번호, recovery code, OTP, passkey, client secret은 모두 credential이며 원문 저장과 로그 노출을 피해야 한다.
Principal은 인증 결과를 담는 객체다. principal에는 password, raw token, MFA secret 같은 credential 원문을 넣지 않는다.
로그인 흐름은 credential 수신, 계정 조회, credential 검증, 계정 상태 확인, 위험 평가, MFA 또는 step-up, 세션 발급, 감사 로그로 나누어 본다.
세션 ID는 bearer credential이다. 탈취되면 사용자를 가장할 수 있으므로 HttpOnly, Secure, SameSite, session fixation 방지, 만료, 폐기가 필요하다.
로그인 실패는 장애 로그가 아니라 공격 탐지 신호다. 계정별, IP별, 기기별, ASN별, 시간대별 실패 패턴을 구조화해야 credential stuffing을 볼 수 있다.

1. Authentication Identity Principal: identity, identifier, credential, principal, authority를 분리해 인증 결과가 권한으로 과장되지 않게 한다.
1. Login Flow와 Credential 검증: 로그인 API를 계정 열거와 credential stuffing에 강한 흐름으로 설계한다.
1. Session 기반 인증: 세션 ID의 발급, 쿠키 속성, fixation 방지, 폐기, 저장소 장애를 다룬다.
1. MFA와 계정 탈취 방어: MFA 등록, 검증, 해제, recovery code, 위험 기반 step-up을 별도 보안 이벤트로 본다.
1. 로그인 실패 Abuse와 운영 로그: 실패 이벤트를 단순 카운트가 아니라 공격 탐지와 대응 근거로 남긴다.

인증되면 권한도 충분하다고 생각하기 쉽다. 로그인 성공 후 principal이 생기기 때문이다.
- 핵심은 인증은 신원 확인이고, 인가는 특정 resource와 action에 대한 허용 판단이라는 점이다.
- principal이 있다고 해서 다른 사용자의 주문, 관리자 기능, 결제 변경을 할 수 있는 것은 아니다.
이메일을 사용자 ID로 그대로 쓰기 쉽다. 로그인 화면에서 이메일을 입력하기 때문이다.
- 핵심은 로그인 identifier와 내부 subject id를 분리하는 것이다.
- 이메일 변경, 소셜 로그인 연결, 계정 병합, 탈퇴 후 재가입에서 이메일만 믿으면 identity가 흔들린다.
MFA가 있으면 비밀번호와 세션 설계를 느슨하게 해도 된다고 생각하기 쉽다.
- 핵심은 MFA가 두 번째 방어선이지 첫 번째 방어선을 대체하지 않는다는 점이다.
- 비밀번호 해시, 실패 제한, 세션 보호, MFA 복구 절차가 함께 맞아야 한다.
로그인 실패 로그를 많이 남기면 충분하다고 보기 쉽다.
- 핵심은 원문 credential을 남기지 않으면서도 공격 패턴을 볼 수 있는 필드 구조다.
- identifier_hash, ip, user_agent_hash, result, reason, risk_score, trace_id가 분리되어야 한다.

Identity와 Principal의 차이는 무엇인가?
- Identity는 사용자를 구분하는 속성이고, Principal은 인증이 끝난 뒤 서버가 요청 처리에 사용하는 실행 주체 표현이다.
로그인 API의 실패 응답에서 조심해야 할 점은 무엇인가?
- 계정 존재 여부, 잠금 여부, 비밀번호 오류 여부를 공격자에게 구체적으로 알려 주지 않는 것이다.
세션 ID를 bearer credential로 보는 이유는 무엇인가?
- 세션 ID를 가진 쪽이 서버에서 인증된 사용자처럼 동작할 수 있기 때문이다.
로그인 실패 로그가 보안 설계인 이유는 무엇인가?
- credential stuffing, password spraying, 계정 열거, MFA abuse를 사후에 추적하고 자동 대응할 근거가 되기 때문이다.

동블