웹 인증 방식 총정리 (Authentication)

웹 서비스의 인증(Authentication)은 요청을 보낸 사용자가 누구인지 확인하는 절차이고, 인가(Authorization)는 확인된 사용자가 특정 자원에 접근할 권한이 있는지 판단하는 절차다. HTTP는 상태를 저장하지 않는 프로토콜이므로, 로그인 이후의 요청마다 사용자를 다시 식별할 수단이 필요하다. 이 문서는 세션 기반 인증, 토큰 기반 인증, API 키, OAuth를 큰 그림에서 비교하며 각 방식이 어떤 상황에 적합한지 정리한다.

왜 별도의 인증 상태 관리가 필요한가

HTTP의 무상태성(Statelessness)은 각 요청이 독립적으로 처리된다는 뜻이다. 서버는 직전 요청에서 누가 로그인했는지 기억하지 않으므로, 매 요청마다 아이디와 비밀번호를 다시 보내지 않는 한 사용자를 구분할 수 없다. 그러나 비밀번호를 매번 전송하는 것은 유출 위험을 키우고 사용자 경험도 나쁘다. 그래서 실제 서비스는 최초 로그인에서 자격 증명(Credential)을 한 번만 검증하고, 이후에는 그 검증 결과를 대신 증명하는 값을 주고받는다. 이 값을 서버가 보관하면 세션 방식이 되고, 클라이언트가 보관하면 토큰 방식이 된다. 이 저장 위치의 차이가 확장성, 무효화 가능성, 보안 특성의 차이로 이어진다.

세션 기반 인증

세션(Session) 방식은 로그인 성공 시 서버가 세션 저장소에 사용자 정보를 기록하고, 그 항목을 가리키는 무작위 세션 식별자(Session ID)를 쿠키(Cookie)로 클라이언트에 내려준다. 이후 브라우저는 요청마다 쿠키를 자동으로 첨부하고, 서버는 식별자로 저장소를 조회해 사용자를 알아낸다. 인증 상태의 원본이 서버에 있으므로, 관리자가 저장소에서 세션을 삭제하면 즉시 강제 로그아웃이 가능하다는 점이 큰 장점이다. 반면 서버가 상태를 들고 있어야 하므로 서버를 여러 대로 늘리면 세션 공유 문제가 생긴다. 보통 레디스(Redis) 같은 공용 세션 저장소를 두어 해결하지만, 그만큼 조회 비용과 운영 부담이 늘어난다. 전통적인 서버 렌더링 웹 서비스나 단일 도메인 서비스에 잘 맞는다.

토큰 기반 인증

토큰(Token) 방식은 로그인 성공 시 서버가 사용자 정보와 만료 시각을 담아 서명한 토큰을 발급하고, 클라이언트가 이를 보관했다가 요청 헤더의 Authorization 필드에 실어 보낸다. 대표 구현이 JWT(JSON Web Token)다. 서버는 서명만 검증하면 저장소 조회 없이 사용자를 식별할 수 있어 무상태 구조가 유지되고, 서버 확장이 쉬우며 모바일 앱이나 서로 다른 도메인의 API 호출에도 자연스럽다. 대신 이미 발급한 토큰은 만료 전까지 서버가 되돌릴 수 없다는 약점이 있다. 그래서 실무에서는 수명이 짧은 액세스 토큰(Access Token)과 수명이 긴 리프레시 토큰(Refresh Token)을 나누어, 액세스 토큰이 만료되면 리프레시 토큰으로 재발급받는 구조를 쓴다. 토큰의 상세 구조와 검증 원리는 JWT 문서에서 따로 다룬다.