쉬운 설명
당신이 누구인지 확인하는 게 인증이라면, 그 신원으로 무엇을 할 수 있는지를 정하는 게 인가입니다. 같은 사이트에서도 일반 사용자는 자기 글만 수정할 수 있고, 관리자는 다른 사람 글도 삭제할 수 있고, 결제 시스템은 환불을 만들 수 있습니다. 이 차이는 모두 인가에서 결정됩니다.
대표적인 모델 두 가지가 있습니다. ① RBAC(역할 기반 접근 통제): 'admin·editor·viewer' 같은 역할에 권한을 묶고 사용자에게 역할을 부여. 단순하고 흔함. ② ABAC(속성 기반): '소유자만 자기 글을 수정할 수 있다'처럼 사용자·자원·상황의 속성을 함께 보는 방식. 더 유연하지만 복잡함. 큰 시스템은 보통 두 가지를 섞어 씁니다.
정책을 어디에서 평가하느냐도 큰 결정입니다. ① 앱 코드 안에서 if 문으로(흩어져 관리 어려움), ② 라이브러리·미들웨어로 분리(Casbin·Cerbos·OPA), ③ 별도 인가 서비스로(중앙에서 결정 → 다른 서비스에 답을 줌). 회사가 커질수록 정책을 중앙화하는 방향으로 갑니다.
인가의 가장 위험한 함정은 'IDOR(Insecure Direct Object Reference)'입니다. URL의 ID를 바꿔서 다른 사람의 데이터에 접근하는 사고가 보안 사고 통계에서 항상 상위에 있습니다. 예: /orders/123이 내 주문이라면 /orders/124는 다른 사람의 주문일 수 있고, 인가 검사가 없으면 그대로 보입니다. 모든 자원 접근 시점마다 '이 사용자가 이걸 봐도 되는가'를 명시적으로 검사하는 습관이 필수입니다.
다른 자주 보이는 오류: 클라이언트 코드에서 '관리자 메뉴 숨기기'를 인가로 착각하는 것. 화면에 안 보여도 API 호출은 누구나 시도할 수 있습니다. 인가는 항상 서버 측에서, 모든 요청마다 확인해야 합니다. 또 '최소 권한 원칙(least privilege)' — 사용자·서비스에 필요한 최소한의 권한만 주는 것 — 이 인가 설계의 기본 가치입니다.
비유로 보면
인가는 회사 출입증의 등급과 비슷합니다. 같은 회사 출입증을 가졌어도, 일반 직원증으로는 사무실까지만 갈 수 있고, 임원 카드는 회의실 한 곳까지 더, 보안 카드는 서버실까지 갈 수 있습니다. 누구인지(인증)는 같지만, 어디를 갈 수 있는지(인가)가 다릅니다.
어디에서 만나나
모든 멀티 사용자 시스템 — SaaS, 회사 협업 도구, 클라우드 콘솔(AWS IAM·GCP IAM), 깃허브·노션 같은 공유 도구, 행정 시스템, 의료·금융 시스템. 권한이 정교할수록 인가 정책의 복잡도가 비례해 커집니다.
작은 예시
회사 협업 도구에서 같은 문서 링크를 두 사람에게 보내도, 편집자는 글을 고칠 수 있고 뷰어는 읽기만 됩니다. 두 사람은 모두 로그인(인증 완료)했지만, 인가가 다르게 적용돼서 가능한 행동이 달라진 것입니다.
자주 하는 오해
한 줄 정리
인가의 좋은 척도는 '최소 권한이 유지되는가'입니다. 누구나 자기 일에 필요한 최소한만 가지면, 사고의 영향 범위가 자연히 작아집니다.