API ควรใช้การรับรองความถูกต้องพื้นฐาน HTTP อย่างไร


17

เมื่อ API ต้องการให้ลูกค้ารับรองความถูกต้องฉันได้เห็นสถานการณ์ที่แตกต่างกันสองสถานการณ์ที่ใช้และฉันสงสัยว่ากรณีใดที่ฉันควรใช้กับสถานการณ์ของฉัน

ตัวอย่าง 1. บริษัท ให้บริการ API เพื่ออนุญาตให้บุคคลที่สามรับรองความถูกต้องด้วยโทเค็นและข้อมูลลับโดยใช้ HTTP Basic

ตัวอย่างที่ 2 API ยอมรับชื่อผู้ใช้และรหัสผ่านผ่าน HTTP Basic เพื่อตรวจสอบสิทธิ์ผู้ใช้ โดยทั่วไปแล้วพวกเขาจะได้รับโทเค็นกลับมาสำหรับคำขอในอนาคต

การตั้งค่าของฉัน: ฉันจะมี JSON API ที่ฉันใช้เป็นแบ็กเอนด์สำหรับมือถือและเว็บแอป ดูเหมือนเป็นวิธีปฏิบัติที่ดีสำหรับทั้งแอปมือถือและเว็บในการส่งโทเค็นและความลับดังนั้นเฉพาะแอปทั้งสองนี้เท่านั้นที่สามารถเข้าถึง API ที่ปิดกั้นบุคคลที่สามอื่น ๆ

แต่แอพมือถือและเว็บช่วยให้ผู้ใช้สามารถเข้าสู่ระบบและส่งโพสต์ดูข้อมูลของพวกเขาและอื่น ๆ ดังนั้นฉันต้องการให้พวกเขาเข้าสู่ระบบผ่านทาง HTTP พื้นฐานเช่นเดียวกับการร้องขอแต่ละครั้ง

ฉันจะใช้ทั้งสองวิธีร่วมกันหรือส่งเฉพาะข้อมูลรับรองผู้ใช้ (ชื่อผู้ใช้และโทเค็น) ในแต่ละคำขอหรือไม่ หากฉันส่งเฉพาะข้อมูลรับรองผู้ใช้ฉันจะเก็บไว้ในคุกกี้บนไคลเอนต์หรือไม่


โปรดทราบว่าคุกกี้ไม่ได้เป็นส่วนหนึ่งของโปรโตคอล HTTP และเป็นเพียงคุณสมบัติเบราว์เซอร์ทั่วไป ดังนั้นหากคุณไม่ได้ปรับใช้เว็บให้ลืมพวกเขา
Yam Marcovic

หากไม่แนะนำให้ใช้คุกกี้คุณจะจัดเก็บเครดิตเพื่อส่งไปยัง API อย่างไร / ที่ไหน?
Paul Sylling

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

คุณมีความคิดอย่างไรในส่วนของคำถามของฉันเกี่ยวกับการรับรองความถูกต้องของผู้ใช้และการรับรองความถูกต้อง ฉันยังไม่แน่ใจในเรื่องนี้
Paul Sylling

คำตอบ:


7

การพิสูจน์ตัวตนพื้นฐาน HTTP ต้องการชื่อผู้ใช้และรหัสผ่านที่จะส่งพร้อมกับคำขอทรัพยากรทุกครั้ง ชื่อผู้ใช้: รหัสผ่านถูกส่งผ่านใน "การอนุญาต" คำขอส่วนหัว base64 สตริงที่เข้ารหัสนำหน้าด้วย "พื้นฐาน" หากการสื่อสาร http ของคุณทั้งหมดถูกเข้ารหัส (ผ่าน SSL) ข้อมูลส่วนหัวการอนุญาตควรไม่สามารถใช้งานได้ง่ายโดยผู้โจมตีเนื่องจากไม่น่าเป็นไปได้ที่พวกเขาจะสามารถได้รับการควบคุม

SSL เข้ารหัส http ด้วยการรับรองความถูกต้องเบื้องต้นควรจะเพียงพอ


2
คุณสามารถให้ตัวอย่างนี้ มันเป็นสิ่งที่ฉันต้องการเพียงขวาติดมากในขณะนี้ ...
ganders

0

OAuth / OpenID สามารถทำงานได้พร้อมกับโทเค็น / ความลับหรือไม่

ฉันเพิ่งใคร่ครวญสถานการณ์ต่อไปนี้:

  • Web Application Front End
  • REST API พื้นฐาน
  • แอปพลิเคชั่นอุปกรณ์มือถือเข้าถึง REST API

เป็นการทดสอบง่ายๆฉันสามารถ:

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

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


1
ดังนั้นในตัวอย่างของคุณมีเพียงผู้ใช้ที่กำลังตรวจสอบความถูกต้อง ลูกค้าที่กำลังโทรไปยัง API (เว็บแอปมือถือ) ไม่ได้ตรวจสอบว่าพวกเขาเป็นใคร ในทางทฤษฎี API เป็นสาธารณะและแอปพลิเคชันใด ๆ สามารถโพสต์ชื่อผู้ใช้และรหัสผ่านและอาจได้รับโทเค็นกลับ
Paul Sylling

ผู้ใช้กำลังตรวจสอบความถูกต้องผ่านแอพและแอพกำลังทำการโทรในนามของผู้ใช้ กระบวนการตรวจสอบความถูกต้องได้รับโทเค็นซึ่งแอปพลิเคชันจะผ่านไป
เบรนแดนกรีน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.