인증과 인가

상태 코드 구분이 실무에서 자주 틀립니다.

마지막이 판단이 필요한 자리입니다. 남의 문서 id 로 접근했을 때 403 을 주면 그 문서가 존재한다는 사실이 노출됩니다. 민감한 경우에는 404 로 응답해 존재 여부를 숨깁니다.

인가는 자원 단위로 확인해야 합니다. 로그인했다는 것만 확인하고 그 사용자가 그 자원의 소유자인지 검사하지 않으면, id 만 바꿔 남의 데이터를 볼 수 있습니다.

흔한 실수: 인가 검사를 화면에서만 하는 것. 버튼을 숨기는 것은 표시일 뿐이고, API 를 직접 부르면 그대로 통과합니다. 검사는 서버의 각 엔드포인트에서 해야 합니다.

비밀번호를 남에게 주지 않고 제한된 권한만 위임하는 규약입니다.

가장 많이 쓰는 인가 코드 흐름입니다.

3번과 4번을 나눈 이유가 핵심입니다. 코드는 URL 로 노출되지만 그것만으로는 토큰을 못 얻습니다. 서버의 비밀키가 함께 필요하므로, 브라우저 이력이나 로그에 코드가 남아도 탈취만으로는 쓸 수 없습니다.

브라우저나 모바일 앱처럼 비밀키를 숨길 수 없는 곳에서는 PKCE 를 함께 씁니다. 처음에 만든 임의 값의 해시를 보내고 교환 시 원본을 제시해, 코드를 탈취한 쪽이 쓸 수 없게 만듭니다.

흔한 실수: OAuth 를 인증 규약으로 답하는 것. OAuth 2.0 은 인가를 위한 규약이고, 로그인에 쓰려면 그 위에 얹은 OpenID Connect 를 씁니다.

구분하는 지점은 누가 누구를 대신하는가입니다.

각자의 약점도 함께 봅니다.

흔한 실수: JWT 를 API 키처럼 길게 발급하는 것. 무효화가 어려운 방식에 긴 유효 기간을 주면 유출 시 대응할 방법이 없습니다. 짧게 주고 리프레시로 갱신하는 구조가 함께 가야 합니다.

RBAC 의 한계가 드러나는 자리가 있습니다. "본인이 작성한 글만 수정 가능" 같은 규칙은 역할로 표현되지 않습니다. 역할은 사용자에게 붙는 속성이고, 이 규칙은 사용자와 자원의 관계에 달려 있습니다.

그래서 실무에서는 둘을 섞습니다.

이렇게 나누면 역할 수를 적게 유지하면서 세밀한 통제가 됩니다.

흔한 실수: 예외 상황마다 역할을 새로 만드는 것. "부서장", "부서장 조회전용", "타부서 부서장" 같은 역할이 늘어나면 누가 무엇을 할 수 있는지 아무도 모르게 됩니다. 관계 기반 검사로 옮길 것을 구분해야 합니다.