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

คุณกำลังดูเอกสารประกอบ 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 รายการ และคุณจะต้องเลือกว่าการให้สิทธิ์ใด ประเภทที่จะใช้ตามความต้องการของคุณเอง โดยทั่วไป การให้สิทธิ์แต่ละประเภทมีข้อดีและ ข้อเสีย และคุณต้องพิจารณาข้อดีข้อเสียโดยพิจารณาจากกรณีการใช้งานทางธุรกิจของคุณ หนึ่ง ที่ควรคำนึงถึงก็คือ "ความน่าเชื่อถือ" ของแอปที่จะเข้าถึงข้อมูลของคุณ โดยทั่วไปแล้ว แอปของบุคคลที่สามจะมีความน่าเชื่อถือน้อยกว่าแอปที่พัฒนาและใช้ภายใน Enterprise

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

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

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

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

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

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

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

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

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

การเข้าถึงที่จำกัดผ่าน ขอบเขต

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

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

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

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

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

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

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

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

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

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

แนะนำ ทรัพยากร

การอ่าน

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