백엔드 인증·인가 설계: 세션·JWT와 권한 모델 선택 기준

“세션과 JWT 중 무엇을 골라야 나중에 다시 만들지 않을까?”

“관리자 메뉴를 숨겼는데도 API 권한을 따로 확인해야 할까?”

“역할이 늘어나면 권한 모델을 어떻게 바꿔야 할까?”

세션과 JWT는 유행이 아니라 로그인 상태를 어떻게 보관·폐기할지로 선택하고, 인가는 서버 API가 요청자·행동·리소스·조건을 기준으로 최종 판단하도록 분리해야 합니다. 먼저 로그인 상태를 즉시 무효화해야 하는지와 호출 주체가 누구인지를 정한 뒤, 역할만으로 부족한 조건을 권한 정책에 추가하는 순서가 핵심입니다.

인증(authentication)은 요청자가 누구인지 확인하는 일이고, 인가(authorization)는 그 요청자가 해당 작업을 해도 되는지 판단하는 일입니다. 로그인에 성공했다는 사실과 게시글을 수정할 수 있다는 권한은 같은 문제가 아닙니다. 둘을 단일 isAdmin 값으로 묶으면 역할·조직·소유자 조건이 늘어날 때 변경 범위를 파악하기 어려워집니다.

세션과 JWT 중 무엇을 선택해야 할까요?

로그인 상태를 즉시 통제해야 하는 브라우저 중심 서비스는 세션을 먼저 검토하고, 여러 서비스나 클라이언트가 토큰을 검증하는 경계가 분명하다면 JWT를 검토할 수 있습니다. 다만 JWT를 선택해도 로그아웃, 차단, 권한 변경 반영 정책은 별도로 결정해야 합니다.

세션 기반 인증은 서버가 세션 기록을 관리하고 클라이언트에 세션 ID를 전달한 뒤 요청마다 저장된 세션 데이터를 참조하는 방식입니다. JWT는 사용자 식별자·역할·만료 시간 같은 클레임을 담아 서명하고, 서버가 서명과 클레임을 검증하는 방식입니다. JWT는 서버 측 상태를 별도로 관리하지 않으면 만료 전 개별 토큰을 즉시 폐기하기 어렵고, 토큰에 든 권한 변경도 기존 토큰이 만료될 때까지 반영되지 않을 수 있습니다. 짧은 액세스 토큰 수명, 블랙리스트, 리프레시 토큰 폐기, 서버 API를 통한 동적 권한 검증은 이를 완화하는 선택지입니다. 출처: JWT 대 세션 인증

다음 표는 기술의 우열이 아니라 운영 요구를 정리하기 위한 선택표입니다.

‘세션은 확장할 수 없고 JWT는 무조건 확장된다’처럼 단정할 필요는 없습니다. 다중 인스턴스 환경이라면 어느 방식을 쓰든 로그인 상태, 키, 폐기 정책이 여러 서버에서 일관되게 동작해야 합니다. 기술을 고르기 전에 로그아웃 요구, 권한 변경 빈도, 클라이언트 구성을 문장으로 적어 보세요.

역할 하나로 부족해질 때 권한 모델은 어떻게 확장할까요?

초기에는 역할과 권한을 분리한 RBAC로 시작하고, 소유자·조직·상태 같은 조건이 생길 때 리소스 검사를 추가하는 편이 관리하기 쉽습니다. 모든 조건을 토큰의 단일 역할 문자열로 표현하면 예외가 쌓이기 쉽습니다.

admin, member처럼 역할만 필요한 서비스라면 역할이 권한 묶음을 갖는 RBAC 구조가 읽기 쉽습니다. 권한은 post:read, post:update, user:manage처럼 행동과 대상이 드러나는 이름으로 두면 API와 정책을 연결하기 편합니다.

다만 다음 조건은 역할만으로 표현하기 어렵습니다.

• 작성자는 자신의 게시글만 수정할 수 있다.
• 조직 관리자는 자기 조직의 구성원만 관리할 수 있다.
• 특정 상태의 주문은 제한된 역할만 변경할 수 있다.

이런 API는 역할 확인 뒤 리소스의 소유자 ID, 조직 ID, 상태를 확인하는 정책을 둘 수 있습니다. 처음부터 거대한 정책 엔진을 만들기보다 API가 늘어날 때 주체, 행동, 리소스, 조건을 분리해 이름 붙이는 것부터 시작하는 편이 좋습니다.

게시글 수정 API의 판단 순서는 다음처럼 정리할 수 있습니다.

1. 인증 정보를 검증해 요청자의 사용자 ID를 얻습니다.
2. post:update 권한이 있는지 확인합니다.
3. 대상 게시글을 조회합니다.
4. 일반 작성자라면 게시글 소유자와 요청자 ID가 같은지 확인합니다.
5. 정책을 통과한 경우에만 변경을 수행합니다.

조직 단위 서비스라면 ‘관리자’라는 역할만 저장하기보다 어느 조직에서의 관리자 역할인지까지 모델에 포함해야 판단 범위가 분명해집니다.

프론트엔드에서 메뉴를 숨기면 인가도 끝난 걸까요?

아닙니다. 메뉴·버튼·라우트 가드는 화면 경험을 위한 제어이고, API의 허용 여부는 서버 정책에서 다시 판단하도록 설계해야 합니다. 클라이언트가 전달한 역할값이나 사용자 ID만을 최종 판단값으로 삼지 않는 것이 이 글의 설계 기준입니다.

김알레오는 프론트엔드 개발자로서 서비스 화면과 사용자 흐름을 다룹니다. 이 관점에서 권한 없는 버튼을 보여주지 않고, 권한 부족 상태를 자연스럽게 안내하는 처리는 필요합니다. 그러나 화면 제어와 API 정책을 같은 책임으로 섞지 않아야 화면 변경이 서버의 권한 판단을 대신하는 구조가 되지 않습니다.

프론트엔드와 백엔드가 합의할 계약은 다음과 같습니다.

• 인증되지 않은 요청과 권한 없는 요청을 API 응답에서 어떻게 구분할지 정합니다.
• 권한 부족 응답을 받았을 때 재로그인, 안내 문구, 이전 화면 이동 중 어떤 흐름을 제공할지 정합니다.
• UI 표시를 위해 권한 목록을 내려주더라도 서버의 최종 검사와 별개임을 문서화합니다.
• 권한 변경이 기존 로그인 상태에 언제 반영되는지 정합니다.

인가 규칙의 원본은 화면이 아니라 서버 정책이어야 합니다. 화면은 정책을 이해하기 쉽게 표현하고, API는 그 정책을 실제 요청에 적용하는 역할을 맡습니다.

구현 전에 어떤 기준으로 결정하면 될까요?

핵심은 ‘어떤 기술을 쓰는가’보다 로그인 상태를 언제 무효화하고, 어떤 조건에서 누가 어떤 리소스를 다룰 수 있는지 문서화하는 일입니다. 이 기준이 정리되면 세션과 JWT, RBAC와 리소스 조건 검사는 경쟁하는 선택지가 아니라 서로 다른 책임을 맡게 됩니다.

구현 전에는 다음 네 가지를 확인하세요.

1. 로그인 상태를 즉시 무효화해야 하는 상황은 무엇인가?
2. 인증 정보를 사용하는 클라이언트와 서비스는 몇 종류인가?
3. 역할 외에 소유자·조직·상태 조건이 필요한 작업은 무엇인가?
4. 권한 없는 요청을 API와 화면에서 각각 어떻게 처리할 것인가?

특히 권한 변경이 잦거나 조직별 정책이 다른 서비스라면 토큰에 무엇을 넣을지보다 최신 권한을 어느 시점에 확인할지를 먼저 정하는 편이 낫습니다. 반대로 역할이 단순하고 브라우저 요청이 중심인 초기 서비스라면, 명확한 서버 검사와 이해하기 쉬운 모델을 우선한 뒤 요구가 늘어날 때 확장할 수 있습니다.

자주 묻는 질문

JWT를 쓰면 서버에 로그인 상태를 저장하지 않아도 되나요?

반드시 그렇지는 않습니다. JWT의 서명 검증과 별개로 로그아웃, 토큰 폐기, 권한 변경 반영 요구가 있다면 상태 관리 또는 별도 정책이 필요할 수 있습니다.

역할은 토큰에 넣어도 되나요?

넣을 수는 있지만 권한 변경 빈도와 토큰 수명을 함께 고려해야 합니다. 토큰 발급 뒤 역할이 바뀔 수 있다면 역할값을 언제까지 신뢰할지와 최신 권한을 어디서 확인할지를 정해야 합니다.

403 응답을 받으면 프론트엔드는 무엇을 해야 하나요?

권한 부족 상태를 안내하고 해당 작업을 계속 시도시키지 않는 흐름을 준비해야 합니다. 응답 형식, 재시도 여부, 이동 경로는 제품의 인증 정책과 화면 구조에 맞춰 백엔드와 합의합니다.

작은 서비스도 권한 테이블을 따로 만들어야 하나요?

초기에는 역할 컬럼과 명확한 서버 검사로 시작할 수 있습니다. 역할별 예외가 늘거나 조직·소유자 조건이 반복될 때 역할과 권한을 분리하는 모델을 검토하면 됩니다.

제 도움이 필요하시다면

프론트엔드와 백엔드 사이에서 인증 상태, 권한 부족 화면, 보호된 라우트의 책임을 나누는 작업을 도울 수 있습니다. 로그인 이후 화면 전환, 권한별 UI 노출, API 오류 상태의 사용자 흐름이 어긋난다면 API 계약과 화면 처리 기준을 함께 점검할 수 있습니다.

다만 토큰 키 관리, 서버 인프라, 보안 사고 대응 정책처럼 백엔드 운영 환경의 최종 결정은 해당 시스템을 책임지는 백엔드·보안 담당자와 함께 검토하는 것이 적절합니다.