개인 액세스 토큰, 기계 간 인증, API 키의 정의 및 실제 시나리오
개인 액세스 토큰(PATs), 기계 간(M2M) 인증, API 키의 차이점과 이들의 사용 방법을 배워보세요.
개인 액세스 토큰(PATs), 기계 간(M2M) 인증, API 키의 차이점과 이들의 사용 방법을 배워보세요.
소프트웨어나 SaaS 제품을 개발할 때 자주 접하는 넓은 범위의 사용 사례나 기능 요청이 있습니다: _API 요청_입니다. 특히 더 큰 엔터프라이즈 클라이언트는 종종 개인 또는 조직 차원에서 리소스에 대한 프로그램 접근을 원할 수 있습니다.
이러한 경우에 API 키, 개인 액세스 토큰(PATs), 기계 간(M2M) 인증이 자주 필요하게 됩니다. 이 기사에서는 이러한 방법들 사이의 차이점과 B2B 제품 개발에서 이를 어떻게 사용할 수 있는지에 대해 탐구해보겠습니다.
먼저 이 세 가지 방법의 유사점에 대해 살펴보겠습니다.
이러한 유사점들을 이해하면 이러한 인증 방법의 공통 기반을 인식할 수 있습니다. 이들의 차이점은 특정 사용 사례 및 보안 요구사항에 맞는 적절한 솔루션을 선택하는 데 도움이 됩니다.
이제 각 방법의 사용 사례와 사용 시기를 중심으로 그 차이점에 대해 이야기해보겠습니다.
API 키는 호출 애플리케이션 또는 서비스를 식별하고 권한을 부여하는 데 사용됩니다. 이들은 일반적으로 장기적이며 정적이지만 회전될 때까지 유지되며, 종종 고정된 권한 집합을 가지게 됩니다. 서버 간 통신 또는 공개 데이터를 액세스하는 데 주로 사용되며, 일반적으로 특정 사용자를 나타내지 않습니다.
API 키는 API 제공자에 의해 발급되며, 등록된 API 소비자[1]에게 제공됩니다. 소비자는 이를 각 요청에 포함시킵니다. 그러면 API 서버는 API 키를 검사하여 소비자의 신원을 확인하고 요청한 데이터를 반환합니다.
API 키는 OAuth와 JWT와 같은 다른 형태의 API 인증보다 효과적이지는 않지만, 여전히 API 생산자가 사용량을 모니터링하고 민감한 데이터를 안전하게 유지하는 데 중요한 역할을 합니다.
[1]: API 소비자는 API의 기능이나 데이터를 액세스하기 위해 상호 작용하는 애플리케이션, 서비스 또는 사용자를 의미합니다. 이들은 리소스를 검색, 생성, 업데이트 또는 삭제하는 등의 작업을 수행하기 위해 API에 요청을 보냅니다. API 소비자는 웹 애플리케이션, 모바일 앱, 다른 서버 또는 다른 서비스를 통합하거나 기존 플랫폼 위에 새로운 기능을 구축하기 위해 API를 사용하는 개인 개발자가 될 수 있습니다.
Postman: API 키란 무엇인가요?
API 키 사용 사례에 대해 이야기할 때, 사람들은 종종 자동화, 데이터 공유, 테스트, 개발 및 보안 제어를 언급합니다. 그러나 이러한 것들은 다소 기술적입니다. 실제 환경에서 제품을 구축할 때 가장 흔한 목적은 통합입니다.
Zapier: API 키로 인증 추가
Zapier는 다양한 웹 애플리케이션을 연결하는 인기 있는 자동화 도구입니다. 애플리케이션을 Zapier와 통합할 때 API 키는 애플리케이션의 API에 접근하기 위한 인증 및 권한 부여를 위해 사용됩니다. 예를 들어, CRM 시스템과 이메일 마케팅 도구 간의 작업을 자동화하려면 CRM 시스템에서 API 키를 생성한 후 이를 Zapier에 제공해야 합니다. 이 키는 Zapier가 CRM의 API와 상호작용할 때 인증하는 데 사용되어 두 시스템 간의 데이터가 안전하게 흐를 수 있도록 합니다.

Stripe는 다양한 플랫폼 및 애플리케이션과의 안전한 통합을 위해 API 키를 활용합니다. 개발자 대시보드를 사용하여 API 키를 생성, 공개, 삭제 및 회전할 수 있습니다.

개인 액세스 토큰은 특정 사용자의 신원 및 권한을 나타내는 유사한 개념이지만, 성공적인 인증 또는 로그인 시 동적으로 생성되며, 일반적으로 사용 기간이 제한되어 있지만 갱신될 수 있습니다. 이들은 특정 사용자 데이터 및 기능에 대한 세밀한 액세스 제어를 제공하며, CLI 도구, 스크립트 또는 개인 API 액세스에 자주 사용됩니다.
두 가지 일반적인 시나리오가 있습니다,
자동화 및 스크립팅
이는 개발자가 PAT을 사용하여 리포지토리에서 프로덕션 환경으로 코드 배포를 자동화하여 수동 개입을 줄이고 일관성을 보장하는 경우를 의미합니다.
예를 들어, GitHub 사용자는 HTTPS로 Git 작업을 인증하고 GitHub의 REST API와 상호작용하기 위해 PATs을 생성할 수 있습니다. 이는 리포지토리를 복제, 커밋 푸시, 또는 이슈 및 풀 요청을 관리하는 등의 작업을 자동화해야 하는 개발자에게 유용합니다.
외부 애플리케이션과의 통합
이 경우, 다른 시스템 및 애플리케이션 간의 안전한 커뮤니케이션을 가능하게 합니다. 이는 API 키 통합 시나리오와 유사하지만 PAT는 클라이언트 또는 애플리케이션이 아닌 사용자를 대표합니다.
예를 들어, 프로젝트 관리자가 프로젝트 관리 도구와 외부 문제 추적 시스템을 통합하기 위해 PAT를 사용하여 원활한 데이터 교환 및 동기화를 달성하는 경우입니다. 예를 들어 Atlassian(Jira 및 Confluence)과 같은 도구에서와 같은 상황입니다.
위의 시나리오는 개발자 도구와 유사합니다. PAT는 이러한 종류의 제품에만 유용한가요? 아닙니다. 다음은 또 다른 두 가지 예입니다: 하나는 CMS 시스템이고 다른 하나는 생산성 도구입니다.
Contentful: 개인 액세스 토큰
Contentful은 헤드리스 CMS 플랫폼으로, OAuth 토큰 대신 개인 액세스 토큰(PAT)을 Content Management API (CMA)에 액세스하기 위한 대안으로 제공합니다.
주요 기능은 다음과 같습니다:

Airtable - 클라우드 협업 플랫폼, API 액세스를 위해 PATs을 구현합니다.
그들의 시스템은 다음과 같은 기능을 제공합니다:

M2M 인증은 사람의 개입 없이 서비스 간 통신을 위해 설계되었습니다. 이는 서비스 보호를 위해 사용자 이름과 비밀번호가 불충분하며 효과적인 자동화에 비효율적이라는 아이디어에서 비롯되었습니다.
기계 간(M2M) 애플리케이션은 이제 OAuth 2.0 RFC 6749 인증 프로토콜에서 정의된 클라이언트 자격 흐름을 채택하고 있습니다. 이 방법은 유사한 표준 프로토콜도 지원할 수 있습니다. 네, M2M 인증은 PAT 및 API 키에 비해 표준 준수에 더 엄격합니다.
이는 사용자가 아닌 애플리케이션 또는 서비스를 인증하며, 종종 JWT(JSON Web Tokens)를 사용하여 상태 없는 인증을 구현합니다. 이는 서비스 간에 안전한 통신을 가능하게 합니다.
이 방법은 다음과 같은 프로세스를 따릅니다:
백엔드와 백엔드 간의 통신을 위해 기계 간(M2M) 인증을 사용하는 간단한 예를 살펴보겠습니다:
시나리오: 서비스 A에서 서비스 B의 API 데이터를 액세스해야 합니다.
설정:
인증:
서비스 A가 인증 서버에 액세스 토큰을 요청합니다:
토큰 발급:
API 요청:
서비스 A가 이 토큰을 사용하여 서비스 B에 데이터 요청을 보냅니다:
검증:
응답:
이 프로세스는 사용자 개입 없이 서비스 A와 서비스 B 간의 안전하고 자동화된 통신을 가능하게 하며, OAuth 2.0 클라이언트 자격 흐름을 사용합니다.
장치 간 통신
IoT(사물 인터넷) 맥락에서 장치 간 통신은 보안적이고 효율적인 데이터 교환을 위해 기계 간(M2M) 인증에 크게 의존합니다.
예를 들어, 스마트 홈 장치에서 스마트 온도 조절기는 사용자의 선호도에 따라 온도 설정을 조정하기 위해 중앙 홈 자동화 허브와 통신합니다. 온도 조절기는 홈의 난방 시스템과 상호작용할 수 있는 장치만 허용되도록 M2M 인증을 사용하여 허브에 데이터를 안전하게 전송하고 명령을 수신합니다.
좋습니다, 이 기사의 끝에 도달했습니다. 요약해드릴까요? 물론이죠! 여기 주요 포인트가 있습니다: