REST 인증 : 사용자 정의 헤더 또는 Authorization 헤더에 키를 넣으시겠습니까?

Question

저는 보안에 중점을 둔 대형 회사를위한 REST API 프레임 워크를 설계하고 있습니다.

Google 서비스를 이용하는 모든 발신자는 시스템에 액세스하기 위해 클라이언트 키를 제공해야합니다. 특정 클라이언트에 대한 액세스 권한 부여 및 속도 제한 및 모니터링에이를 사용할 것입니다. 또한 API 호출 중 일부는이며 고객 데이터에 액세스하고 OAuth 2 토큰을 사용하여 해당 데이터에 대한 액세스를 제어합니다.

제 질문은 클라이언트 키를 전달하는 방법입니다. HTTP 기본 인증 또는 쿼리 매개 변수는 URI에 전달할 수 없기 때문에 사용할 수 없습니다 (URI는 때때로 기록됩니다) - 대신 HTTP 헤더에 있어야합니다. 그래서 두 가지 접근법을 생각해 봤습니다. 둘 다 결함이 있습니다 :

(1) 우리 고유의 헤더를 발명하십시오 : MyCompanyAPIKey: api-key-goes-here. 이것은 우리 자신의 헤더를 발명 할 것이기 때문에 결함이 있습니다. 이것은 잘못된 디자인 선택입니다. 다른 사람이나 표준 도구로는 작동하지 않습니다 (우리가 자체적으로 발명했기 때문에).

(2) 인증 헤더 : Authorization: Bearer api-key-goes-here을 사용하십시오. OAuth가 헤더를 필요로하는 OAuth와 충돌 할 수 있기 때문에 이것은 잘못되었습니다. 기술적으로 나는 이 필요하지 않습니다. OAuth 토큰을 가지고있을 때 클라이언트 키가 필요합니다 (OAuth 토큰은 단일 클라이언트에만 한정되어 있기 때문에). 그러나 일반 도구로 처리 할 수 ​​있는지 여부는 알 수 없습니다.

어떻게 진행해야한다고 생각합니까?

Answer 1

요구 사항을 감안할 때 맞춤 헤더와 같은 소리가 여기에 있습니다.

API 키를 전달하는 표준화 된 방법이 없으므로 잘못된 디자인 선택과 관련하여 우려 할 사항이 아닙니다. API 키는 다른 응용 프로그램과는 다른 것을 의미합니다. 일부 사용자 아이디; 다른 사람에게, 그 비밀 번호; 그리고 다른 사람들에게는 명백한 인증이 요구되지 않는 곳에서 단순히 조절하는 것입니다.

호환성에 관한 한 대부분의 도구는 API로 작업 할 때 약간의 유연성을 허용하므로 오랫동안 미친 짓은하지 마십시오. 괜찮을 거예요. 무엇을 하든지간에 모든 표준을 구현하기로 선택하면 완전히 구현 (OAuth vs "OAuth like")하고 문서를 제공하십시오.