유지 관리하는 애플리케이션 중 하나에 대한 RESTful API를 구축하는 중입니다. 우리는 현재 더 통제 된 액세스와 보안이 필요한 다양한 것들을 여기에 구축하려고합니다. API 보안에 대한 방법을 조사하는 동안 사용할 양식에 대한 몇 가지 다른 의견을 발견했습니다. 일부 리소스에서 HTTP-Auth가 갈 길이라고 말하는 반면 다른 리소스는 API 키를 선호하며 다른 리소스 (SO에서 찾은 질문 포함)도 OAuth가 맹세하는 것을 보았습니다.
물론 API 키를 선호하는 사람들은 OAuth가 사용자를 대신하여 액세스하는 애플리케이션을 위해 설계되었다고 말합니다 (예 : Facebook 계정을 사용하여 Facebook이 아닌 사이트에 로그인하는 것과 같이 내가 이해하는대로). 사용자가 특별히 가입 한 사이트 (예 : Twitter 서버에 액세스하는 공식 Twitter 클라이언트)의 리소스에 직접 액세스하는 사용자에게는 해당되지 않습니다. 그러나 OAuth에 대한 권장 사항은 가장 기본적인 인증 요구 사항에 해당하는 것 같습니다.
내 질문은-HTTPS를 통해 모두 수행되었다고 가정하면 세 가지의 실질적인 차이점은 무엇입니까? 하나를 다른 것보다 언제 고려해야합니까?
답변
귀하의 필요에 따라 다릅니다. 당신이 필요로 할:
- ID – 누가 API 요청을한다고 주장합니까?
- 인증 – 실제로 그들이 말하는 사람입니까?
- 승인 – 그들이하려는 일을 할 수 있습니까?
아니면 세 가지 모두?
API 호출의 양 또는 수를 추적하기 위해 호출자를 식별하기 만하면되는 경우 간단한 API 키를 사용하십시오. API 키를 발급 한 사용자가 다른 사람과 공유하면 API도 호출 할 수 있습니다.
그러나 인증이 필요한 경우 API 호출자를 기반으로 특정 리소스에 대한 액세스 만 제공 한 다음 oAuth를 사용합니다.
다음은 좋은 설명입니다. http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/
답변
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 자에게 비밀번호를 공개하지 않는 것입니다).
두 범주 모두 관심있는 리소스를 소유 한 서버와의 첫 번째 상호 작용을 위해 전통적인 신원 확인 워크 플로를 사용합니다.
