API 인증 방법

소개#

오늘날의 세상에서 API는 현대 애플리케이션의 백본입니다. API는 백엔드 서비스에서 데이터와 기능에 접근하는 기본적인 방법입니다. API는 다양한 소프트웨어 시스템이 서로 다른 파티와 통신하고 데이터를 공유할 수 있게 하여 비즈니스에 없어서는 안 될 존재로 만듭니다. 그러나 API는 공격자들의 주된 타겟이기도 합니다. API 보호의 필요성이 그 어느 때보다 강해졌습니다.

API 보호는 무단 접근, 오용, 공격으로부터 API를 보호하는 과정입니다. 이것은 모든 API 전략에 있어 중요한 요소입니다. 이 문서에서는 세 가지 일반적인 API 보호 메커니즘인 API 키, 기본 인증, 그리고 OAuth JWT 토큰을 탐구할 것입니다. 마지막에는 Logto가 OAuth JWT 토큰을 사용하여 API를 보호하는 방법도 보여드리겠습니다.

API 키#

API 키는 API를 보호하는 가장 간단하고 널리 사용되는 방법입니다. API 키는 API 제공자가 생성하고 승인된 사용자와 공유하는 긴 문자 문자열입니다. 이 키는 API에 접근할 때 요청 헤더에 포함되어야 합니다. API 키는 기본적인 보안 요구에 대해 단순하고 효과적입니다. 예를 들어, Google Maps API와 AWS와 같은 인기 있는 서비스는 접근을 제어하고 사용량을 모니터링하기 위해 API 키를 제공합니다. 그러나 API 키는 보안 측면에서 제한이 있습니다. 주로 기계 대 기계 통신에서 사용됩니다.

e.g.

장점:#

• 구현이 간단함: API 키는 구현하고 사용하기 쉽습니다. 요청 헤더에 키를 첨부하는 간단한 방법으로, 개발자와 클라이언트가 이해하고 사용할 수 있는 이해하기 쉬운 방법입니다.
• 모니터링이 쉬움: API 키는 모니터링하기 쉽습니다. 각 키의 사용량을 추적하고 필요하면 해지할 수 있습니다.
• 효과적인 속도 제한: API 키는 속도 제한에 효과적입니다. 남용을 방지하기 위해 키당 요청 수 제한을 설정할 수 있습니다.
• 비민감 데이터에 적합: API 키는 보안 요구 사항이 낮은 비민감 데이터 또는 공개 API에 적합합니다.

단점:#

• 제한된 보안: API 키는 특히 클라이언트 측 애플리케이션에 대해 민감한 데이터에 적합하지 않습니다. 보안이 충분하지 않습니다. 주로 기계 대 기계 통신에 사용됩니다.
• 사용자 인증에 적합하지 않음: API 키는 개별 사용자와 연결되지 않으며 응용 프로그램 또는 시스템과 연결되어 특정 사용자를 식별하거나 그들의 행동을 추적하기 어렵습니다.
• 토큰 만료 없음: API 키는 일반적으로 정적이며 만료되지 않습니다. 키가 손상되면 수동으로 다시 생성하지 않는 한 무기한으로 악용될 수 있습니다.

기본 인증#

기본 인증은 API를 보호하는 또 다른 일반적인 방법입니다. 이것은 HTTPS 프로토콜에 내장된 간단한 인증 스키마입니다. 기본 인증은 요청 헤더에 사용자 이름과 비밀번호를 전송하여 사용자 인증을 수행합니다. 서버는 자격 증명을 검증하고 유효한 경우 요청한 리소스를 반환합니다. 예를 들어, 많은 웹 애플리케이션과 RESTful API는 사용자를 신속하고 간단하게 인증하기 위해 기본 인증을 사용합니다.기본 인증은 API 키보다 보안적입니다. 그러나 여전히 민감한 데이터에 대해서는 충분히 안전하지 않으며, 평문으로 전송된 자격 증명이 도청 당할 수 있는 위험이 있습니다. 기본 인증은 네트워크 연결이 안전한 내부 시스템 e.g. 기계 대 기계 통신에 적합합니다.

e.g.

또는

장점:#

• 더 강력한 보안: 기본 인증은 정적 키 대신 사용자 이름과 비밀번호를 사용하기 때문에 API 키보다 보안적입니다.
• 널리 지원됨: 기본 인증은 대부분의 웹 서버와 브라우저에서 널리 채택되고 지원됩니다.
• 단순성: API 키와 마찬가지로 기본 인증도 설정하고 사용하기 비교적 쉽습니다.

단점:#

• 자격 증명 노출: 기본 인증은 자격 증명을 평문으로 전송하여, 안전한 연결 (HTTPS)을 사용하지 않는 경우 도청 당할 위험이 있습니다.
• 토큰 만료 없음: 기본 인증은 토큰 만료를 지원하지 않습니다. 토큰이 손상되면 수동으로 다시 생성하지 않는 한 무기한으로 악용될 수 있습니다.

OAuth JWT 토큰#

RFC 7519에서 정의된 JSON 웹 토큰 (JWT)은 정보를 JSON 객체 형식으로 안전하게 전송하기 위한 개방형 표준입니다. 웹 애플리케이션과 API에서 인증과 권한 부여에 일반적으로 사용됩니다.

서명된 JWT는 다음 형식을 가집니다:

이것은 .으로 구분된 세 부분으로 구성됩니다: 헤더, 페이로드, 그리고 서명입니다.

다음은 JWT의 예입니다:

• 헤더: 토큰 유형과 서명에 사용된 해싱 알고리즘에 대한 정보를 담고 있습니다.
• 페이로드: 사용자에 대한 진술 (클레임) 및 기타 데이터를 담고 있습니다.
• 서명: 헤더와 페이로드의 해시를 비밀 키로 서명한 것입니다.

OAuth는 API 보안을 위한 포괄적인 개방형 표준이며, 접근 권한 위임을 위해 널리 사용됩니다. 이는 클라이언트 사용자가 다른 웹사이트에 자신의 비밀번호를 제공하지 않고도 정보에 접근할 수 있도록 웹사이트나 애플리케이션에 위임하는 방법으로 자주 사용됩니다.

JWT와 함께 사용될 때, OAuth JWT 토큰은 강력한 보안 솔루션을 제공합니다. 사용자 이름과 비밀번호와 같은 민감한 정보를 각 요청마다 전송하는 대신, OAuth JWT 토큰은 인증에 성공한 후 권한이 부여된 클라이언트에게 발급됩니다. 이러한 토큰은 사용자 및 그들의 권한에 대한 정보를 포함하며, JWT 토큰은 디지털 서명되어 변조 방지 기능을 제공하며, 만료될 수 있습니다. 이것은 추가적인 보안 계층을 제공합니다.

OAuth JWT 토큰의 주요 이점 중 하나는 유연성입니다. 이 토큰은 웹 및 모바일 앱, 단일 로그인 솔루션 등 다양한 유형의 응용 프로그램에서 사용할 수 있습니다. 예를 들어, Facebook, Twitter, LinkedIn과 같은 주요 소셜 미디어 플랫폼은 OAuth JWT 토큰을 사용하여 사용자를 인증하고, 제3자 애플리케이션이 사용자 데이터를 안전하게 접근할 수 있도록 합니다.

장점:#

• 강화된 보안: OAuth JWT 토큰은 높은 보안 수준을 제공합니다. 디지털 서명되거나 암호화될 수 있어 무단 접근 및 데이터 변조의 위험을 줄입니다.
• 사용자 신원과 접근 제어: JWT 토큰은 사용자 신원 정보를 담고 있으며, 사용자가 접근할 수 있는 자원이나 수행할 수 있는 작업을 명시하는 주장 (클레임)을 포함할 수 있습니다.
• 세밀한 접근 제어: JWT 토큰은 세밀한 접근 제어를 구현하는 데 사용할 수 있습니다. 예를 들어, 사용자가 접근할 수 있는 자원 및 자원에서 수행할 수 있는 작업을 명시할 수 있습니다.
• 토큰 만료: OAuth JWT 토큰은 특정 기간 후 만료되도록 설정할 수 있어 악용의 위험을 줄여줍니다.

단점:#

• 복잡성: OAuth JWT 토큰은 API 키와 기본 인증보다 더 복잡합니다. 설정 및 사용하기 위해 추가 단계가 필요합니다.
• 토큰 관리: OAuth JWT 토큰은 필요 시 관리하고 해지해야 합니다. 이는 많은 사용자와 클라이언트를 가진 대규모 애플리케이션에서는 도전이 될 수 있습니다.
• 리소스 소비: 토큰 생성 및 검증은 성능 오버헤드가 발생할 수 있으며, 이는 트래픽이 많은 시나리오에서 우려가 될 수 있습니다.

Logto API 보호#

인증 방법의 선택은 애플리케이션의 특정 요구 사항과 보안 고려 사항에 따라 다릅니다. API 키는 간단하지만 보안이 낮고, 기본 인증은 보안성이 더 강하지만 사용자 신원 기능이 부족하며, OAuth JWT 토큰은 강력한 보안과 사용자 신원 기능을 제공하지만 구현 및 관리의 복잡도를 증가시킵니다.

Logto는 OAuth JWT 토큰을 사용하여 귀하의 API를 단순하고 안전하게 보호할 수 있는 방법을 제공합니다. OAuth 2.0과 OpenID Connect (OIDC) 표준을 모두 지원하므로 가장 적합한 인증 방법을 선택할 수 있습니다. 기계 대 기계 통신을 위해 client_credentials 흐름을 사용하고, 웹 애플리케이션을 위해 authorization_code 흐름을 사용할 수 있습니다.

기계 대 기계 통신#

Logto는 기계 대 기계 유형의 애플리케이션을 위해 client_credentials 흐름을 사용합니다. 이 흐름은 클라이언트가 클라이언트 자격 증명을 안전하게 저장할 수 있는 비밀 클라이언트인 백엔드 서버 통신에 적합합니다. 이 방법은 사용자와는 무관하기 때문에 "양족 OAuth"라고도 합니다. 클라이언트 자격 증명은 접근 토큰을 얻기 위한 승인 그랜트로 직접 사용됩니다.

통합 흐름은 간단하고 직관적입니다:

1. Logto 콘솔에서 API 리소스를 만듭니다.
2. Logto 콘솔에서 기계 대 기계 클라이언트를 만듭니다.
3. 접근 토큰을 얻기 위해 Logto 토큰 엔드포인트에 요청을 보냅니다.

4. 접근 토큰으로 보호된 리소스에 접근합니다.

자세한 내용은 우리의 기계 대 기계 통합 문서를 확인해 주세요.

웹 애플리케이션#

웹 애플리케이션과 같은 공개 클라이언트를 위해 Logto는 authorization_code 흐름을 사용하여 사용자를 인증합니다. 이 흐름은 클라이언트가 클라이언트 자격 증명을 안전하게 저장할 수 없는 공개 클라이언트인 웹 애플리케이션에 적합합니다. 이 방법은 사용자가 관련되어 있으므로 "삼족 OAuth"라고도 합니다. 사용자는 인증 서버로 리디렉션되어 인증과 클라이언트의 승인을 처리하게 됩니다. 클라이언트는 그런 다음 승인 코드를 사용하여 접근 토큰을 얻습니다.

통합 흐름은 기계 대 기계 흐름보다 약간 더 복잡합니다:

Express.js API를 JWT와 Logto로 보호하기 기사를 확인하여 JWT 토큰을 사용하여 React와 Express 서버 API를 통합하는 방법에 대한 종합적인 예시를 확인해 주세요.