คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล
หน้าแรกของ OAuth: ดูหน้าแรกของ OAuth สำหรับมุมมองระดับบนสุดของคำแนะนำ OAuth ที่เราระบุไว้
หัวข้อนี้จะแสดงภาพรวมพื้นฐานของ OAuth 2.0 ใน Apigee Edge
OAuth 2.0 คืออะไร
มีหนังสือ บล็อก และเว็บไซต์จำนวนมากที่ใช้ OAuth 2.0 เราขอแนะนำเป็นอย่างยิ่งให้คุณเริ่มด้วยการอ่านข้อมูลจำเพาะของ IETF OAuth 2.0 นี่คือคำจำกัดความของ 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 คืออะไร
ให้คิดว่าการให้สิทธิ์ประเภทต่างๆ คือเส้นทางหรือการโต้ตอบต่างๆ ที่แอปสามารถทำได้เพื่อรับโทเค็นเพื่อการเข้าถึง การให้สิทธิ์แต่ละประเภทจะจัดการ Use Case อย่างน้อย 1 กรณี และคุณจะต้องเลือกประเภทการให้สิทธิ์ที่จะใช้ตามความต้องการของคุณเอง โดยทั่วไปแล้ว การให้สิทธิ์แต่ละประเภทมีทั้งข้อดีและข้อเสีย และคุณจะต้องพิจารณาข้อดีและข้อเสียต่างๆ ตามกรณีการใช้งานทางธุรกิจ ข้อควรพิจารณาที่สำคัญอย่างหนึ่งคือ "ความน่าเชื่อถือ" ของแอปที่จะเข้าถึงข้อมูลของคุณ โดยทั่วไปแล้ว แอปของบุคคลที่สามจะมีความน่าเชื่อถือน้อยกว่าแอปที่พัฒนาและใช้ภายในองค์กร
Apigee Edge รองรับการให้สิทธิ์ OAuth 2.0 หลัก 4 ประเภทดังนี้
- รหัสการให้สิทธิ์ -- เป็นประเภทการให้สิทธิ์ที่ปลอดภัยที่สุด ก่อนที่เซิร์ฟเวอร์การให้สิทธิ์จะออกโทเค็นเพื่อการเข้าถึง แอปต้องได้รับรหัสการให้สิทธิ์จากเซิร์ฟเวอร์ทรัพยากรก่อน คุณเห็นขั้นตอนนี้ทุกครั้งที่แอปเปิดเบราว์เซอร์ไปยังหน้าเข้าสู่ระบบของเซิร์ฟเวอร์ทรัพยากรและเชิญให้คุณเข้าสู่ระบบบัญชีจริง (เช่น Facebook หรือ Twitter)
หากคุณเข้าสู่ระบบสำเร็จ แอปจะได้รับรหัสการให้สิทธิ์ ซึ่งสามารถใช้เพื่อเจรจาโทเค็นการเข้าถึงกับเซิร์ฟเวอร์การให้สิทธิ์ โดยปกติแล้ว การให้สิทธิ์ประเภทนี้จะใช้เมื่อแอปอยู่ในเซิร์ฟเวอร์ ไม่ใช่ในไคลเอ็นต์ การให้สิทธิ์ประเภทนี้ถือว่ามีความปลอดภัยสูงเพราะแอปไคลเอ็นต์จะไม่จัดการหรือเห็นชื่อผู้ใช้หรือรหัสผ่านของผู้ใช้สำหรับเซิร์ฟเวอร์ทรัพยากร (เช่น แอปไม่เคยเห็นหรือจัดการข้อมูลเข้าสู่ระบบ Twitter ของคุณ) ขั้นตอนประเภทการให้สิทธิ์นี้เรียกอีกอย่างว่า OAuth "แบบ 3 ทาง"
- implicit -- ถือเป็นรหัสการให้สิทธิ์เวอร์ชันที่เรียบง่าย โดยปกติแล้ว การให้สิทธิ์ประเภทนี้จะใช้เมื่อแอปอยู่ในไคลเอ็นต์ เช่น โค้ดของแอปมีการใช้งานในเบราว์เซอร์โดยใช้ JavaScript หรือภาษาสคริปต์อื่น (แทนที่จะเรียกใช้และใช้ในเว็บเซิร์ฟเวอร์ที่แยกต่างหาก) ในขั้นตอนประเภทการให้สิทธิ์นี้ เซิร์ฟเวอร์การให้สิทธิ์จะส่งกลับโทเค็นเพื่อการเข้าถึงโดยตรงเมื่อผู้ใช้ผ่านการตรวจสอบสิทธิ์ แทนที่จะออกรหัสการให้สิทธิ์ก่อน ในบางกรณี การให้สิทธิ์โดยนัยอาจช่วยปรับปรุงการตอบสนองของแอปได้ แต่ สิทธิประโยชน์นี้ต้องแสดงให้เห็นถึงผลกระทบด้านความปลอดภัยที่อาจเกิดขึ้นตามที่อธิบายไว้ใน ข้อกำหนด IETF
- ข้อมูลเข้าสู่ระบบรหัสผ่านของเจ้าของทรัพยากร ในขั้นตอนนี้ ระบบจะออกโทเค็นการเข้าถึงให้ไคลเอ็นต์เมื่อชื่อผู้ใช้/รหัสผ่านของผู้ใช้ได้รับการตรวจสอบโดยเซิร์ฟเวอร์การให้สิทธิ์ เราขอแนะนำขั้นตอนนี้สำหรับแอปพลิเคชันที่เชื่อถือได้สูง ข้อดีของโฟลว์นี้ เช่น การตรวจสอบสิทธิ์พื้นฐาน คือผู้ใช้แสดงชื่อผู้ใช้/รหัสผ่านเพียงครั้งเดียว จากนั้น เราจะใช้โทเค็นเพื่อการเข้าถึง
- ข้อมูลเข้าสู่ระบบของไคลเอ็นต์ -- พิจารณาใช้ในกรณีที่แอปไคลเอ็นต์ดำเนินการในนามของแอปเอง กล่าวคือ ไคลเอ็นต์จะเป็นเจ้าของทรัพยากรด้วย เช่น การให้สิทธิ์ประเภทนี้มักจะใช้เมื่อแอปจำเป็นต้องเข้าถึงบริการพื้นที่เก็บข้อมูลแบ็กเอนด์ แอปต้องใช้บริการในการทำงาน และบริการไม่ชัดเจนสำหรับผู้ใช้ปลายทาง การให้สิทธิ์ประเภทนี้ทำให้แอปรับโทเค็นเพื่อการเข้าถึงได้โดยแสดงรหัสไคลเอ็นต์และคีย์รหัสลับไคลเอ็นต์ของเซิร์ฟเวอร์การให้สิทธิ์ ไม่ต้องดำเนินการเพิ่มเติมใดๆ Edge มีโซลูชันข้อมูลเข้าสู่ระบบไคลเอ็นต์ที่พร้อมใช้งานทันที ซึ่งนำไปใช้กับพร็อกซี API ได้ง่าย
โทเค็นเพื่อการเข้าถึงคืออะไร
โทเค็นเพื่อการเข้าถึงเป็นสตริงแบบยาวของอักขระซึ่งทำหน้าที่เป็นข้อมูลเข้าสู่ระบบที่ใช้ในการเข้าถึงทรัพยากรที่มีการป้องกัน ระบบจะส่งโทเค็นทรัพยากร (หรือที่เรียกว่าโทเค็นสำหรับผู้ถือ) ในส่วนหัวการให้สิทธิ์ ดังนี้
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
เซิร์ฟเวอร์ทรัพยากรเข้าใจว่าโทเค็นเพื่อการเข้าถึง "ย่อมาจาก" สำหรับข้อมูลเข้าสู่ระบบ เช่น ชื่อผู้ใช้และรหัสผ่าน นอกจากนี้ โทเค็นเพื่อการเข้าถึงอาจออกได้โดยมีข้อจำกัด เช่น แอปอ่านได้แต่เขียนหรือลบข้อมูลในเซิร์ฟเวอร์ทรัพยากรไม่ได้ โปรดทราบว่า โทเค็นเพื่อการเข้าถึงจะเพิกถอนได้ในกรณีต่างๆ เช่น แอปถูกบุกรุก ในกรณีนี้ คุณจะต้องรับโทเค็นเพื่อการเข้าถึงใหม่เพื่อใช้แอปต่อไป แต่คุณไม่ต้องเปลี่ยนชื่อผู้ใช้หรือรหัสผ่านในเซิร์ฟเวอร์ทรัพยากรที่มีการป้องกัน (เช่น Facebook หรือ Twitter)
โดยทั่วไปแล้ว โทเค็นเพื่อการเข้าถึงจะมีวันหมดอายุ (เพื่อเหตุผลด้านความปลอดภัย) การให้สิทธิ์บางประเภทอนุญาตให้เซิร์ฟเวอร์การให้สิทธิ์ออกโทเค็นการรีเฟรช ซึ่งจะช่วยให้แอปเรียกโทเค็นเพื่อการเข้าถึงใหม่ได้เมื่อโทเค็นเก่าหมดอายุ สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับโทเค็นเพื่อการเข้าถึงและรีเฟรช โปรดดูข้อมูลจำเพาะของ IETF OAuth 2.0
การเข้าถึงที่จำกัดผ่านขอบเขต
OAuth 2.0 สามารถให้สิทธิ์แอปในการเข้าถึงทรัพยากรที่มีการป้องกันได้อย่างจำกัดผ่านกลไกของขอบเขต เช่น แอปอาจมีสิทธิ์เข้าถึงทรัพยากรบางรายการ อาจอัปเดตทรัพยากรได้ หรืออาจได้รับสิทธิ์การเข้าถึงระดับอ่านอย่างเดียวเท่านั้น ตามกระบวนการ OAuth แบบ "3 ทาง" โดยทั่วไปผู้ใช้จะจะระบุระดับการเข้าถึงผ่านหน้าความยินยอม (เช่น หน้าเว็บที่ผู้ใช้เลือกขอบเขตด้วยช่องทำเครื่องหมายของกลไกอื่นๆ)
การลงทะเบียนแอป
ไคลเอ็นต์ (แอป) ทั้งหมดต้องลงทะเบียนกับเซิร์ฟเวอร์การให้สิทธิ์ OAuth 2.0 ต้นทางที่จะขอโทเค็นเพื่อการเข้าถึง เมื่อลงทะเบียนแอป คุณจะได้รับชุดคีย์กลับคืนมา คีย์แรกคือคีย์สาธารณะที่เรียกว่าตัวระบุไคลเอ็นต์ ส่วนอีกคีย์เป็นคีย์ลับที่เรียกว่ารหัสลับไคลเอ็นต์ หากไม่มีคีย์เหล่านี้ แอปจะออกคำขอรหัสการให้สิทธิ์หรือโทเค็นเพื่อการเข้าถึงเซิร์ฟเวอร์การให้สิทธิ์ไม่ได้ โปรดทราบว่าแม้ข้อกำหนด IETF OAuth จะเรียกรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ของคีย์เหล่านี้ แต่ UI ของ Apigee Edge เรียกใช้รหัสดังกล่าวและข้อมูลลับของผู้บริโภค ซึ่งเหมือนกัน
สรุปกรณีการใช้งาน OAuth 2.0
ขั้นตอนประเภทการให้สิทธิ์ OAuth 2.0 ที่คุณเลือกใช้จะขึ้นอยู่กับกรณีการใช้งานของคุณ เนื่องจากการให้สิทธิ์บางประเภทมีความปลอดภัยมากกว่าประเภทอื่นๆ ประเภทการให้สิทธิ์ที่คุณเลือกขึ้นอยู่กับความน่าเชื่อถือของแอปไคลเอ็นต์ และจำเป็นต้องมีการพิจารณาอย่างรอบคอบมากดังที่อธิบายไว้ในตารางต่อไปนี้
| กรณีการใช้งาน | ความน่าชื่อถือได้ | ประเภทการให้สิทธิ์ OAuth 2.0 ที่แนะนำ | คำอธิบาย |
|---|---|---|---|
| B2B (เอ็กซ์ทราเน็ต), อินทราเน็ต และอื่นๆ |
แอปที่ได้รับความไว้วางใจสูง ซึ่งเขียนโดยนักพัฒนาซอฟต์แวร์ภายในหรือนักพัฒนาซอฟต์แวร์ที่มีความสัมพันธ์ทางธุรกิจที่เชื่อถือได้กับผู้ให้บริการ API แอปที่จำเป็นต้องเข้าถึงทรัพยากรในนามของตนเอง |
|
|
| ไซต์อินทราเน็ต พอร์ทัล |
แอปที่เชื่อถือได้ซึ่งเขียนโดยนักพัฒนาแอปภายในหรือบุคคลที่สามที่เชื่อถือได้ ตัวอย่างที่ดีคือการเข้าสู่ระบบเว็บไซต์ HR ของบริษัทเพื่อเลือกประกันภัย ส่งรีวิว หรือเปลี่ยนข้อมูลส่วนบุคคล |
|
|
| แอปที่เผยแพร่ต่อสาธารณะ | แอปที่ไม่น่าเชื่อถือเขียนขึ้นโดยนักพัฒนาแอปบุคคลที่สามซึ่งไม่มีความสัมพันธ์ทางธุรกิจที่เชื่อถือได้กับผู้ให้บริการ API เช่น นักพัฒนาแอปที่ลงทะเบียนโปรแกรม API สาธารณะไม่ควรเชื่อถือนักพัฒนาแอป |
|
|
| B2C | มีผู้ใช้ปลายทาง 1 คน (ผู้ใช้อุปกรณ์เคลื่อนที่) และข้อมูลเข้าสู่ระบบของผู้ใช้จะจัดเก็บไว้ในอุปกรณ์เคลื่อนที่ |
|
|
การรักษาความปลอดภัยของ OAuth 2.0 เทียบกับคีย์ API
การตรวจสอบคีย์ API ต้องใช้แอปเพื่อส่งคีย์ไปยัง Edge คีย์ต้องเป็นคีย์ผู้บริโภคที่ถูกต้องจากแอปนักพัฒนาซอฟต์แวร์ Apigee Edge ที่เชื่อมโยงกับพร็อกซี API หากต้องเพิกถอนสิทธิ์เพื่อให้แอปไคลเอ็นต์เรียกใช้พร็อกซีด้วยเหตุผลบางประการ คุณต้องเพิกถอนคีย์ผู้บริโภคดังกล่าว นอกจากนี้แอปไคลเอ็นต์ที่ใช้คีย์ดังกล่าวจะเข้าถึงพร็อกซี API ไม่ได้ด้วย ในทางกลับกัน คุณเพิกถอนโทเค็น OAuth ได้ทุกเมื่อโดยไม่ต้องเพิกถอนคีย์ของแอป แอปสามารถขอโทเค็นใหม่ในนามของผู้ใช้ได้ และหากมีการให้สิทธิ์โทเค็น แอปก็จะใช้พร็อกซี API ต่อไปได้
ความแตกต่างอีกข้อระหว่างคีย์ API และโทเค็นคือโทเค็นอาจมีแอตทริบิวต์ข้อมูลเมตาที่คุณดึงและใช้ได้ในภายหลัง ตัวอย่างเช่น คุณอาจจัดเก็บรหัสของผู้ใช้ที่เรียก API และใช้เพื่อปรับแต่งการเรียกไปยังบริการแบ็กเอนด์
ดูรายละเอียดเกี่ยวกับการตรวจสอบคีย์ API ได้ที่คีย์ API สำหรับข้อมูลเกี่ยวกับการใช้แอตทริบิวต์ที่กำหนดเองกับโทเค็น OAuth โปรดดูที่การปรับแต่งโทเค็นและรหัสการให้สิทธิ์