인증 시리즈 (1부): 애플리케이션 엔지니어링 실무

소개

인터넷 애플리케이션, 특히 기업 내부 애플리케이션에서 데이터 접근과 사용자 프라이버시를 보호하기 위해 인증은 중요한 역할을 합니다. 이번 글에서는 다양한 관점에서 인증을 탐구하며, 특히 애플리케이션 엔지니어링에서의 인증 실습에 초점을 맞출 것입니다.

다양한 애플리케이션에서 인증은 주로 다음 두 가지 기술을 사용합니다:

쿠키 & 세션: 이 전통적인 인증 메커니즘은 주로 브라우저 내에서 사용되며, 쿠키와 세션을 통해 사용자 신원을 확인하고 세션 상태를 유지합니다.
Bearer 토큰: 이는 더 현대적인 인증 메커니즘으로, 브라우저 쿠키에 의존하지 않고 HTTP 프로토콜을 사용하여 인증을 수행합니다. 특히 API 시나리오에 적합하며, 모바일 애플리케이션에서도 사용할 수 있습니다.

어떤 방법을 선택하든, 개발자는 제품에 적합한 인증 방식을 선택하여 데이터 보안, 사용자 프라이버시, 그리고 원활한 사용자 경험을 보장해야 합니다.

전통적인 웹 애플리케이션

과거에는 Java JSP를 사용하여 웹 애플리케이션을 직접 구축했으며, JSESSIONID라는 세션 ID를 사용하여 사용자를 식별했습니다. 이 세션 ID는 클라이언트 브라우저의 쿠키에 저장되고 각 요청과 함께 전송됩니다.

그러나 이 방식에는 몇 가지 문제가 있었습니다. 쿠키는 브라우저에 의해 클라이언트 장치에서 관리 및 저장되기 때문에, 악의적인 공격자가 저장된 세션 ID를 훔쳐 사용자를 사칭할 수 있어 보안 위험이 있었습니다. 또한, 개발자들은 때때로 쿠키와 세션에 대한 적절한 만료 기간과 보안 요구 사항을 설정하는 데 어려움을 겪었습니다.

이러한 애플리케이션을 개발할 때, 개발자들은 각 시스템에 대해 독립적으로 인증을 구현해야 했으며, 이는 반복적인 작업을 필요로 했습니다. 이러한 경우, Single Sign-On (SSO)을 사용하여 통합 인증 시스템을 활용함으로써 이러한 문제를 해결할 수 있었습니다. 이를 통해 각 개별 웹 애플리케이션에서 최소한의 통합 작업만으로도 인증 기능을 구현할 수 있었습니다.

최근 몇 년 동안 프론트엔드와 백엔드 기술이 빠르게 발전하면서, 개발자들은 더 현대적인 기술 스택으로 이전하기 시작했고, 구식 기술로 구동되는 애플리케이션은 레거시 플랫폼으로 남게 되었습니다. 그러나 새로운 인증 보안 요구 사항이 발생했지만 기존 코드를 수정할 수 없는 경우도 있습니다. 이러한 경우, 미들웨어를 리버스 프록시로 사용하여 인증을 수행하는 대안적 접근 방식을 사용할 수 있습니다. 클라이언트가 애플리케이션에 도달하기 전에, 미들웨어는 사용자를 외부 인증 인터페이스로 리디렉션하고, 사용자가 로그인하면 미들웨어는 사용자의 신원 정보를 얻어 요청에 첨부한 후 기존 애플리케이션에 전달합니다. 이를 통해 개발자는 기존 코드를 수정하지 않고도 기존 애플리케이션에 새로운 인증 메커니즘을 추가할 수 있습니다.

API7의 인증

웹 애플리케이션의 진화: 프론트엔드와 백엔드의 분리

Vue와 React와 같은 새로운 프론트엔드 기술의 등장으로 웹 상호작용이 혁신되었습니다. 과거에는 사용자가 웹 페이지에서 폼을 작성하고 제출하여 백엔드와 상호작용했으며, HTML 폼과 버튼을 사용했기 때문에 원활한 사용자 경험을 제공하지 못했습니다. 이제는 페이지 상의 상호작용이 실시간으로 이루어지며, 개발자들은 JavaScript 스크립트를 사용하여 백엔드 API와 상호작용함으로써 더 일관되고 연속적인 경험을 제공합니다. 사용자 상호작용은 직접적인 HTTP 요청에서 다양한 API를 호출하는 방식으로 전환되었습니다.

웹 페이지 중심 애플리케이션과 API 중심 애플리케이션 간의 인증 메커니즘에는 몇 가지 차이점이 있습니다. 기존 쿠키를 여전히 사용할 수 있지만, 현대적인 프론트엔드 기술에는 적합하지 않습니다. 새로운 기술은 개발자에게 더 표현력 있는 코드를 제공하여 더 많은 작업을 수행할 수 있게 해주며, 프론트엔드에서 사용자 계정을 전환해야 하는 시나리오도 있습니다. 그러나 이를 프론트엔드에서 직접 쿠키를 통해 구현하는 것은 어렵습니다(보안상의 이유로 사용자 신원과 관련된 쿠키는 종종 httpOnly로 설정되어 JavaScript 스크립트가 이를 읽고 조작할 수 없습니다).

일반적으로 현대적인 프론트엔드 애플리케이션은 사용자 세션을 직접 관리합니다. 사용자가 성공적으로 로그인하면, 프론트엔드는 백엔드에서 생성된 토큰을 관리하고 API 호출 시 요청 헤더에 추가하여 백엔드가 사용자 신원을 식별할 수 있게 합니다. API는 토큰을 사용하여 사용자 정보를 식별합니다. JSON Web Tokens (JWT)를 사용하여 토큰 메커니즘을 수동으로 구현하는 등 다양한 기술적 수단이 있습니다. JWT 페이로드에는 사용자 ID와 같은 식별 정보가 저장되며, 이를 서명하여 백엔드가 토큰을 검증하고 사용자 신원 정보를 검색할 수 있게 합니다.

그러나 JWT에도 몇 가지 단점이 있습니다:

JWT의 만료 시간은 고정되어 있으며, 서명이 완료되면 수정할 수 없습니다. 일반적으로 백엔드에 저장되지 않고 서명 검증만 수행되기 때문에 토큰을 취소할 수 없어 토큰 도난의 위험이 있습니다.
페이로드 데이터는 평문으로 저장되며 클라이언트에서 파싱할 수 있어 기밀 정보를 저장하는 데 적합하지 않습니다.

다행히, 이러한 단점을 해결하기 위한 새로운 JWT 사양이 있습니다. JWT 페이로드에는 "jti"라는 필드를 포함시켜 JWT의 고유 식별자를 저장할 수 있으며, 이를 백엔드 캐시에 저장하여 JWT의 생명주기를 제어할 수 있습니다. 또한, JSON Web Encryption (JWE) 사양은 암호화된 JWT 확장을 정의하여 비대칭 및 대칭 암호화의 장점을 결합하여 페이로드가 암호문 형태로 전송되도록 하여 유출을 방지합니다.

또한, JWT 기반의 다른 기술들도 더 성숙한 솔루션을 제공합니다. 예를 들어, OpenID Connect가 있습니다. OpenID Connect는 JWT에 의존하지 않지만 함께 사용할 수 있습니다. OpenID Connect는 액세스 토큰과 리프레시 토큰의 메커니즘을 표준화하여 개발자가 단기 토큰을 사용하여 토큰 도난 위험을 완화할 수 있게 합니다. OpenID Connect의 생태계도 번성하여 많은 서버 및 클라이언트 구현이 개발자들이 OpenID Connect 프로토콜 기반의 인증 시스템을 구축하는 데 도움을 줍니다. 또한, Keycloak과 같은 오픈소스 인증 솔루션은 개발자들이 안전한 인증 서비스를 구현하는 데 도움을 줄 수 있습니다.

API7 인증 플러그인

Next.js와 같은 새로운 프론트엔드 기술 실습은 서버 사이드 렌더링 기술을 프론트엔드 영역에 점차 도입하고 있습니다. 이는 React와 백엔드 프로그램을 결합하여 사용자 경험을 더욱 향상시키는 구식 웹 개발 패러다임의 새로운 진화를 나타냅니다. 이제 NextAuth와 같은 더 많은 라이브러리가 개발자들이 이 메커니즘을 사용하여 인증을 구현하는 데 도움을 주어 인증 과정을 더 개발자 친화적으로 만듭니다.

API 게이트웨이와 인증

모바일 애플리케이션이 데이터와 상호작용하는 방식을 생각해봅시다. 모바일 애플리케이션도 API를 사용할까요? 모바일 애플리케이션에는 브라우저와 같은 쿠키 메커니즘이 없기 때문에 주로 토큰을 사용하여 HTTP 요청 헤더를 통해 정보를 전달합니다.

API 서비스는 어떨까요? 성공적인 애플리케이션 백엔드는 일반적으로 많은 복잡한 API 시스템으로 구성되며, 통합된 인증 메커니즘이 필요합니다. 그렇지 않으면 개발자들은 각 서비스에 대해 동일한 인증 메커니즘을 구현해야 하는 번거로움이 있습니다.

API 게이트웨이는 이러한 문제를 해결하는 데 도움을 줄 수 있습니다. API 게이트웨이는 쿠키나 토큰과 같은 인증 및 파싱 작업을 처리하고, 파싱된 신원 정보를 백엔드 서비스에 직접 전달하여 작업의 중복을 줄입니다. Apache APISIX와 API7 Enterprise는 즉시 사용 가능한 OpenID Connect 인증 기능을 지원하여 사용자가 인증 서비스를 직접 통합할 수 있게 합니다. 또한, API 게이트웨이는 스크립팅을 통해 어떤 인증 메커니즘이든 구현할 수 있으므로, 사용자 정의 인증 메커니즘이 있더라도 API 게이트웨이에 통합하여 애플리케이션 개발을 단순화할 수 있습니다.

요약

사용자 상호작용 방식의 발전은 인증의 발전을 이끌었습니다. API 중심 접근 방식은 주류 트렌드가 되고 있으며, API는 마이크로서비스 아키텍처에 의해 제공될 수 있으므로 통합된 인증 메커니즘이 필요합니다. 이는 중복 개발을 줄이기 위함입니다. 따라서 우리는 OpenID Connect와 JWT와 같은 더 현대적인 메커니즘을 선택해야 하며, API 게이트웨이를 사용하면 API 개발에 추가 기능을 제공할 수 있습니다.