프로그래매틱 인증: API 키, Personal Access Token, 및 OAuth 클라이언트 자격 증명 흐름

배경#

소프트웨어 개발에서 CLI 명령을 통해 API 리소스에 프로그래매틱하게 접근하거나 백엔드 서비스 간 통신을 확립하는 경우, 개발자들이 널리 사용하는 세 가지 인증 메커니즘이 있습니다: API 키, Personal Access Token (PAT), 및 OAuth 클라이언트 자격 증명 흐름(로그토에서 Machine-to-Machine 으로 브랜드화됨). 그러나 이들 간의 차이점은 무엇일까요? 각각의 방법에 가장 적합한 시나리오는 무엇일까요? 이 블로그 게시물에서는 유사점과 차이점을 살펴보고, 다양한 시나리오에서 각각을 사용할 시점에 대한 통찰력을 제공합니다.

정의#

• API 키: API 리소스에 대한 요청을 인증할 수 있는 간단한 문자열입니다.
• Personal Access Token (PAT): API 리소스에 인증하는 데 사용할 때 사용자를 나타내는 간단한 문자열입니다. 사용자의 대리를 나타냅니다.
• Logto Machine-to-Machine (Logto M2M): 클라이언트가 사전에 등록되어야 하고 클라이언트 ID와 비밀을 사용하여 액세스 토큰을 교환해야 하는 표준 OAuth 클라이언트 자격 증명 흐름입니다. 따라서, Logto M2M 자격 증명은 신뢰할 수 있는 클라이언트를 나타내며 OAuth 클라이언트 자격 증명 흐름의 성격으로 인해 사용이 상대적으로 복잡합니다.

유사점#

1. 인증 목적#

• API 키, PAT, 그리고 Logto M2M 모두 특정 서비스나 리소스에 접근하기 위한 사용자 또는 응용 프로그램의 인증을 위한 기본 목적을 제공합니다. 요청자의 신원을 증명하는 자격 증명으로 작동하며, CLI 명령이나 백엔드 간 통신 시나리오에서 주로 사용됩니다.

2. 보안 조치#

• 이 세 가지 인증 방법 모두 보안을 염두에 두고 처리해야 합니다. 개발자는 무단 액세스를 방지하기 위해 안전한 저장 및 전송을 보장해야 합니다.

차이점#

1. 사용자 컨텍스트#

• API 키는 주체를 식별하지 않으며, 어떤 권한 정보도 제공하지 않습니다. 따라서 API 키는 공개 데이터나 리소스에 익명으로 접근하는 데 자주 사용됩니다. 모든 서비스가 API 키의 사용을 지원하는 것은 아닙니다.
• PAT는 사용자 아이덴티티이며 API 리소스를 요청할 때 당신을 대신하여 사용자를 나타냅니다. 일부 시스템에서는 특정 서비스에 접근 허용이 되지 않습니다. 예: NuGet 패키지를 Azure Artifacts 피드에 게시하기.
• Logto M2M 자격 증명은 오직 신뢰할 수 있는 클라이언트만 사용할 수 있습니다. 클라이언트는 인증되기 전에 사전에 등록되어야 합니다. Logto M2M 자격 증명을 사용하는 경우, 그것은 사용자를 대신하여 사용하는 누군가가 아니라 신뢰할 수 있는 클라이언트를 나타냅니다.

2. 권한의 세분성#

• PAT와 Logto M2M 자격 증명은 보통 API 키에 비해 더 세밀한 권한 제어를 제공하여 수행할 수 있는 작업에 대한 세부적인 제어가 가능합니다.

3. 토큰 형식#

• API 키와 PAT는 보통 명확하고 단순한 불투명한 형식의 문자열입니다.
• Logto M2M 메커니즘을 통해 발행된 액세스 토큰은 보통 JWT 형식입니다.

4. 인증 흐름#

• API 키와 PAT는 시스템에 의해 생성된 불투명한 문자열로, 이 과정 중에는 어떤 인증 흐름도 포함되지 않습니다. 예를 들어, Google Cloud 자연어를 호출할 때 다음과 같이 할 수 있습니다:

• Logto M2M은 표준 OAuth 2.0 클라이언트 자격 증명 흐름을 활용합니다. 각 클라이언트는 사전에 클라이언트 ID와 비밀을 확보해야 하며, 클라이언트는 나중에 그것을 사용하여 액세스 토큰을 교환할 수 있습니다. 그리고 클라이언트는 액세스 토큰을 사용하여 API 리소스에 접근합니다.

사용 시점#

API 키#

• 서비스 간 통신: API 키는 응용 프로그램이 CLI를 통해 API와 직접 통신해야 하는 시나리오에 적합합니다. 예: OpenAI API 호출.
• 공개 API: API를 공개적으로 노출할 때, API 키는 단순한 접근 제어 방법을 제공합니다.
• 간단한 설정: 빠르고 간단한 인증 요구 사항에 대해, 특히 개발 단계에서. Logto M2M과 달리 API 키는 사전에 클라이언트 등록을 필요로 하지 않으며, 액세스 토큰을 교환할 필요도 없습니다. 요청에 매개변수로 API 키를 전달하기만 하면 되고 그저 작동합니다.

Personal Access Token (PAT)#

• 사용자 특정 작업: 응용 프로그램이 사용자를 대신하여 작업을 수행해야 할 때.
• 세밀한 접근 제어 (사용자): 사용자가 수행할 수 있는 작업에 대한 정확한 제어가 필요할 때.

Logto Machine-to-Machine (Logto M2M)#

• 보안: Logto M2M은 오직 신뢰할 수 있는 클라이언트만 백엔드 서비스에 접근할 수 있는 시나리오에 이상적입니다.
• 세밀한 접근 제어 (클라이언트): 응용 프로그램이 수행할 수 있는 작업에 대한 정확한 제어가 필요할 때.

결론#

요약하자면, API 키, PAT, 및 Logto M2M 중 선택은 사용자 특정 작업, Machine-to-Machine 통신, 또는 둘의 조합 여부와 같은 애플리케이션의 특정 요구 사항에 따라 달라집니다. 보안 및 기능 요구 사항 평가를 통해 귀하의 사용 사례에 가장 적합한 인증 방법을 결정하세요.

Logto M2M 메커니즘은 RBAC (역할 기반 접근 제어) 기능에 대한 세밀한 접근 제어를 설정할 수 있도록 허용합니다. 우리는 또한 가까운 장래에 API 키와 PAT를 지원할 계획입니다. 기능 업데이트를 계속 주목해 주세요!