헤더 또는 URL에 API 키 배치

헤더 또는 URL에 API 키 배치

---

회사 데이터에 대한 공개 API를 설계하고 있습니다. 애플리케이션 개발자가 API 키에 등록하여 사용 및 남용을 모니터링 할 수 있기를 바랍니다.

API가 REST이므로 처음에는이 키를 사용자 지정 헤더에 넣는 것이 좋습니다. 이것이 제가 구글, 아마존, 야후를 본 방법입니다. 반면에 상사는 키가 URL의 일부가되는 경우 API를 사용하는 것이 더 쉽다고 생각합니다. " http : //api.domain.tld/longapikey1234/resource ". 나는 그것에 대해 말할 것이 있다고 생각하지만, 그것은 당신이 원하는 방법이나 이유가 아니라 원하는 것에 대한 간단한 주소로서 URL의 원칙을 위반합니다.

URL에 키를 넣는 것이 합리적입니까? 또는 일부 데이터에 간단한 자바 스크립트 프런트 엔드를 작성하는 경우 HTTP 헤더를 수동으로 설정할 필요가 없습니까?

---

HTTP Authorization 헤더에 넣어야합니다. 사양은 여기 https://tools.ietf.org/html/rfc7235

---

상사에게 어필 할 수있는 논쟁을 원한다면 : URL이 무엇인지 생각해보십시오. URL은 공개입니다. 사람들은 그것들을 복사하여 붙여 넣습니다. 그들은 그것들을 공유하고 광고에 올립니다. 누군가 (고의적이든 아니든) 다른 사람들이 사용할 수 있도록 해당 URL을 메일로 보내는 것을 막을 수있는 것은 없습니다. API 키가 해당 URL에 있으면 누구나 가지고 있습니다.

---

URL이 아닌 헤더에 API 키를 사용하는 것이 좋습니다.

URL은 브라우저에서 시도하는 경우 브라우저의 기록에 저장됩니다. 매우 드문 시나리오입니다. 그러나 백엔드 서버가 모든 URL을 기록 할 때 문제가 발생합니다. API 키가 노출 될 수 있습니다.

두 가지 방법으로 헤더에 API 키를 사용할 수 있습니다.

기본 승인 :

스트라이프의 예 :

curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:

curl은 -u 플래그를 사용하여 기본 인증 자격 증명을 전달합니다 (API 키 뒤에 콜론을 추가하면 암호를 요청하지 못함).

맞춤 헤더

curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users

---

REST 인이 느슨한 '표준'을 위반하므로 URL에 키를 넣지 않을 것입니다. 그러나 그렇게했다면 URL의 '사용자'부분에 배치합니다.

예 : http : //me@example.com/myresource/myid

이렇게하면 기본 인증을 사용하여 헤더로 전달할 수도 있습니다.

---

매개 변수에 API 키를 전달하면 클라이언트가 API 키를 비밀로 유지하기 어렵고 정기적으로 키를 유출하는 경향이 있습니다. 더 나은 접근 방식은 요청 url의 헤더에 전달하는 것입니다. 코드에서 사용자 키 헤더를 설정할 수 있습니다. 요청 Url을 테스트하기 위해 사용자 키 헤더를 API 키로 설정하여 Google 크롬에서 Postman 앱을 사용할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/5517281/place-api-key-in-headers-or-url