ข้อมูลเบื้องต้นเกี่ยวกับ OAuth 2.0

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่ เอกสารประกอบของ Apigee X info

หน้าแรกของ OAuth: ดูหน้าแรกของ OAuth เพื่อดูภาพรวมระดับบนสุดของคำแนะนำเกี่ยวกับ OAuth ที่เรา มีให้.

หัวข้อนี้จะให้ภาพรวมพื้นฐานของ OAuth 2.0 ใน Apigee Edge

OAuth 2.0 คืออะไร

มีหนังสือ บล็อก และเว็บไซต์มากมายที่อธิบายเกี่ยวกับ OAuth 2.0 เราขอแนะนำให้คุณ เริ่มต้นด้วยการอ่านข้อกำหนด OAuth 2.0 ของ IETF ต่อไปนี้คือคำจำกัดความของ OAuth 2.0 จากข้อกำหนด OAuth 2.0 ของ IETF เอง:

เฟรมเวิร์กการให้สิทธิ์ OAuth 2.0 ช่วยให้แอปพลิเคชันของบุคคลที่สาม ได้รับสิทธิ์เข้าถึงบริการ HTTP แบบจำกัดในนามของเจ้าของทรัพยากรโดย การประสานการโต้ตอบเพื่อขออนุมัติระหว่างเจ้าของทรัพยากรกับบริการ HTTP หรือโดย อนุญาตให้แอปพลิเคชันของบุคคลที่สามได้รับสิทธิ์เข้าถึงในนามของตนเอง

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

ขั้นตอน OAuth 2.0

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

คำที่คุณควรรู้

• ไคลเอ็นต์: เรียกอีกอย่างว่า "แอป" ซึ่งอาจเป็นแอปที่ทำงานบนอุปกรณ์เคลื่อนที่ หรือเว็บแอปแบบเดิม โดยแอปจะส่งคำขอไปยังเซิร์ฟเวอร์ทรัพยากรเพื่อขอชิ้นงานที่มีการป้องกัน ในนามของเจ้าของทรัพยากร เจ้าของทรัพยากรต้องให้สิทธิ์แอปในการเข้าถึงทรัพยากรที่มีการป้องกัน
• เจ้าของทรัพยากร: เรียกอีกอย่างว่า "ผู้ใช้ปลายทาง" โดยทั่วไปจะเป็น บุคคล (หรือนิติบุคคลอื่นๆ) ที่สามารถให้สิทธิ์เข้าถึงทรัพยากรที่มีการป้องกันได้ ตัวอย่างเช่น หากแอปต้องใช้ข้อมูลจากเว็บไซต์โซเชียลมีเดียเว็บไซต์ใดเว็บไซต์หนึ่งของคุณ คุณจะเป็นเจ้าของทรัพยากร ซึ่งเป็นบุคคลเดียวที่สามารถให้สิทธิ์เข้าถึงข้อมูลแก่แอปได้
• เซิร์ฟเวอร์ทรัพยากร: ให้คิดว่าเซิร์ฟเวอร์ทรัพยากรเป็นบริการอย่าง Facebook, Google หรือ Twitter หรือบริการ HR ในอินทราเน็ตของบริษัท หรือบริการของพาร์ทเนอร์ใน เอ็กซ์ทราเน็ต B2B Apigee Edge จะเป็นเซิร์ฟเวอร์ทรัพยากรทุกครั้งที่ต้องมีการตรวจสอบโทเค็น OAuth เพื่อ ประมวลผลคำขอ API เซิร์ฟเวอร์ทรัพยากรต้องมีการให้สิทธิ์บางอย่างก่อนจึงจะแสดง ทรัพยากรที่มีการป้องกันแก่แอป
• เซิร์ฟเวอร์การให้สิทธิ์: เซิร์ฟเวอร์การให้สิทธิ์ได้รับการติดตั้งใช้งาน ตามข้อกำหนด OAuth 2.0 และมีหน้าที่ ตรวจสอบ การให้สิทธิ์ และออก โทเค็นเพื่อการเข้าถึง ที่ให้สิทธิ์แอปในการเข้าถึงข้อมูลของผู้ใช้ในเซิร์ฟเวอร์ทรัพยากร คุณ สามารถกำหนดค่า "ปลายทางของโทเค็น" ใน Apigee Edge ได้ ซึ่งในกรณีนี้ Edge จะรับบทบาทเป็น เซิร์ฟเวอร์การให้สิทธิ์
• การให้สิทธิ์: ให้สิทธิ์แอปในการดึงโทเค็นเพื่อการเข้าถึงในนามของผู้ใช้ปลายทาง OAuth 2.0 กำหนด "ประเภทการให้สิทธิ์" ไว้ 4 ประเภท ดู "ประเภทการให้สิทธิ์ OAuth 2.0 มีอะไรบ้าง" ด้านล่าง
• โทเค็นเพื่อการเข้าถึง: สตริงอักขระยาวที่ทำหน้าที่เป็นข้อมูลเข้าสู่ระบบ ที่ใช้เข้าถึงทรัพยากรที่มีการป้องกัน ดู "โทเค็นเพื่อการเข้าถึง คืออะไร" ด้านล่างด้วย
• ทรัพยากรที่มีการป้องกัน: ข้อมูลที่เป็นเจ้าของโดยเจ้าของทรัพยากร เช่น รายชื่อติดต่อ ข้อมูลบัญชี หรือข้อมูลที่ละเอียดอ่อนอื่นๆ ของผู้ใช้

Apigee Edge มีส่วนเกี่ยวข้องอย่างไร

คุณสามารถป้องกัน API ใดก็ตามที่พร็อกซีผ่าน Apigee Edge ด้วย OAuth 2.0 Edge มีการติดตั้งใช้งานเซิร์ฟเวอร์การให้สิทธิ์ จึงสามารถสร้างและตรวจสอบโทเค็นเพื่อการเข้าถึงได้ นักพัฒนาแอปเริ่มต้นด้วยการลงทะเบียนแอปกับ Apigee Edge แอปที่ลงทะเบียนแล้วสามารถขอโทเค็นเพื่อการเข้าถึงผ่านการโต้ตอบประเภท การให้สิทธิ์ทั้ง 4 ประเภท

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

โปรดทราบว่าเซิร์ฟเวอร์ทรัพยากรใดก็ตามที่พร็อกซี API ที่ปลอดภัยของคุณเรียกใช้ควรอยู่หลังไฟร์วอลล์ (นั่นคือ ทรัพยากรต้องเข้าถึงไม่ได้ด้วยวิธีอื่นนอกเหนือจากพร็อกซี API หรือ API อื่นที่มีการรักษาความปลอดภัยอย่างดี)

ประเภทการให้สิทธิ์ OAuth 2.0 มีอะไรบ้าง

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

Apigee Edge รองรับประเภทการให้สิทธิ์ OAuth 2.0 หลัก 4 ประเภท ได้แก่

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

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

• โดยปริยาย -- ถือเป็นรหัสการให้สิทธิ์เวอร์ชันที่ง่ายขึ้น โดยทั่วไปแล้ว ประเภทการให้สิทธิ์นี้จะใช้เมื่อแอปอยู่ในไคลเอ็นต์ เช่น โค้ดของแอปได้รับการติดตั้งใช้งานในเบราว์เซอร์โดยใช้ JavaScript หรือภาษาการเขียนสคริปต์อื่น (แทนที่จะอยู่ในและทำงานบนเว็บเซิร์ฟเวอร์แยกต่างหาก) ในขั้นตอนประเภทการให้สิทธิ์นี้ เซิร์ฟเวอร์การให้สิทธิ์จะแสดงผลโทเค็นเพื่อการเข้าถึงโดยตรงเมื่อผู้ใช้ผ่านการตรวจสอบสิทธิ์แล้ว แทนที่จะออกรหัสการให้สิทธิ์ก่อน การให้สิทธิ์โดยปริยายอาจช่วยให้แอปตอบสนองได้ดีขึ้นในบางกรณี แต่ คุณต้องพิจารณาข้อดีนี้เทียบกับผลกระทบด้านความปลอดภัยที่อาจเกิดขึ้นตามที่อธิบายไว้ใน ข้อกำหนด IETF
• ข้อมูลเข้าสู่ระบบรหัสผ่านของเจ้าของทรัพยากร -- ในขั้นตอนการให้สิทธิ์ประเภทนี้ ไคลเอ็นต์จะได้รับ โทเค็นเพื่อการเข้าถึงเมื่อเซิร์ฟเวอร์การให้สิทธิ์ตรวจสอบชื่อผู้ใช้/รหัสผ่านของผู้ใช้แล้ว เราขอแนะนำให้ใช้ขั้นตอนการให้สิทธิ์ประเภทนี้กับแอปพลิเคชันที่เชื่อถือได้สูง ข้อดีของขั้นตอนการให้สิทธิ์ประเภทนี้เมื่อเทียบกับการตรวจสอบสิทธิ์พื้นฐาน เช่น คือผู้ใช้จะป้อนชื่อผู้ใช้/รหัสผ่านเพียงครั้งเดียว จากนั้น จะใช้โทเค็นเพื่อการเข้าถึง
• ข้อมูลเข้าสู่ระบบของไคลเอ็นต์ -- พิจารณาใช้ในกรณีที่แอปไคลเอ็นต์ดำเนินการในนามของตนเอง นั่นคือ ไคลเอ็นต์เป็นเจ้าของทรัพยากรด้วย โดยทั่วไปแล้ว ประเภทการให้สิทธิ์นี้จะใช้เมื่อแอปต้องเข้าถึงบริการพื้นที่เก็บข้อมูลแบ็กเอนด์ เช่น แอปต้องใช้บริการเพื่อทำงาน และบริการนั้นจะมองไม่เห็น สำหรับผู้ใช้ปลายทาง เมื่อใช้ประเภทการให้สิทธิ์นี้ แอปจะได้รับโทเค็นเพื่อการเข้าถึงโดยการแสดงรหัสไคลเอ็นต์และคีย์รหัสลับไคลเอ็นต์ต่อเซิร์ฟเวอร์การให้สิทธิ์ ไม่จำเป็นต้องดำเนินการเพิ่มเติม Edge มีโซลูชันข้อมูลเข้าสู่ระบบของไคลเอ็นต์แบบสำเร็จรูปที่ติดตั้งใช้งานได้ง่ายสำหรับพร็อกซี API ใดก็ได้

โทเค็นเพื่อการเข้าถึง คืออะไร

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

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

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

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

สิทธิ์เข้าถึงแบบจำกัดผ่าน ขอบเขต

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

การลงทะเบียนแอป

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

สรุปกรณีการใช้งาน OAuth 2.0

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

ความปลอดภัยของ OAuth 2.0 เทียบกับคีย์ API

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

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

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

แหล่งข้อมูลที่แนะนำ

การอ่าน

ดูข้อมูลเกี่ยวกับ OAuth 2.0