OAuth 로그인 점검: state·PKCE·세션·권한 구분
OAuth와 OIDC 역할을 구분하고 로그인 실패를 단계별로 추적하는 점검표입니다.
OAuth는 접근 권한 위임을 다루는 프레임워크이며 사용자 로그인 자체와 같은 말은 아닙니다. 로그인에는 OAuth 위에 신원 정보를 다루는 OpenID Connect(OIDC)를 사용하는 구성이 흔합니다. 장애를 조사할 때도 인가 흐름, 신원 검증, 앱 세션, 리소스 권한을 나누어 봐야 합니다.
어디에서 실패했는지 단계 나누기
| 단계 | 확인할 항목 | 기록하면 안 되는 것 |
|---|---|---|
| 인가 요청 시작 | 등록된 redirect URI, 요청 연계 정보 | 비밀키 |
| 콜백 수신 | state 검증, 예상한 요청과의 연결 | 코드·토큰 원문 |
| 코드 교환 | PKCE 검증자와 클라이언트 설정 | 교환 응답 전체 |
| 신원 확인 | 발급자·대상·서명·만료 등 라이브러리 검증 | ID 토큰 원문 |
| 앱 세션 | 쿠키 전달과 만료 조건 | 세션 값 |
state와 PKCE는 각각의 역할을 이해하고 지원되는 검증된 라이브러리로 구현합니다. OIDC에서는 흐름에 맞는 nonce 검증 등도 필요합니다. 직접 토큰 문자열을 풀어 사용자 ID만 읽는 방식은 신원 검증이 아닙니다.
로그인됐는데도 접근이 안 된다면
인증은 누구인지 확인하는 것이고 인가는 그 사람이 특정 자원에 접근할 수 있는지 판단하는 것입니다. 로그인 성공 후에도 주문의 소유자나 조직 소속을 서버에서 확인해야 합니다. 화면에서 버튼을 숨기는 것은 권한 검사가 아닙니다.
가상의 문서 서비스라면 사용자 / 문서 / 읽기·수정·삭제 표를 만들고 다른 사용자의 문서 ID로 접근했을 때 거부되는지 테스트합니다. Django 기본 모델 권한을 쓴다고 개별 객체 소유권까지 자동으로 해결되는 것은 아닙니다.
세션과 비밀번호는 별도 경계
HTTPS 배포에서는 세션 쿠키의 보안 속성과 프록시 설정을 확인합니다. 콜백 이후 쿠키가 전달되지 않는 문제를 OAuth 제공자 장애로 오해할 수 있습니다. 브라우저 정책과 도메인, SameSite 조건을 함께 확인하세요.
직접 비밀번호를 관리한다면 프레임워크의 안전한 저장과 검증 기능을 사용합니다. 복잡한 문자 규칙을 늘리는 것만으로 계정 탈취를 막을 수는 없습니다. 재설정, 시도 제한, 다중 인증 등 계정 전체 흐름을 검토합니다.
진단 결과 남기기
‘로그인 실패’ 대신 어느 단계에서 어떤 오류 코드가 발생했는지, 배포 버전과 등록 URI가 일치하는지 기록합니다. 토큰이나 인증 코드를 로그에 넣지 않고도 단계별 성공·실패를 추적할 수 있습니다. 상세 기록 기준은 개인정보를 제외한 로그 설계를 참고하세요.