로그인한 사용자가 URL의 주문 ID를 바꿔 다른 사람의 주문을 요청합니다. 로그인 확인만으로 충분하며, 인증과 인가를 어디에서 구분해 검사해야 하나요?

로그인 여부만 확인해서는 다른 사람의 주문 조회를 막을 수 없습니다. 인증 (authentication)은 요청을 보낸 주체가 누구인지 확인하는 과정이고, 인가 (authorization)는 그 주체가 특정 자원에 특정 작업을 할 수 있는지 판단하는 과정입니다. 따라서 서버는 검증된 세션이나 토큰에서 주체를 얻은 뒤, URL의 주문 ID와 그 주체의 소유자·테넌트·역할·주문 상태를 함께 검사해야 합니다. 이 객체 단위 검사가 빠져 다른 사용자의 객체를 읽거나 바꾸는 문제를 BOLA라고 부릅니다.

자원 경계에서 다시 판단합니다

예를 들어 GET /orders/42에서 토큰이 유효하다는 이유로 주문 42를 반환하면, 공격자는 ID만 바꿔 다른 주문을 읽을 수 있습니다. 사용자 ID를 요청 본문이나 query parameter로 받아 권한을 판단해서는 안 되고, 인증 미들웨어가 만든 주체 정보와 DB의 주문 소유자 또는 조직을 비교해야 합니다. 가능하면 조회 자체를 WHERE order_id = :id AND owner_id = :authenticated_user처럼 권한 조건과 함께 수행해 검사 후 조회 사이의 틈도 줄이겠습니다. 수정·삭제는 조회보다 더 강한 역할과 상태 조건을 가질 수 있습니다.

역할은 큰 범위의 정책을 표현하는 데 유용하지만, 역할만으로 자원 접근을 완성하지는 못합니다. ‘판매 담당자’라도 자기 조직의 주문만 수정하고, 정산이 끝난 주문은 관리자도 변경하지 못하는 식의 조건이 필요합니다. 역할처럼 주체의 속성으로 범위를 정하고 소유자·테넌트·상태 같은 자원 속성과 작업을 조합하는 방식을 속성 기반 접근 제어 (ABAC)라고 부릅니다. 정책을 중앙 서비스에서 결정하더라도 실제 주문을 아는 서비스가 최종 집행을 생략해서는 안 됩니다.

권한 최신성과 실패를 정합니다

토큰 서명이 유효하다는 것은 발급 당시의 일부 주장이 변조되지 않았다는 뜻이지, 지금도 권한이 최신이라는 뜻은 아닙니다. 일반 조회는 짧은 토큰 수명으로 권한 회수 지연을 허용할 수 있지만, 관리자 삭제·결제 수단 변경처럼 즉시 회수가 필요한 작업은 현재 세션 상태나 권한 버전을 다시 확인하겠습니다. 이 선택은 안전성과 저장소 의존성·지연의 교환이므로 작업별로 명시해야 합니다. 캐시가 권한 검사 뒤의 응답을 다른 사용자에게 주지 않도록 캐시 키에 주체와 테넌트 범위를 포함하거나 민감 응답을 캐시하지 않습니다.

검증은 정상 사용자뿐 아니라 같은 역할의 다른 사용자, 다른 테넌트, 존재하지 않는 주문, 권한 회수 직후, 읽기에서 수정으로 바꾼 요청을 시험합니다. 거절 로그에는 인증 정보 원문이 아니라 주체·자원·작업·정책 결과를 남기겠습니다. 핵심은 로그인 성공률이 아니라 모든 접근 경로에서 ‘누가 어떤 자원에 어떤 시점의 정책으로 무엇을 했는가’가 일관되게 집행되는지입니다.

API 계층마다 검사 책임도 구분하겠습니다. 게이트웨이는 토큰 형식과 기본 scope를 확인할 수 있지만, 주문 서비스는 주문 상태·소유 조직·허용된 작업을 직접 알아야 합니다. GraphQL처럼 한 요청에서 여러 객체를 읽는 인터페이스에서는 필드 하나의 노출도 별도 인가 대상이므로 목록 조회와 상세 조회의 권한이 같다고 가정하지 않습니다. 다운로드 URL이나 비동기 작업 상태 조회처럼 다른 endpoint로 우회할 수 있는 경로도 같은 정책을 적용해야 합니다. 실패 응답을 404로 숨길지 403으로 알릴지는 자원 존재 노출 위험과 클라이언트 계약으로 정하되, 어떤 상태 코드를 택하든 실제 자원 접근은 허용하지 않겠습니다.

권한 검사 결과를 캐시하는 경우에는 인증 주체·tenant·resource ID·정책 버전을 키에 포함하겠습니다. 그렇지 않으면 한 사용자의 주문 응답이나 허용 판정이 다른 사용자에게 재사용될 수 있습니다. 일괄 다운로드, export 파일, 웹소켓 subscription도 일반 상세 API와 같은 자원 범위로 취급하고, 비동기 작업 ID를 아는 것만으로 결과를 읽지 못하게 작업 소유권을 다시 검사합니다.