ตำแหน่งที่จะวางคีย์ API: ส่วนหัว HTTP ที่กำหนดเอง VS ส่วนหัวการให้สิทธิ์ด้วยชุดรูปแบบที่กำหนดเอง

ฉันกำลังออกแบบ REST API โดยใช้การอนุญาต / การพิสูจน์ตัวตนผ่านทางคีย์ API

ฉันพยายามคิดออกว่าเป็นที่ที่ดีที่สุดสำหรับสิ่งนั้นและพบว่าหลายคนแนะนำให้ใช้ส่วนหัว HTTP ที่กำหนดเองเช่นProjectName-Api-Keyเช่น:

ProjectName-Api-Key: abcde

แต่ก็เป็นไปได้และถูกต้องตามหลักอุดมการณ์ที่จะใช้Authorizationส่วนหัวกับชุดรูปแบบที่กำหนดเองเช่น:

Authorization: ApiKey abcde

ในทางกลับกันฉันพบการพิจารณาว่ารูปแบบการให้สิทธิ์ที่กำหนดเองอาจไม่คาดคิดและไม่ได้รับการสนับสนุนจากลูกค้าบางรายและนำไปสู่รหัสที่กำหนดเองอยู่ดีดังนั้นจึงเป็นการดีกว่าที่จะใช้ส่วนหัวที่กำหนดเอง

คุณต้องการส่งคีย์ API ไปทางไหน

— RomanG
แหล่งที่มา

โครงการภายใต้คำแนะนำของฉันใช้Authorization: Bearer <token>หัวข้อและไม่เคยมีปัญหาเดียวกับที่ โทเค็นคือJWT s

— Andy

@DavidPacker อย่างที่ฉันเข้าใจBearerมีการใช้รูปแบบเฉพาะกับ oAuth2 การนำไปใช้แยกต่างหากจาก oAuth ฟังเป็นการใช้ผิดวัตถุประสงค์ เหตุใดจึงต้องใช้รูปแบบนี้หากไม่มี oAuth อย่างไรก็ตามฉันมีปัญหาในการเลือกประเภทการอนุญาตสำหรับ API ของฉัน API จะพร้อมใช้งานสำหรับบริการที่เชื่อถือได้เพียงหนึ่งเดียวดังนั้นฉันตรวจสอบการไหลของข้อมูลรับรองลูกค้าของ oAuth2 และไม่พบประโยชน์ใด ๆ เมื่อเปรียบเทียบกับ ApiKey ในกรณีของฉัน

— RomanG

@DavidPacker จากนั้นฉันเข้าใจว่าการให้สิทธิ์ ApiKey ถือเป็นการใช้งาน oAuth ที่ถูกต้องหากApiKeyมีการเปลี่ยนชื่อและตีความว่าเป็นการAccess Tokenให้สิทธิ์แก่ลูกค้าโดยไม่มีเวลาหมดอายุ นั่นคือแง่มุมทางปรัชญาฉันตัดสินใจที่จะไม่ใช้คำจำกัดความที่ซับซ้อนหากกรณีของฉันสามารถอธิบายได้ในแง่ง่ายและตัดสินใจที่จะเรียกมันว่า "ApiKey" หากโพรโทคอลของคุณใช้รูปแบบของ oAuth ฉันสามารถเห็นด้วยกับการใช้Bearerงาน แต่ไม่เช่นนั้นฉันเดาว่ารูปแบบนี้ไม่สามารถใช้ได้

— RomanG

คุณกำลัง จำกัด ตัวเองมากเกินไป ผู้บริโภค API ไม่สามารถใส่ใจน้อยลงได้ว่าคุณใช้ OAuth หรือไม่ สิ่งที่พวกเขาสนใจคือความปลอดภัยของโทเค็น, โทเค็นที่ออกงานและพวกเขาสามารถได้รับการรับรองความถูกต้องอย่างถูกต้อง พวกเขาแนะนำให้ใช้ผู้ถือสิทธิในเอกสาร JWT JWT เข้ากับ Schema ของ Bearer อย่างสมบูรณ์แบบและฉันไม่สามารถแนะนำ JWT ได้มากกว่านี้ เหมาะสำหรับแอปพลิเคชัน REST เนื่องจากคุณสามารถรับรองความถูกต้องของผู้ใช้ได้แม้ไม่ต้องกดปุ่มฐานข้อมูลยกเว้นว่าคุณต้องการคุณสมบัติการเพิกถอนโทเค็น

— Andy

(ขับรถด้วย) ... โปรดระวังให้ดีว่าคีย์ api เป็นความลับที่ ใช้ร่วมกันซึ่งโดยทั่วไปจะใช้ร่วมกันระหว่างบุคคลที่มีการกำหนดค่าและผู้รับรองความถูกต้องไม่ใช่เพื่อสื่อสารข้อมูลประจำตัวหรือการอนุญาต ระบุอีกวิธีหนึ่งพวกเขามีจุดประสงค์เพื่อเริ่มต้นการจับมือความปลอดภัยเท่านั้นไม่ได้แสดงผลลัพธ์การรับรองความถูกต้อง คีย์ api สื่อสารสิทธิ์ของคุณในการพิสูจน์ตัวตนของคุณกับผู้ตรวจสอบที่เชื่อถือได้ของระบบ การใช้คีย์เป็นโทเค็นเพื่อควบคุมการเข้าถึงทรัพยากรอย่างปลอดภัยนั้นไม่ดี juju

— K. Alan Bates

หากคุณใช้การอนุญาตให้สอดคล้อง

บางคนจะโต้แย้งว่าสิ่งต่อไปนี้ไม่จำเป็น ( และไม่นานมานี้ฉันจะเห็นด้วยกับพวกเขา ) แต่วันนี้ถ้าเราใช้Authorizationส่วนหัวเราควรแจ้งประเภทของโทเค็นเพราะ คีย์ APIไม่อธิบายตัวตนต่อ¹ .

ทำไมฉันถึงคิดว่ามันจำเป็นและทำไมฉันถึงคิดว่ามันสำคัญ เพราะทุกวันนี้สนับสนุนโปรโตคอลการพิสูจน์ตัวตน / การอนุญาตที่แตกต่างกันกลายเป็นสิ่งที่ต้องมี หากเราวางแผนที่จะใช้Authorizationส่วนหัวสำหรับโปรโตคอลเหล่านี้ทั้งหมดเราจะต้องให้บริการรับรองความถูกต้องของเราสอดคล้องกัน วิธีในการสื่อสารประเภทของโทเค็นที่เราส่งและควรใช้โปรโตคอลการอนุญาตใดควรอยู่ในส่วนหัวด้วย

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

ฉันไม่สนใจเรื่องนี้ แต่หลังจากทำงานกับแอพไคลเอ็นต์แอปที่ไม่รับประกันการอัปเดต (ส่วนใหญ่โทรศัพท์มือถือและเซ็นเซอร์) ฉันเริ่ม ฉันเริ่มระมัดระวังในการใช้ระบบความปลอดภัยมากขึ้นเพื่อให้สามารถขยายได้โดยไม่ต้องยุ่งกับไคลเอนต์และไม่มีความเจ็บปวดด้านเซิร์ฟเวอร์มากเกินไป

ความกังวลเกี่ยวกับ

ปัญหาที่ฉันเผชิญกับการใช้รูปแบบของตัวเองนั้นคล้ายกับความคิดเห็น

ในทางกลับกันฉันพบการพิจารณาว่ารูปแบบการให้สิทธิ์ที่กำหนดเองอาจไม่คาดคิดและไม่ได้รับการสนับสนุนจากลูกค้าบางรายและนำไปสู่รหัสที่กำหนดเองอยู่ดี

Say ลูกค้าบอกว่าห้องสมุดกรอบผู้รับมอบฉันทะย้อนกลับ

ข้อดี

ข้อดีอย่างหนึ่งที่สำคัญคือแคช แคชที่ใช้ร่วมกันจะไม่แคชส่วนหัว (และแน่นอนว่าดี) เว้นแต่คุณจะพูดเป็นอย่างอื่น

ดังนั้นการอนุญาตหรือส่วนหัวที่กำหนดเอง?

จากประสบการณ์ของฉันการใช้Authorizationรูปแบบของตัวเองทำให้ฉันมีจำนวนงานที่เหมือนกัน (หรือมากกว่า) กว่าการใช้หัวเรื่องการอนุญาตที่กำหนดเองโดยมีความแตกต่างเล็กน้อยในการมีอิสระในการออกแบบและการควบคุมแคชมากกว่าเมื่อฉันใช้ส่วนหัวที่กำหนดเอง เหตุผลค่อนข้างโง่เวลาส่วนใหญ่ที่ฉันCache-controlตั้งไว้ no-cacheหรือno-storeอนุญาตให้ฉันโทรไปยังเซิร์ฟเวอร์ที่กำหนดมากขึ้น (ซึ่งเป็นสิ่งสำคัญเมื่อมันมาถึงการติดตามและทดสอบ) โดยไม่คำนึงถึงทอพอโลยีของเครือข่าย

^{1: ฉันพบคำตอบนี้ชัดเจนเกี่ยวกับคีย์ API}

— LAIV
แหล่งที่มา

การใช้X-เลิกใช้แล้วในปี 2012: stackoverflow.com/a/3561399/923720

— Darkhogg

Ops! ฉันไม่รู้ แก้ไขและแก้ไขแล้ว

— Laiv

ก่อนหน้าคำถามนี้ฉันคิดว่าทุกคนส่วนใหญ่ใส่คีย์ API ใน URL แต่ใช้ HTTPS เพื่อซ่อน ดีที่เห็นทางเลือกอื่น ยกตัวอย่างเช่น Contentful อนุญาตการอนุมัติหรือ pamameter แบบสอบถาม: contentful.com/developers/docs/references/content-delivery-api/...

— user949300

@ user949300 ... การใช้ความลับที่แชร์ที่เข้ารหัส (เช่นคีย์ api ใน uri over ssl) เห็นได้ชัดว่าปลอดภัยกว่าไม่มีอะไรเลย แต่สามารถปลอมแปลงได้ง่ายหากถูกดักจับและไม่ให้ข้อมูลใด ๆ ฉันไม่เคยใช้ api_keys สำหรับสิ่งอื่นใดนอกจากการสื่อสารระหว่างเครื่องกับเครื่องที่ฉันจับคู่ความลับที่แบ่งปันระหว่างฝ่ายที่ไว้วางใจและตัวตนของเครื่องที่ได้รับอนุญาตที่ได้รับอนุญาตให้ทำหน้าที่กับความลับที่แบ่งปันนั้น หลังจากทำการต่อเครื่องแล้วผู้ปฏิบัติงานมนุษย์จะรับรองความถูกต้องโดยใช้วิธีการอื่น

— K. Alan Bates

@K Alan Bates การปฏิสัมพันธ์ API ส่วนใหญ่ของฉันมีไว้สำหรับสิ่งที่ "ไม่สำคัญ" อย่างเช่นระดับ geocoding ฟรีรายงานสภาพอากาศและสิ่งที่คล้ายกันโดยที่คีย์ API นั้น จำกัด การใช้อัตรามากกว่าความลับที่ร้ายแรงของผู้ใช้ ดังนั้นสำหรับ OP ขึ้นอยู่กับระดับความปลอดภัยที่ต้องการ

— user949300