인가
인증된 주체가 특정 리소스에 접근하거나 특정 작업을 수행할 수 있는 권리를 보유하고 있는지 확인하여 허가하는 프로세스.
— W3C 웹 어플리케이션 보안 아키텍처 가이드
"403 Forbidden 에러의 지배자. 로그인(인증)은 시켜줬는데 왜 보지를 못하니..." 실수로 관리자 권한 체크 로직에 느낌표(!) 하나 빼먹어서 유저 전체가 신의 권한을 얻는 사고가 종종 터진다.
1. 개요
신원이 확인된 주체(인증을 통과한 유저)에게 특정 자원에 접근하거나 특정 명령(수정, 삭제 등)을 내릴 수 있는 권한을 부여하고 검증하는 메커니즘이다. 영문 명칭은 Authorization, 약어로 AuthZ라고 약칭한다. 주로 역할 기반 접근 제어(RBAC)나 속성 기반 접근 제어(ABAC) 모델을 채택하여 설계된다.(...)
2. Unauthorized와 403 Forbidden의 잔인한 경계
백엔드 개발자가 API 서버를 설계할 때 전 세계 클라이언트 개발자들의 뚝배기를 깨버리는 주범 중 하나가 바로 [HTTP 상태 코드](http-status-code)인 401과 403을 대충 섞어 던지는 짓거리다. 스펙상 401 Unauthorized는 이름은 저 모양이어도 실질적으로는 '인증 없음'(너 로그인부터 하고 와라)을 의미한다. 반면 403 Forbidden은 너가 누군지(인증)는 알겠는데, 일개 일반 유저가 감히 VIP 메뉴나 어드민 API를 찌르니 '자격 없음'이라며 뺨을 때리는 엄연한 인가 실패 에러다. 이 둘을 제대로 구분하지 않고 프론트엔드에게 내려보내면, 프론트엔드 코드는 401을 받고 무한 로그아웃 루프에 빠지는 등 대환장 쇼가 펼쳐진다.(...)
3. 관련 밈 및 드립
3.1. 관리자 계정으로 테스트 중
실무에서 개발자가 인가 로직을 짤 때 귀찮다는 이유로 본인의 테스트 계정에 최고 존엄 'SUPER_ADMIN' 권한을 박아두고 지내는 행태를 뜻한다. 이 상태로 코딩을 하면 모든 권한이 다 뚫리니까 완벽하게 동작하는 줄 착각하고 무사히 배포했다가, 실서비스 오픈 당일 일반 유저들이 '수정 버튼이 안 눌려요', '화면이 안 보여요'라며 버그 제보 폭탄을 던지면 그제야 허겁지겁 인가 필터를 뜯어고치는 촌극을 의미한다.
4. 여담
- URL 인가의 취약점: 가끔 초짜 개발자들이 화면(Front-end)에서 메뉴만 숨겨두면 인가가 끝난 줄 아는데, 영악한 유저가 브라우저 주소창에
/admin/delete-user같은 백엔드 API 주소를 직접 찔러넣었을 때 서버측 2차 인가 검증이 없으면 그대로 실행되어 회사가 공중분해될 수 있다. - RBAC의 한계: '팀장' 권한이면 모든 결재 서류를 볼 수 있게 설계했더니, '옆 팀의 결재 서류'까지 인가 필터를 패스해 버리는 버그가 터져 부랴부랴 글의 소유주 ID까지 비교하는 세부 로직을 쑤셔 넣는 장인 정신 노가다가 수시로 수반된다.
- OAuth와 인가: 사실 우리가 흔히 쓰는 소셜 로그인의 근간 규격인 OAuth는 원래 '인증' 규격이 아니라, 내 구글 캘린더나 페이스북 사진에 접근할 수 있게 제3자 앱에게 권한을 위임하는 철저한 '인가' 프로토콜이다.