인증 · 인가

인증이란?

인증과 인가를 나눠 보기 시작하면 점검 지점이 달라집니다. 인증은 로그인 순간 한 번으로 끝나지만, 인가는 요청이 들어올 때마다 매번 다시 판단해야 하는 절차입니다. 로그인한 사용자가 주문 상세를 열 때도 서버는 '이 주문이 이 사람 것이 맞는지'를 그 자리에서 확인해야 합니다. 화면에서 메뉴와 버튼을 감추는 것은 인가가 아닙니다 — 주소를 직접 입력하거나 API를 그대로 호출하면 열리기 때문입니다.

수단과 모델을 갈라 두면 설계가 단순해집니다. 인증 수단은 비밀번호처럼 아는 것, OTP·패스키처럼 가진 것, 지문·얼굴처럼 신체에 붙은 것으로 나뉘고, 서로 다른 두 종류를 묶으면 다중요소인증(MFA)이 됩니다. 인가 쪽은 직책·부서에 권한을 묶는 RBAC(역할 기반)와 조건까지 따지는 ABAC(속성 기반)으로 갈립니다. 근무시간 외 접근 차단, 사내 IP에서만 대량 다운로드 허용 같은 규칙이 후자에 해당합니다. 이름 때문에 늘 헷갈리지만 OAuth 2.0은 인가 프로토콜이고, '누구인지'를 알려주는 신원 계층은 그 위에 얹는 OIDC입니다.

운영에서는 수명 관리가 실질적인 일감입니다. 액세스 토큰은 15~30분으로 짧게 두고 리프레시 토큰으로 갱신하는 구성이 흔하며, 권한의 기본값을 '거부'로 두고 필요한 것만 여는 최소권한이 기준선입니다. 그런데 더 자주 사고로 이어지는 쪽은 토큰이 아니라 계정입니다 — 퇴사·부서이동 시점에 권한이 같이 움직이는지가 실제 위험도를 가릅니다. 개인정보를 다루는 서비스라면 권한 부여·변경·말소 이력과 접속기록을 남겨 최소 1년 보관해야 합니다.

실제 사고는 대부분 인증은 통과했는데 인가 검사가 비어 있는 구간에서 터집니다. URL의 주문번호나 사용자 id를 1씩 바꿔 넣으면 남의 명세서가 그대로 열리는 유형이 대표적인데, 개발 단계에서는 테스트 계정 하나로만 확인하다 보니 배포 전까지 드러나지 않습니다. 관리자 계정을 팀이 돌려 쓰는 관행도 같은 뿌리입니다. 사고가 나도 누가 무엇을 언제까지 봤는지 증명할 수 없고, 그 순간 입증 책임은 고스란히 회사로 돌아옵니다.