<aside>

</aside>

안녕하세요! 드디어 6부 '인증 및 보안'의 마지막 시간, 31강입니다! 🥳🔐

지난 30강에서는 JWT 토큰을 검증하고 get_current_user 의존성을 만들어, 우리 /tasks API 엔드포인트들을 인증된 사용자만 접근할 수 있도록 보호했습니다. 이제 우리 API는 요청을 보낸 사용자가 누구인지(인증) 확실히 알 수 있게 되었어요!

하지만 사용자가 누구인지 아는 것만으로는 충분하지 않을 때가 많습니다. 예를 들어, 'A' 사용자가 'B' 사용자가 작성한 할 일을 마음대로 수정하거나 삭제할 수 있다면 문제가 되겠죠? 또는 '관리자'만 접근해야 하는 특별한 기능이 있을 수도 있습니다. 이렇게 인증된 사용자가 **무엇을 할 수 있는지(권한)**를 제어하는 것을 **인가(Authorization)**라고 합니다.

이번 시간에는 바로 이 **인가(Authorization)**의 기초를 구현해 봅니다. 가장 흔한 두 가지 패턴인 소유권(Ownership) 기반 접근 제어 (내 할 일은 나만!)와 역할 기반 접근 제어(RBAC) 의 아주 간단한 형태 (관리자 구분)를 우리 ToDo API에 적용해 보겠습니다. API의 보안을 더욱 강화하고 사용자의 데이터를 안전하게 지키는 방법을 배워봅시다! 🧐

📚 챕터 소개

이번 31강에서는 30강에서 구현한 사용자 인증(Authentication)을 바탕으로, 인가(Authorization), 즉 접근 제어 기능을 구현하는 기본적인 방법을 배웁니다. 인증이 '누구인가?'를 확인하는 것이라면, 인가는 '무엇을 할 수 있는가?'를 결정하는 과정입니다.

먼저, 가장 일반적인 인가 패턴 중 하나인 소유권(Ownership) 기반 접근 제어를 구현합니다. 사용자가 자신의 할 일(Task) 데이터만 조회, 수정, 삭제할 수 있도록 tasks 라우터의 관련 엔드포인트 로직을 수정합니다. 데이터베이스 쿼리 시 현재 로그인된 사용자의 ID(current_user.id)와 Task의 소유자 ID(owner_id)를 비교하는 조건을 추가하여 이를 구현합니다.

다음으로, **역할 기반 접근 제어(Role-Based Access Control, RBAC)**의 아주 기초적인 형태를 구현해 봅니다. User SQLAlchemy 모델에 is_admin 과 같은 불리언(boolean) 필드를 추가하고, 이 스키마 변경 사항을 Alembic 마이그레이션을 통해 데이터베이스에 반영합니다. 그리고 이 is_admin 플래그를 확인하여 관리자 권한을 요구하는 간단한 **의존성 함수(require_admin)**를 만들고, 이를 사용하여 관리자 전용 API 엔드포인트를 보호하는 예제를 구현합니다.

마지막으로, 인증 실패 시 반환되는 401 Unauthorized 와 인가 실패 시 반환되는 403 Forbidden 상태 코드의 의미 차이를 명확히 정리합니다.

🎯 챕터 목표

이 강의를 마치면 여러분은 다음을 할 수 있게 됩니다:

1. **인가(Authorization)**의 개념과 인증(Authentication)과의 차이를 명확히 설명할 수 있습니다.
2. 소유권(Ownership) 기반 접근 제어 로직을 구현하여 사용자가 자신의 데이터만 조작하도록 제한할 수 있습니다. (Task 엔드포인트 수정)
3. SQLAlchemy 모델에 역할/권한 관련 필드(예: is_admin)를 추가하고 Alembic으로 스키마 변경을 관리할 수 있습니다.
4. 특정 역할(예: 관리자)을 요구하는 간단한 의존성 함수를 만들 수 있습니다.
5. 의존성을 사용하여 관리자 전용 엔드포인트를 구현하고 보호할 수 있습니다.
6. 401 Unauthorized와 403 Forbidden HTTP 상태 코드의 차이점을 이해합니다.