로그인 이후에 일어나는 일을 구분해보자
백엔드 개발을 하다 보면 인증과 인가라는 용어를 자주 접하게 된다. 두 개념은 함께 언급되는 경우가 많지만, 실제로는 역할과 책임이 명확히 다르다. 이 차이를 명확히 이해하지 못하면 보안 설계나 API 설계에서 혼란이 생기기 쉽다. 이 글에서는 인증과 인가의 개념을 분리해서 정리한다.
인증(Authentication)이란 무엇인가
인증은 사용자가 누구인지 확인하는 과정이다.
시스템 입장에서 보면 “이 요청을 보낸 주체가 누구인가”를 검증하는 단계다.
대표적인 인증 예시는 다음과 같다.
- 아이디와 비밀번호 로그인
- 토큰(JWT) 검증
- OAuth 로그인(Google, GitHub 등)
- 인증서 기반 인증
인증의 결과는 보통 다음 질문에 대한 답이다.
- 이 사용자는 누구인가
- 이 사용자는 신뢰할 수 있는가
인가(Authorization)란 무엇인가
인가는 인증된 사용자가 무엇을 할 수 있는지 결정하는 과정이다.
즉, 권한을 검증하는 단계다.
대표적인 인가 예시는 다음과 같다.
- 관리자만 접근 가능한 API
- 본인 데이터만 조회 가능
- 특정 역할(Role)만 수행 가능한 기능
인가의 핵심 질문은 다음과 같다.
- 이 사용자가 이 작업을 수행할 수 있는가
인증과 인가의 핵심 차이
두 개념의 차이를 간단히 정리하면 다음과 같다.
- 인증
- 누구인지 확인
- 신원 확인 단계
- 로그인, 토큰 검증
- 인가
- 무엇을 할 수 있는지 결정
- 권한 확인 단계
- 역할, 권한, 정책 기반
인증이 먼저 수행되고, 그 다음에 인가가 수행된다.
흐름으로 보는 인증과 인가
일반적인 요청 흐름은 다음과 같다.
- 사용자가 요청을 보냄
- 인증 수행
- 토큰 유효성 확인
- 사용자 식별
- 인가 수행
- 요청한 자원에 대한 권한 확인
- 요청 처리 또는 거부
인증에 실패하면 인가 단계까지 도달하지 않는다.
인증만 있고 인가가 없는 경우
다음과 같은 구조는 위험할 수 있다.
- 로그인만 하면 모든 API 접근 가능
- 사용자 구분은 있지만 권한 구분 없음
이 경우 시스템은 다음 문제를 가진다.
- 일반 사용자가 관리자 기능 접근 가능
- 데이터 노출 위험 증가
인증과 인가는 반드시 함께 설계되어야 한다.
인가만 있고 인증이 없는 경우
일반적인 웹 서비스에서는 거의 사용되지 않는다.
누구인지 모르는 상태에서 권한을 판단할 수 없기 때문이다.
다만 내부 시스템이나 특정 네트워크 기반 접근 제어에서는 제한적으로 사용될 수 있다.
HTTP 관점에서의 차이
HTTP 응답 코드에서도 인증과 인가는 구분된다.
- 401 Unauthorized
- 인증 실패
- 신원 확인 불가
- 403 Forbidden
- 인증은 성공
- 권한이 없음
이 차이를 명확히 사용하는 것은 API 설계에서 중요하다.
JWT 기반 시스템에서의 인증과 인가
JWT를 사용하는 경우 흐름은 다음과 같다.
- 인증
- 토큰 서명 검증
- 토큰 만료 여부 확인
- 인가
- 토큰 내부의 역할(Role), 권한(Scope) 확인
JWT는 인증 정보와 인가 정보를 함께 담을 수 있지만, 두 개념은 여전히 분리해서 이해해야 한다.
인증과 인가를 분리해서 설계해야 하는 이유
두 개념을 분리하면 다음과 같은 장점이 있다.
- 보안 정책 명확화
- 권한 변경 시 인증 로직 수정 불필요
- 역할 기반 접근 제어 확장 용이
특히 MSA 환경에서는 인증과 인가의 경계가 더욱 중요해진다.
언제 헷갈리기 쉬운가
다음 상황에서 혼동이 자주 발생한다.
- 로그인 기능 구현 시
- 관리자 권한 처리 시
- OAuth, JWT, API Gateway 도입 시
이때 “지금 하는 작업이 인증인지 인가인지”를 구분하면 설계가 명확해진다.
정리
인증은 사용자가 누구인지 확인하는 과정이고, 인가는 그 사용자가 무엇을 할 수 있는지를 결정하는 과정이다. 인증이 없으면 인가는 의미가 없고, 인가가 없으면 인증은 불완전해진다. 두 개념을 명확히 구분하는 것은 보안과 API 설계의 기본이다. 다음 글에서 다룰 OAuth 2.0 동작 흐름 역시 이 인증과 인가의 개념을 이해하고 나면 훨씬 쉽게 접근할 수 있다.