Google APIs ใช้ โปรโตคอล OAuth 2.0 ในการตรวจสอบสิทธิ์และการให้สิทธิ์ Google รองรับสถานการณ์ทั่วไปของ OAuth 2.0 เช่น สถานการณ์สำหรับเว็บเซิร์ฟเวอร์ ฝั่งไคลเอ็นต์ ติดตั้ง และแอปพลิเคชันในอุปกรณ์อินพุตที่จำกัด
ในการเริ่มต้น ให้ขอรับข้อมูลเข้าสู่ระบบไคลเอ็นต์ OAuth 2.0 จาก Google API Console จากนั้นแอปพลิเคชันไคลเอ็นต์จะขอโทเค็นเพื่อการเข้าถึงจากเซิร์ฟเวอร์การให้สิทธิ์ของ Google แล้วดึงข้อมูลโทเค็นจากการตอบกลับ แล้วส่งโทเค็นไปยัง Google API ที่คุณต้องการเข้าถึง สำหรับการสาธิตแบบอินเทอร์แอกทีฟเกี่ยวกับการใช้ OAuth 2.0 กับ Google (รวมถึงตัวเลือกการใช้ข้อมูลเข้าสู่ระบบไคลเอ็นต์ของคุณเอง) ให้ทดลองใช้ OAuth 2.0 Playground
หน้านี้แสดงภาพรวมของสถานการณ์การให้สิทธิ์ OAuth 2.0 ที่ Google รองรับ และมีลิงก์ไปยังเนื้อหาที่ละเอียดมากขึ้น โปรดดูรายละเอียดเกี่ยวกับการใช้ OAuth 2.0 สำหรับการตรวจสอบสิทธิ์ที่ OpenID Connect
ขั้นตอนเบื้องต้น
แอปพลิเคชันทั้งหมดมีรูปแบบพื้นฐานเมื่อเข้าถึง Google API โดยใช้ OAuth 2.0 ในระดับสูง คุณจะทำตาม 5 ขั้นตอนดังนี้
1. รับข้อมูลเข้าสู่ระบบ OAuth 2.0 จาก Google API Console
ไปที่ Google API Console เพื่อรับข้อมูลเข้าสู่ระบบ OAuth 2.0 เช่น รหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ที่ทั้ง Google และแอปพลิเคชันทราบ ชุดค่าจะแตกต่างกันไปตามประเภทของแอปพลิเคชันที่คุณกำลังสร้าง เช่น แอปพลิเคชัน JavaScript ไม่ต้องใช้ข้อมูลลับ แต่แอปพลิเคชันเว็บเซิร์ฟเวอร์มี
คุณต้องสร้างไคลเอ็นต์ OAuth ที่เหมาะสำหรับแพลตฟอร์มที่แอปจะทำงาน เช่น
- สำหรับฝั่งเซิร์ฟเวอร์หรือเว็บแอป JavaScript ให้ใช้ไคลเอ็นต์ประเภท "เว็บ" อย่าใช้ไคลเอ็นต์ประเภทนี้กับแอปพลิเคชันอื่นๆ เช่น โฆษณาเนทีฟหรือแอปบนอุปกรณ์เคลื่อนที่
- สำหรับแอป Android ให้ใช้ประเภทไคลเอ็นต์ "Android"
- สำหรับแอป iOS และ macOS ให้ใช้ประเภทไคลเอ็นต์ "iOS"
- สำหรับแอป Universal Windows Platform ให้ใช้ประเภทไคลเอ็นต์ "Universal Windows Platform"
- สำหรับอุปกรณ์อินพุตที่จำกัด เช่น ทีวีหรืออุปกรณ์แบบฝัง ให้ใช้ไคลเอ็นต์ประเภท "ทีวีและอุปกรณ์อินพุตแบบจำกัด"
- ใช้บัญชีบริการสำหรับการโต้ตอบแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์
2. รับโทเค็นเพื่อการเข้าถึงจากเซิร์ฟเวอร์การให้สิทธิ์ของ Google
ก่อนที่แอปพลิเคชันจะเข้าถึงข้อมูลส่วนตัวโดยใช้ Google API ได้ แอปพลิเคชันต้องได้รับโทเค็นเพื่อการเข้าถึงที่ให้สิทธิ์เข้าถึง API ดังกล่าว โทเค็นเพื่อการเข้าถึงเดียวอาจให้สิทธิ์เข้าถึง API หลายรายการในระดับที่แตกต่างกัน พารามิเตอร์ตัวแปรที่ชื่อว่า scope
จะควบคุมชุดทรัพยากรและการดำเนินการที่โทเค็นเพื่อการเข้าถึงอนุญาต ในระหว่างการขอโทเค็นเพื่อการเข้าถึง แอปพลิเคชันจะส่งค่าอย่างน้อย 1 ค่าในพารามิเตอร์ scope
การส่งคำขอนี้มีหลายวิธีด้วยกันและแตกต่างกันไปตามประเภทของแอปพลิเคชันที่คุณสร้าง ตัวอย่างเช่น แอปพลิเคชัน JavaScript อาจขอโทเค็นเพื่อการเข้าถึงโดยใช้การเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง Google ขณะที่แอปพลิเคชันที่ติดตั้งในอุปกรณ์ที่ไม่มีเบราว์เซอร์จะใช้คำขอบริการเว็บ
คำขอบางรายการกำหนดให้มีขั้นตอนการตรวจสอบสิทธิ์ซึ่งผู้ใช้เข้าสู่ระบบด้วยบัญชี Google ของตน หลังจากเข้าสู่ระบบแล้ว ระบบจะถามผู้ใช้ว่าต้องการให้สิทธิ์ที่แอปพลิเคชันขออย่างน้อย 1 สิทธิ์หรือไม่ กระบวนการนี้เรียกว่าความยินยอมของผู้ใช้
หากผู้ใช้ให้สิทธิ์อย่างน้อย 1 สิทธิ์ เซิร์ฟเวอร์การให้สิทธิ์ของ Google จะส่งโทเค็นเพื่อการเข้าถึง (หรือรหัสการให้สิทธิ์ที่แอปพลิเคชันใช้รับโทเค็นเพื่อการเข้าถึงได้) และรายการขอบเขตของการเข้าถึงที่โทเค็นนั้นให้สิทธิ์ หากผู้ใช้ไม่ให้สิทธิ์ เซิร์ฟเวอร์จะแสดงข้อผิดพลาด
โดยทั่วไปแล้ว แนวทางปฏิบัติแนะนำคือให้ขอขอบเขตแบบเพิ่มขึ้นเรื่อยๆ ในเวลาที่จำเป็นต้องเข้าถึงเวลา แทนการขอตั้งแต่แรก ตัวอย่างเช่น แอปที่ต้องการรองรับการบันทึกกิจกรรมในปฏิทินไม่ควรขอสิทธิ์เข้าถึง Google ปฏิทินจนกว่าผู้ใช้จะกดปุ่ม "เพิ่มในปฏิทิน" โปรดดูการให้สิทธิ์ที่เพิ่มขึ้น
3. ตรวจสอบขอบเขตของสิทธิ์เข้าถึงที่ผู้ใช้ให้สิทธิ์
เปรียบเทียบขอบเขตที่รวมอยู่ในการตอบกลับโทเค็นเพื่อการเข้าถึงกับขอบเขตที่จำเป็นต่อการเข้าถึงฟีเจอร์และฟังก์ชันการทำงานของแอปพลิเคชันของคุณที่ต้องอาศัยการเข้าถึง Google API ที่เกี่ยวข้อง ปิดใช้ฟีเจอร์ใดๆ ของแอปที่ทำงานไม่ได้หากไม่มีสิทธิ์เข้าถึง API ที่เกี่ยวข้อง
ขอบเขตที่รวมอยู่ในคำขออาจไม่ตรงกับขอบเขตที่ระบุไว้ในการตอบกลับ แม้ว่าผู้ใช้ให้สิทธิ์ขอบเขตที่ขอทั้งหมดแล้วก็ตาม โปรดดูขอบเขตที่จำเป็นสำหรับการเข้าถึงในเอกสารประกอบของ Google API แต่ละรายการ API อาจแมปค่าสตริงขอบเขตหลายค่ากับขอบเขตการเข้าถึงเดียว โดยแสดงผลสตริงขอบเขตเดียวกันสำหรับค่าทั้งหมดที่อนุญาตในคำขอ
ตัวอย่าง: Google People API อาจแสดงผลขอบเขต https://www.googleapis.com/auth/contacts
เมื่อแอปขอสิทธิ์จากผู้ใช้ในขอบเขต https://www.google.com/m8/feeds/
ส่วนเมธอด Google People API people.updateContact
ต้องการขอบเขต https://www.googleapis.com/auth/contacts
ที่ได้รับอนุญาต
4. ส่งโทเค็นเพื่อการเข้าถึงไปยัง API
หลังจากที่แอปพลิเคชันได้รับโทเค็นเพื่อการเข้าถึงแล้ว แอปพลิเคชันจะส่งโทเค็นไปยัง Google API ใน ส่วนหัวคำขอการให้สิทธิ์ HTTP คุณสามารถส่งโทเค็นเป็นพารามิเตอร์สตริงการค้นหา URI ได้ แต่เราไม่แนะนําเนื่องจากพารามิเตอร์ URI อาจอยู่ในไฟล์บันทึกที่ไม่มีความปลอดภัยอย่างสมบูรณ์ นอกจากนี้ แนวทางปฏิบัติที่ดีของ REST เพื่อหลีกเลี่ยงการสร้างชื่อพารามิเตอร์ URI ที่ไม่จำเป็น
โทเค็นเพื่อการเข้าถึงใช้ได้กับชุดการดำเนินการและทรัพยากรที่อธิบายไว้ใน scope
ของคำขอโทเค็นเท่านั้น เช่น หากมีการออกโทเค็นเพื่อการเข้าถึงสำหรับ
Google ปฏิทิน API จะไม่ได้ให้สิทธิ์เข้าถึง Google Contacts API แต่คุณส่งโทเค็นเพื่อการเข้าถึงนั้นไปยัง Google Calendar API ได้หลายครั้งเพื่อการดำเนินการที่คล้ายกัน
5. รีเฟรชโทเค็นเพื่อการเข้าถึง หากจำเป็น
โทเค็นเพื่อการเข้าถึงมีอายุการใช้งานที่จำกัด หากแอปพลิเคชันต้องการสิทธิ์เข้าถึง Google API เมื่อพ้นอายุการใช้งานของโทเค็นเพื่อการเข้าถึงเดียว แอปพลิเคชันจะรับโทเค็นการรีเฟรชได้ โทเค็นการรีเฟรชช่วยให้แอปพลิเคชันรับโทเค็นเพื่อการเข้าถึงใหม่ได้
สถานการณ์
แอปพลิเคชันเว็บเซิร์ฟเวอร์
ปลายทาง Google OAuth 2.0 รองรับแอปพลิเคชันเว็บเซิร์ฟเวอร์ที่ใช้ภาษาและเฟรมเวิร์ก เช่น PHP, Java, Go, Python, Ruby และ ASP.NET
ลำดับการให้สิทธิ์จะเริ่มต้นเมื่อแอปพลิเคชันเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ของ Google โดยที่ URL จะมีพารามิเตอร์การค้นหาที่ระบุประเภทการเข้าถึงที่ขอ Google จะจัดการการตรวจสอบสิทธิ์ผู้ใช้ การเลือกเซสชัน และความยินยอมของผู้ใช้ ผลลัพธ์คือรหัสการให้สิทธิ์ ซึ่งแอปพลิเคชันแลกเปลี่ยนกับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรชได้
แอปพลิเคชันควรจัดเก็บโทเค็นการรีเฟรชไว้ใช้ในอนาคตและใช้โทเค็นเพื่อการเข้าถึงเพื่อเข้าถึง Google API เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ แอปพลิเคชันจะใช้โทเค็นการรีเฟรชเพื่อรับโทเค็นใหม่
![แอปพลิเคชันของคุณจะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับรหัสการให้สิทธิ์, แลกเปลี่ยนรหัสสำหรับโทเค็น และใช้โทเค็นดังกล่าวเพื่อเรียกใช้ปลายทาง Google API](https://developers.google.cn/static/identity/protocols/oauth2/images/flows/authorization-code.png?hl=th)
โปรดดูรายละเอียดที่การใช้ OAuth 2.0 สำหรับแอปพลิเคชันเว็บเซิร์ฟเวอร์
แอปพลิเคชันที่ติดตั้ง
อุปกรณ์ปลายทางของ Google OAuth 2.0 รองรับแอปพลิเคชันที่ติดตั้งในอุปกรณ์ เช่น คอมพิวเตอร์ อุปกรณ์เคลื่อนที่ และแท็บเล็ต เมื่อคุณสร้างรหัสไคลเอ็นต์ผ่าน Google API Console ให้ระบุว่าเป็นแอปพลิเคชันที่ติดตั้ง จากนั้นเลือก Android, แอป Chrome, iOS, Universal Windows Platform (UWP) หรือแอปบนเดสก์ท็อป
กระบวนการทำให้เกิดรหัสไคลเอ็นต์ และในบางกรณีอาจเป็นรหัสลับไคลเอ็นต์ซึ่งคุณฝังไว้ในซอร์สโค้ดของแอปพลิเคชัน (ในบริบทนี้ เห็นได้ชัดว่ารหัสลับไคลเอ็นต์ไม่ถือว่าเป็นความลับ)
ลำดับการให้สิทธิ์จะเริ่มต้นเมื่อแอปพลิเคชันเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ของ Google โดยที่ URL จะมีพารามิเตอร์การค้นหาที่ระบุประเภทการเข้าถึงที่ขอ Google จะจัดการการตรวจสอบสิทธิ์ผู้ใช้ การเลือกเซสชัน และความยินยอมของผู้ใช้ ผลลัพธ์คือรหัสการให้สิทธิ์ ซึ่งแอปพลิเคชันแลกเปลี่ยนกับโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรชได้
แอปพลิเคชันควรจัดเก็บโทเค็นการรีเฟรชไว้ใช้ในอนาคตและใช้โทเค็นเพื่อการเข้าถึงเพื่อเข้าถึง Google API เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ แอปพลิเคชันจะใช้โทเค็นการรีเฟรชเพื่อรับโทเค็นใหม่
![แอปพลิเคชันของคุณจะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับรหัสการให้สิทธิ์, แลกเปลี่ยนรหัสสำหรับโทเค็น และใช้โทเค็นดังกล่าวเพื่อเรียกใช้ปลายทาง Google API](https://developers.google.cn/static/identity/protocols/oauth2/images/flows/authorization-code.png?hl=th)
โปรดดูรายละเอียดที่หัวข้อ การใช้ OAuth 2.0 สำหรับแอปพลิเคชันที่ติดตั้ง
แอปพลิเคชันฝั่งไคลเอ็นต์ (JavaScript)
อุปกรณ์ปลายทางของ Google OAuth 2.0 รองรับแอปพลิเคชัน JavaScript ที่ทำงานในเบราว์เซอร์
ลำดับการให้สิทธิ์จะเริ่มต้นเมื่อแอปพลิเคชันเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ของ Google โดยที่ URL จะมีพารามิเตอร์การค้นหาที่ระบุประเภทการเข้าถึงที่ขอ Google จะจัดการการตรวจสอบสิทธิ์ผู้ใช้ การเลือกเซสชัน และความยินยอมของผู้ใช้
ผลลัพธ์คือโทเค็นเพื่อการเข้าถึง ซึ่งไคลเอ็นต์ควรตรวจสอบก่อนที่จะรวมไว้ในคำขอ Google API เมื่อโทเค็นหมดอายุ แอปพลิเคชันจะทำซ้ำกระบวนการ
![แอปพลิเคชัน JS จะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google, รับโทเค็น, ตรวจสอบโทเค็น และใช้โทเค็นดังกล่าวเพื่อเรียกใช้ปลายทาง Google API](https://developers.google.cn/static/identity/protocols/oauth2/images/flows/implicit.png?hl=th)
โปรดดูรายละเอียดที่หัวข้อการใช้ OAuth 2.0 สำหรับแอปพลิเคชันฝั่งไคลเอ็นต์
แอปพลิเคชันในอุปกรณ์อินพุตที่จำกัด
อุปกรณ์ปลายทางของ Google OAuth 2.0 รองรับแอปพลิเคชันที่ทำงานบนอุปกรณ์อินพุตที่จำกัด เช่น คอนโซลเกม กล้องวิดีโอ และเครื่องพิมพ์
ลำดับการให้สิทธิ์เริ่มต้นด้วยการที่แอปพลิเคชันส่งคำขอบริการบนเว็บไปยัง URL ของ Google เพื่อขอรหัสการให้สิทธิ์ การตอบกลับมีพารามิเตอร์หลายรายการ ซึ่งรวมถึง URL และโค้ดที่แอปพลิเคชันแสดงให้ผู้ใช้เห็น
ผู้ใช้จะได้รับ URL และโค้ดจากอุปกรณ์ จากนั้นเปลี่ยนไปใช้อุปกรณ์หรือคอมพิวเตอร์แยกต่างหากที่มีความสามารถในการป้อนข้อมูลที่สมบูรณ์ยิ่งขึ้น ผู้ใช้เปิดเบราว์เซอร์แล้วไปยัง URL ที่ระบุ จากนั้นลงชื่อเข้าสู่ระบบแล้วป้อนรหัส
ในขณะเดียวกัน แอปพลิเคชันจะสำรวจ URL ของ Google ในช่วงเวลาที่กำหนด หลังจากที่ผู้ใช้อนุมัติสิทธิ์เข้าถึง การตอบกลับจากเซิร์ฟเวอร์ Google จะมีโทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช แอปพลิเคชันควรจัดเก็บโทเค็นการรีเฟรชไว้ใช้ในอนาคตและใช้โทเค็นเพื่อการเข้าถึงเพื่อเข้าถึง Google API เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุ แอปพลิเคชันจะใช้โทเค็นการรีเฟรชเพื่อรับโทเค็นใหม่
![ผู้ใช้เข้าสู่ระบบในอุปกรณ์อีกเครื่องหนึ่งที่มีเบราว์เซอร์](https://developers.google.cn/static/identity/protocols/images/oauth2/device/flow.png?hl=th)
โปรดดูรายละเอียดที่การใช้ OAuth 2.0 สำหรับอุปกรณ์
บัญชีบริการ
Google API เช่น Prediction API และ Google Cloud Storage สามารถดำเนินการในนามของแอปพลิเคชันได้โดยไม่ต้องเข้าถึงข้อมูลผู้ใช้ ในสถานการณ์เหล่านี้ แอปพลิเคชันของคุณต้องพิสูจน์ตัวตนกับ API แต่ไม่จำเป็นต้องได้รับความยินยอมจากผู้ใช้ ในทำนองเดียวกัน ในกรณีองค์กร แอปพลิเคชันของคุณจะขอสิทธิ์การเข้าถึงที่ได้รับมอบสิทธิ์สำหรับทรัพยากรบางอย่างได้
สำหรับการโต้ตอบแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์เหล่านี้ คุณจะต้องมีบัญชีบริการ ซึ่งเป็นบัญชีที่เป็นของแอปพลิเคชันของคุณ แทนที่จะเป็นของผู้ใช้ปลายทางแต่ละคน แอปพลิเคชันของคุณจะเรียกใช้ Google API ในนามของบัญชีบริการ และไม่จำเป็นต้องได้รับความยินยอมจากผู้ใช้ (ในสถานการณ์ที่ไม่ใช่บัญชีบริการ แอปพลิเคชันของคุณจะเรียกใช้ Google API ในนามของผู้ใช้ปลายทาง และบางครั้งต้องได้รับความยินยอมจากผู้ใช้)
ข้อมูลเข้าสู่ระบบของบัญชีบริการซึ่งคุณได้รับจาก Google API Consoleประกอบด้วยอีเมลที่สร้างขึ้นซึ่งไม่ซ้ำกัน รหัสไคลเอ็นต์ และคู่คีย์สาธารณะ/ส่วนตัวอย่างน้อย 1 คู่ คุณใช้รหัสไคลเอ็นต์และคีย์ส่วนตัว 1 รายการเพื่อสร้าง JWT ที่ลงนามแล้ว และสร้างคำขอโทเค็นเพื่อการเข้าถึงในรูปแบบที่เหมาะสม จากนั้นแอปพลิเคชันจะส่งคำขอโทเค็นไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google OAuth 2.0 ซึ่งจะส่งคืนโทเค็นเพื่อการเข้าถึง แอปพลิเคชันจะใช้โทเค็นเพื่อเข้าถึง Google API เมื่อโทเค็นหมดอายุ แอปพลิเคชันจะทำซ้ำกระบวนการ
![แอปพลิเคชันเซิร์ฟเวอร์ใช้ JWT เพื่อขอโทเค็นจากเซิร์ฟเวอร์การให้สิทธิ์ของ Google จากนั้นใช้โทเค็นดังกล่าวเพื่อเรียกใช้ปลายทาง Google API โดยผู้ใช้ปลายทางไม่มีส่วนร่วม](https://developers.google.cn/static/identity/protocols/oauth2/images/flows/jwt.png?hl=th)
โปรดดูรายละเอียดที่ เอกสารเกี่ยวกับบัญชีบริการ
ขนาดโทเค็น
โทเค็นอาจมีขนาดแตกต่างกันไปตามขีดจำกัดต่อไปนี้
- รหัสการให้สิทธิ์: 256 ไบต์
- โทเค็นเพื่อการเข้าถึง: 2048 ไบต์
- โทเค็นการรีเฟรช: 512 ไบต์
โทเค็นเพื่อการเข้าถึงที่แสดงผลโดย Security Token Service API ของ Google Cloud มีโครงสร้างคล้ายกับโทเค็นเพื่อการเข้าถึง OAuth 2.0 ของ Google API แต่มีขีดจำกัดขนาดโทเค็นที่แตกต่างกัน โปรดดูรายละเอียดที่ เอกสารประกอบของ API
Google ขอสงวนสิทธิ์ในการเปลี่ยนขนาดโทเค็นให้อยู่ภายในขีดจำกัดเหล่านี้ และแอปพลิเคชันของคุณต้องรองรับขนาดโทเค็นที่เปลี่ยนแปลงได้ให้สอดคล้องกัน
การหมดอายุของโทเค็นสำหรับรีเฟรช
คุณต้องเขียนโค้ดเพื่อคาดการณ์ความเป็นไปได้ที่โทเค็นการรีเฟรชที่ได้รับอาจใช้ไม่ได้อีกต่อไป โทเค็นการรีเฟรชอาจหยุดทำงานเนื่องจากสาเหตุข้อใดข้อหนึ่งต่อไปนี้
- ผู้ใช้ได้เพิกถอนสิทธิ์เข้าถึงของแอป
- โทเค็นการรีเฟรชไม่มีการใช้งานมา 6 เดือนแล้ว
- ผู้ใช้เปลี่ยนรหัสผ่านและโทเค็นการรีเฟรชมีขอบเขตของ Gmail
- บัญชีผู้ใช้มีโทเค็นการรีเฟรชที่อนุญาต (ใช้งานจริง) เกินจำนวนสูงสุดแล้ว
- หากผู้ดูแลระบบ
ตั้งค่าบริการที่ขอในขอบเขตของแอปเป็น "จำกัด" (ข้อผิดพลาดคือ
admin_policy_enforced
) - สำหรับ Google Cloud Platform API - เซสชันอาจเกินขีดจำกัดที่ผู้ดูแลระบบกำหนด
โปรเจ็กต์ Google Cloud Platform ที่มีหน้าจอขอความยินยอม OAuth ที่กำหนดค่าสำหรับประเภทผู้ใช้ภายนอกและมีสถานะการเผยแพร่เป็น "การทดสอบ" จะได้รับโทเค็นการรีเฟรชที่หมดอายุใน 7 วัน เว้นแต่ขอบเขต OAuth ที่ขอเพียงรายการเดียวคือชุดย่อยของชื่อ อีเมล และโปรไฟล์ผู้ใช้ (ผ่านขอบเขต
userinfo.email, userinfo.profile, openid
หรือรายการที่เทียบเท่าของ OpenID Connect)
ปัจจุบันมีการจำกัดโทเค็นการรีเฟรชไว้ที่ 100 โทเค็นต่อบัญชี Google 1 รหัสต่อรหัสไคลเอ็นต์ OAuth 2.0 หากถึงขีดจำกัดแล้ว การสร้างโทเค็นการรีเฟรชใหม่จะทำให้โทเค็นการรีเฟรชที่เก่าที่สุดใช้งานไม่ได้โดยอัตโนมัติโดยไม่มีคำเตือน ขีดจำกัดนี้ไม่มีผลกับบัญชีบริการ
นอกจากนี้ยังมีขีดจำกัดที่สูงกว่าสำหรับจำนวนโทเค็นการรีเฟรชทั้งหมดที่บัญชีผู้ใช้หรือบัญชีบริการจะมีในไคลเอ็นต์ทั้งหมด ผู้ใช้ทั่วไปส่วนใหญ่จะใช้งานไม่เกินขีดจำกัดนี้ แต่บัญชีของนักพัฒนาแอปที่ใช้เพื่อทดสอบการติดตั้งใช้งานอาจทำไม่ได้
หากคุณต้องการให้สิทธิ์โปรแกรม เครื่อง หรืออุปกรณ์หลายเครื่อง วิธีแก้ปัญหาวิธีหนึ่งคือจำกัดจำนวนไคลเอ็นต์ที่คุณให้สิทธิ์ต่อบัญชี Google ไว้ที่ 15 หรือ 20 เครื่อง หากคุณเป็น ผู้ดูแลระบบ Google Workspace คุณสามารถสร้างผู้ใช้เพิ่มเติมที่มีสิทธิ์ระดับผู้ดูแลระบบ และใช้ผู้ใช้เหล่านั้นเพื่อให้สิทธิ์ ไคลเอ็นต์บางส่วนได้
การจัดการนโยบายการควบคุมเซสชันสำหรับองค์กรที่ใช้ Google Cloud Platform (GCP)
ผู้ดูแลระบบขององค์กร GCP อาจกำหนดให้มีการตรวจสอบสิทธิ์ผู้ใช้ซ้ำบ่อยครั้งขณะเข้าถึงทรัพยากร GCP โดยใช้ฟีเจอร์การควบคุมเซสชันของ Google Cloud นโยบายนี้ส่งผลต่อการเข้าถึง Google Cloud Console, Google Cloud SDK (หรือที่เรียกว่า gcloud CLI) และแอปพลิเคชัน OAuth ของบุคคลที่สามที่ต้องใช้ขอบเขต Cloud Platform หากผู้ใช้มีนโยบายการควบคุมเซสชันอยู่ เมื่อระยะเวลาเซสชันหมดอายุ การเรียก API ของคุณจะมีข้อผิดพลาดคล้ายกับสิ่งที่จะเกิดขึ้นหากมีการเพิกถอนโทเค็นการรีเฟรช ซึ่งจะเรียกใช้ไม่สำเร็จโดยมีข้อผิดพลาดประเภท invalid_grant
ช่อง error_subtype
สามารถใช้เพื่อแยกแยะระหว่างโทเค็นที่เพิกถอนกับความล้มเหลวเนื่องจากนโยบายการควบคุมเซสชัน (เช่น "error_subtype": "invalid_rapt"
) เนื่องจากระยะเวลาเซสชันจะต้องเริ่มใหม่อย่างจำกัดมาก (ระหว่าง 4 ชั่วโมงจะมีการจัดการอย่างผ่อนปรน) (ระหว่าง 4 ชั่วโมงจะมีการจัดการอย่างมีระยะเวลาจำกัด) กล่าวคือ ช่วงเวลาการตรวจสอบสิทธิ์จะถูกจำกัดอย่างมาก (ระหว่าง 4 ชั่วโมงในการตรวจสอบสิทธิ์จะมีการจัดการเพียง 2 ชั่วโมง)
ในทำนองเดียวกัน คุณต้องไม่ใช้หรือสนับสนุนให้ใช้ข้อมูลเข้าสู่ระบบของผู้ใช้สำหรับการติดตั้งใช้งานแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ หากมีการติดตั้งใช้งานข้อมูลเข้าสู่ระบบของผู้ใช้ในเซิร์ฟเวอร์สำหรับงานหรือการดำเนินงานที่ใช้เวลานาน และลูกค้าใช้นโยบายการควบคุมเซสชันกับผู้ใช้ดังกล่าว แอปพลิเคชันเซิร์ฟเวอร์จะล้มเหลวเนื่องจากจะไม่มีวิธีตรวจสอบสิทธิ์ผู้ใช้อีกครั้งเมื่อระยะเวลาเซสชันหมดอายุ
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีช่วยลูกค้านำฟีเจอร์นี้ไปใช้งานได้ที่บทความช่วยเหลือนี้ที่มุ่งเน้นผู้ดูแลระบบ
ไลบรารีของไคลเอ็นต์
ไลบรารีของไคลเอ็นต์ต่อไปนี้ผสานรวมกับเฟรมเวิร์กยอดนิยม ซึ่งทำให้การใช้งาน OAuth 2.0 ง่ายขึ้น และเราจะเพิ่มฟีเจอร์อื่นๆ ไปยังคลังในอนาคต
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ Java
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ Python
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ Go
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ .NET
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ Ruby
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ PHP
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ JavaScript
- GTMAppAuth - ไลบรารีของไคลเอ็นต์ OAuth สำหรับ Mac และ iOS