RESTful API의 API 키 vs HTTP 인증 vs OAuth

101

유지 관리하는 애플리케이션 중 하나에 대한 RESTful API를 구축하는 중입니다. 우리는 현재 더 통제 된 액세스와 보안이 필요한 다양한 것들을 여기에 구축하려고합니다. API 보안에 대한 방법을 조사하는 동안 사용할 양식에 대한 몇 가지 다른 의견을 발견했습니다. 일부 리소스에서 HTTP-Auth가 갈 길이라고 말하는 반면 다른 리소스는 API 키를 선호하며 다른 리소스 (SO에서 찾은 질문 포함)도 OAuth가 맹세하는 것을 보았습니다.

물론 API 키를 선호하는 사람들은 OAuth가 사용자를 대신하여 액세스하는 애플리케이션을 위해 설계되었다고 말합니다 (예 : Facebook 계정을 사용하여 Facebook이 아닌 사이트에 로그인하는 것과 같이 내가 이해하는대로). 사용자가 특별히 가입 한 사이트 (예 : Twitter 서버에 액세스하는 공식 Twitter 클라이언트)의 리소스에 직접 액세스하는 사용자에게는 해당되지 않습니다. 그러나 OAuth에 대한 권장 사항은 가장 기본적인 인증 요구 사항에 해당하는 것 같습니다.

내 질문은-HTTPS를 통해 모두 수행되었다고 가정하면 세 가지의 실질적인 차이점은 무엇입니까? 하나를 다른 것보다 언제 고려해야합니까?

security api restful-authentication

— Shauna
소스

당신은 무엇으로 끝났습니까?

— Irwin

@Irwin-나는 꽤 오래 전에이 질문을했고 그 이후로 그것을 요구하는 프로젝트에서 옮겨 왔지만 결국 HTTP 인증을 사용하여 전송되는 API 키와 생성 된 암호 (사용자가 볼 수없는)의 조합을 사용하게되었습니다.

— Shauna

답변:

귀하의 필요에 따라 다릅니다. 당신이 필요로 할:

ID – 누가 API 요청을한다고 주장합니까?
인증 – 실제로 그들이 말하는 사람입니까?
승인 – 그들이하려는 일을 할 수 있습니까?

아니면 세 가지 모두?

API 호출의 양 또는 수를 추적하기 위해 호출자를 식별하기 만하면되는 경우 간단한 API 키를 사용하십시오. API 키를 발급 한 사용자가 다른 사람과 공유하면 API도 호출 할 수 있습니다.

그러나 인증이 필요한 경우 API 호출자를 기반으로 특정 리소스에 대한 액세스 만 제공 한 다음 oAuth를 사용합니다.

다음은 좋은 설명입니다. http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

— 시드
소스

"특정 리소스"는 "특정 API 호출"또는 "특정 데이터베이스 레코드"또는 둘 다를 의미합니까?

— Magne

대부분 DB 레코드 (또는 보호 상태를 나타내거나 상태를 수정하는 모든 것). 그러나 그것은 또한 DB에서 실제로 아무것도 변경하지 않고 시스템 리소스를 사용하며 권한이있는 개인 만 사용할 수있는 프리미엄 기능 (예 : 클라우드에서 알고리즘 실행)과 같은 것일 수 있습니다.

— Sid

@Sid 저는 Facebook 또는 LinkedIn에 가입 한 사용자를 등록하기 위해 OAuth를 사용하는 앱을 개발하고 있습니다. 또한 다른 서비스에서 데이터를 관리 할 수 있도록 API를 공개하고 있습니다. 이 경우 사용자 인증에 OAuth를 권장하고 API에 액세스하는 서비스에 대해 API 키 또는 사용자 이름과 비밀번호 조합 (예 : 링크 한 기사)을 권장 하시겠습니까? OAuth와 API 키는 모두 다른 목적으로 사용됩니다.

— Tom Doe

@TomDoe Hi Tom-맞습니다. 지금 OAuth2를 사용하고 싶을 것입니다. 서버가 Python (Django 또는 Flask) 인 경우 github.com/omab/python-social-auth

— Sid

API 키가이 세 가지를 제공 할 수없는 방법을 이해하지 못합니다. 신원 및 인증은 모두 "특정 비밀을 알고 있습니까?"를 기반으로합니다. (별도의 주제 인 2FA를 소개하지 않는 한). User 5의 매우 긴 API 키를 제공하면 적어도 사용자 이름 / 비밀번호와 마찬가지로 내가 User 5임을 주장하고 증명합니다. 그리고 다른 API 키에 다른 권한을 할당 할 수없는 이유가 없습니다. 권리? 내가 여기서 무엇을 놓치고 있습니까?

— Nathan Long

API 키 또는 토큰은 REST API의 노출 된 리소스에 대한 액세스 권한을 부여하므로 직접 인증 및 권한 부여 메커니즘의 범주에 속합니다. 이러한 직접 메커니즘은 위임 사용 사례에서 사용할 수 있습니다.

REST 엔드 포인트에 의해 노출 된 리소스 또는 리소스 집합에 대한 액세스 권한을 얻으려면 해당 ID에 따라 요청자 권한을 확인해야합니다. 워크 플로의 첫 번째 단계 는 요청 을 인증 하여 ID를 확인하는 것입니다 . 연속 단계는 정의 된 규칙 집합에 대해 ID를 확인하여 액세스 수준 (즉, 읽기, 쓰기 또는 읽기 / 쓰기) 을 승인 하는 것입니다. 상기 단계가 완료되면 일반적인 추가 관심사는 허용되는 요청 속도입니다 . 즉, 요청자가 주어진 리소스에 대해 수행 할 수있는 초당 요청 수를 의미합니다.

OAuth (Open Authorization) 는 위임 된 액세스를 위한 표준 프로토콜로 , 주요 인터넷 회사에서 비밀번호를 제공하지 않고 액세스 권한을 부여하기 위해 자주 사용합니다. 분명히 OAuth는 위에서 언급 한 문제를 해결하는 프로토콜입니다. 즉, 리소스 소유자를 대신하여 서버 리소스에 대한 보안 위임 액세스를 제공함으로써 인증 및 권한 부여입니다. 제 3자가 리소스 소유자를 대신하여 서버에서 관리하는 리소스에 액세스 할 수 있도록 허용하는 액세스 토큰 메커니즘을 기반으로합니다. 예를 들어 ServiceX는 John이 위임을 승인하면 John을 대신하여 John Smith의 Google 계정에 액세스하려고합니다. 그런 다음 ServiceX는 Google 계정 세부 정보에 액세스 할 수있는 시간 기반 토큰을 발급받으며 이는 읽기 액세스 전용 일 가능성이 높습니다.

API Key의 개념은 위에서 설명한 OAuth Token과 매우 유사합니다. 주요 차이점은 위임이 없다는 점입니다. 사용자는 연속적인 프로그래밍 방식 상호 작용을 위해 서비스 공급자에게 키를 직접 요청합니다. API 키의 경우도 시간 기반입니다. OAuth 토큰으로서의 키에는 시간 임대 또는 만료 기간이 적용됩니다. 추가 측면으로, 키와 토큰은 서비스 계약에 의해 속도 제한을받을 수 있습니다. 즉, 초당 주어진 요청 수만 제공 될 수 있습니다.

요약하자면, 실제로 기존 인증 및 권한 부여 메커니즘과 키 / 토큰 기반 버전 간에는 실제적인 차이가 없습니다. 그러나 패러다임은 약간 다릅니다. 클라이언트와 서버 간의 모든 상호 작용에서 자격 증명을 계속 재사용하는 대신 지원 키 / 토큰을 사용하여 전체 상호 작용 환경을 더 원활하고 안전하게 만듭니다 (종종 JWT 표준, 키 및 토큰은 제작을 피하기 위해 서버에 의해 디지털 서명됩니다.)

직접 인증 및 승인 : 기존 자격 증명 기반 버전의 변형 인 키 기반 프로토콜입니다.
위임 된 인증 및 권한 부여 : OAuth 기반 프로토콜과 마찬가지로 토큰을 다시 자격 증명 기반 버전의 변형으로 사용합니다 (전체 목표는 제 3 자에게 비밀번호를 공개하지 않는 것입니다).

두 범주 모두 관심있는 리소스를 소유 한 서버와의 첫 번째 상호 작용을 위해 전통적인 신원 확인 워크 플로를 사용합니다.

— 파올로 마레스 카
소스