API 키를 배치 할 위치 : 사용자 지정 구성표가있는 권한 부여 헤더와 사용자 지정 HTTP 헤더

API 키를 통한 인증 / 인증을 사용하여 REST API를 설계하고 있습니다.

나는 그것이 가장 적합한 장소를 알아 내려고 시도했으며 많은 사람들이 다음과 같은 사용자 정의 HTTP 헤더를 사용하도록 제안한다는 것을 알았습니다 ProjectName-Api-Key.

ProjectName-Api-Key: abcde

그러나 다음 Authorization과 같이 사용자 정의 체계와 함께 헤더 를 사용하는 것이 가능하고 이념적으로 정확합니다 .

Authorization: ApiKey abcde

반면에, 일부 클라이언트에서는 사용자 지정 권한 부여 체계가 예기치 않게 지원되지 않을 수 있으며 사용자 지정 코드로 연결될 수 있으므로 클라이언트에 대한 기대치가 없기 때문에 사용자 지정 헤더를 사용하는 것이 좋습니다.

어떤 방법으로 API 키를 보내시겠습니까?

인증을 사용하는 경우 일관성을 유지하십시오.

어떤 사람들은 다음이 불필요하다고 주장 할 것입니다 ( 그리고 너무 오래 전에 나는 그들과 동의했을 것입니다 ). 그러나 요즘에는 Authorization헤더를 사용하면 API 유형 이 자체 설명 적이 지 않기 때문에 토큰 유형 을 알려야합니다 ¹ .

왜 필요하다고 생각하고 왜 중요하다고 생각합니까? 요즘에는 다른 인증 / 권한 부여 프로토콜을 지원해야합니다. Authorization이러한 모든 프로토콜에 헤더 를 사용하려면 인증 서비스의 일관성을 유지해야합니다. 어떤 종류의 토큰을 전송하고 어떤 인증 프로토콜을 적용해야하는지 알려주는 방법도 헤더에 포함되어야합니다.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

나는 이것에 신경 쓰지 않았지만 업데이트가 보장되지 않은 앱 클라이언트 앱 (주로 모바일 및 센서)으로 작업 한 후에 시작했습니다. 클라이언트를 엉망으로 만들거나 서버쪽에 너무 많은 고통을주지 않으면 서 보안을 확장 할 수 있도록 보안을 구현하는 방식에 더주의를 기울였습니다.

우려 사항

내 계획을 구현할 때 직면 한 문제는 언급 한 것과 비슷합니다.

반면에, 일부 고객은 사용자 정의 승인 체계가 예기치 않게 지원되지 않을 수 있으며 어쨌든 사용자 정의 코드로 이어진다는 고려 사항을 발견했습니다.

말의 클라이언트는 , 라이브러리, 프레임 워크, 말 리버스 프록시를 .

장점

중요한 장점 중 하나는 캐시입니다. 공유 캐시는 달리 언급하지 않는 한 헤더를 캐시하지 않습니다 (물론 좋습니다).

인증 또는 사용자 정의 헤더?

내 경험에 따르면, 내 자신의 Authorization체계를 구현하면 사용자 지정 헤더를 사용했을 때 캐시를 제어 할 수있는 더 많은 디자인의 자유와 약간의 차이가있는 사용자 지정 권한 부여 헤더를 구현하는 것과 거의 동일한 작업 (또는 그 이상)이 필요했습니다. 그 이유는 내가 어쩌면 내가 또는로 Cache-control설정 한 시간이 다소 어리석기 때문에 네트워크의 토폴로지에 관계없이 서버에 대한 호출을보다 결정적 (트랙킹 및 테스트와 관련하여 중요) 할 수 있습니다.no-cacheno-store

^{1 : API 키와 관련 하여이 답변 이 매우 명확하다는 것을 알았습니다.}