인가 (Authorization)

인가(Authorization)는 사용자나 프로그램이 특정 자원에 특정 작업을 수행할 권한이 있는지 판단하는 과정입니다. 접속한 사람이 누구인지 확인하는 인증과 구별되며, 같은 계정이라도 읽기와 수정 권한은 다를 수 있습니다. 실제 요청을 처리할 때 대상 자원과 허용된 행동, 소유 관계를 함께 확인합니다.

자원과 행동을 기준으로 하는 판단

문서 작성자는 자기 초안을 고칠 수 있지만 다른 팀의 문서는 읽기만 하도록 서비스를 만들 수 있습니다. 이때 계정이 존재한다는 사실만으로 수정 요청을 허용하지 않습니다. 누가 요청했는지, 어느 문서를 대상으로 하는지, 어떤 변경을 하려는지를 조합해 판단합니다. 화면에 편집 버튼을 보여 줄지도 이 권한과 연결되지만, 버튼의 표시만으로 서버의 접근 통제를 대신할 수는 없습니다.

OWASP의 인가 지침은 인증과 인가를 구별하고 요청마다 권한을 검증하도록 설명합니다. 인증을 마친 일반 이용자에게 관리자 기능까지 허용되는 것은 아닙니다. 반대로 공개 문서를 읽는 기능은 로그인하지 않은 이용자에게 허용할 수도 있습니다. 인증 여부와 접근 가능한 범위를 따로 설계해야 이 두 상황을 모두 표현할 수 있습니다.

역할을 이용하면 편집자와 관리자처럼 업무별 권한을 묶을 수 있습니다. 같은 편집자라도 자기 조직의 문서만 다루게 하려면 역할뿐 아니라 조직과 소유 관계도 확인합니다. 권한 이름 하나에 너무 많은 행동을 묶으면 읽기만 필요한 작업에 삭제 권한까지 따라갈 수 있습니다. 필요한 자원과 작업을 구체적으로 나누는 것이 최소 권한 원칙을 적용하는 출발점입니다.

토큰과 권한 범위의 관계

OAuth 2.0 명세 RFC 6749는 접근 범위를 나타내는 scope와 접근 토큰을 설명합니다. 사용자가 외부 앱에 특정 기능의 이용을 허용하면 그 범위 안에서 자원에 접근하도록 구성할 수 있습니다. 읽기와 쓰기에 어떤 scope 이름을 쓰는지는 서비스가 정하므로, 다른 서비스의 권한 문자열을 그대로 옮긴다고 같은 뜻이 되지는 않습니다.

토큰이 있다는 사실과 요청한 작업이 허용된다는 사실도 구분됩니다. 만료된 토큰이거나 대상 서비스가 다르거나 필요한 범위가 없으면 요청이 거절될 수 있습니다. 토큰 발급 때 허용한 범위와 실제 자원에 적용되는 정책을 함께 확인해야 원인을 좁힐 수 있습니다. 개인 계정으로 성공한 호출을 자동화 계정으로 옮길 때도 두 계정의 권한이 같다고 가정하지 않습니다.

MDN의 Authorization 헤더 설명은 이 헤더로 서버가 사용자를 인증하는 데 필요한 자격 증명을 전달할 수 있다고 설명합니다. 헤더 이름에 Authorization이 들어 있다고 그 값 자체가 모든 인가 판단을 끝내는 것은 아닙니다. 인증 방식에 맞는 정보를 보낸 뒤 서버가 자원별 접근 정책을 적용하는 흐름으로 이해하면 이름 때문에 두 절차를 혼동하는 일을 줄일 수 있습니다.

권한 변경과 검증 범위

팀에서 빠진 계정이나 역할이 바뀐 계정은 이전 권한을 계속 사용할 수 있는지 확인할 대상입니다. 화면에서는 권한이 사라졌는데 이미 발급한 토큰이나 오래된 권한 정보가 계속 사용될 수도 있습니다. 권한 정보의 갱신 시점과 기존 접근 수단을 회수하는 방식은 서비스별로 다릅니다. 운영 기록에는 누구의 어떤 권한을 바꿨는지와 실제 요청에서 변경이 적용됐는지를 구분해 남깁니다.

권한 검증은 허용되는 요청과 거부되는 요청을 함께 확인합니다. 작성자가 자기 문서를 수정하는 경우만 성공해도 다른 사람의 문서 ID를 넣었을 때 접근이 막히는지는 알 수 없습니다. 로그인하지 않은 상태, 다른 조직 계정, 읽기 전용 계정처럼 경계를 나누면 빠진 검사를 발견하기 쉽습니다. 요청을 거부하는 경로에서도 원본 데이터가 변경되지 않았는지 살펴봅니다.

AI 에이전트가 API를 호출하는 경우에는 에이전트가 쓰는 계정과 자격 증명의 권한이 실제 실행 범위를 정합니다. 프롬프트에 읽기만 하라고 적는 것과 서버가 쓰기 요청을 거부하는 것은 서로 다른 제어입니다. 작업에 필요한 범위의 자격 증명을 제공하고 실행 기록에 대상과 결과를 남기면, 요청한 작업과 실제 허용 범위를 대조할 수 있습니다.