การลิงก์บัญชี Google กับ OAuth

บัญชีลิงก์กันโดยใช้ขั้นตอนโดยนัยและรหัสการให้สิทธิ์ OAuth 2.0 ตามมาตรฐานอุตสาหกรรม บริการของคุณต้องรองรับปลายทางการให้สิทธิ์ที่เป็นไปตามข้อกําหนด OAuth 2.0 และโทเค็นการแลกเปลี่ยน

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

ในกระบวนการรหัสการให้สิทธิ์ คุณต้องมีปลายทาง 2 จุด ได้แก่

• ปลายทางการให้สิทธิ์ซึ่งจะแสดง UI การลงชื่อเข้าใช้แก่ผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ ปลายทางการให้สิทธิ์จะสร้างรหัสการให้สิทธิ์ที่ใช้งานได้ชั่วคราวเพื่อบันทึกผู้ใช้&#39 และให้ความยินยอมแก่การเข้าถึงที่ขอ

• ปลายทาง token Exchange ซึ่งรับผิดชอบ Exchange 2 ประเภทดังนี้

  1. แลกเปลี่ยนรหัสการให้สิทธิ์สําหรับโทเค็นการรีเฟรชเป็นระยะเวลานานและโทเค็นเพื่อการเข้าถึงที่ใช้งานได้เป็นระยะเวลาสั้นๆ ซึ่ง Exchange นี้จะเกิดขึ้นเมื่อผู้ใช้ทําตามขั้นตอนการลิงก์บัญชี
  2. แลกเปลี่ยนโทเค็นการรีเฟรชเป็นระยะเวลานานสําหรับโทเค็นเพื่อการเข้าถึงเป็นระยะเวลาสั้นๆ Exchange นี้จะเกิดขึ้นเมื่อ Google ต้องการโทเค็นเพื่อการเข้าถึงใหม่เนื่องจากโทเค็นหมดอายุ

เลือกขั้นตอน OAuth 2.0

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

หมายเหตุ: ใช้ปุ่มต่อไปนี้เพื่อเลือกขั้นตอน OAuth 2.0 ที่ต้องการใช้ เนื้อหาของคู่มือนี้จะโหลดใหม่หากจําเป็น

ขั้นตอนแบบไม่เจาะจงปลายทาง รหัสการให้สิทธิ์

หลักเกณฑ์การออกแบบ

ส่วนนี้จะอธิบายข้อกําหนดในการออกแบบและคําแนะนําสําหรับหน้าจอผู้ใช้ซึ่งคุณโฮสต์สําหรับขั้นตอนการลิงก์ OAuth หลังจากที่แอปของ Google เรียกแล้ว #, แพลตฟอร์มจะแสดงการลงชื่อเข้าใช้หน้า Google และหน้าจอคํายินยอมในการลิงก์บัญชีแก่ผู้ใช้ ระบบจะเปลี่ยนเส้นทางผู้ใช้กลับไปยังแอปของ Google หลังจากให้ความยินยอมในการลิงก์บัญชี

รูปที่ 1 การลิงก์บัญชีผู้ใช้ลงชื่อเข้าใช้ Google และหน้าจอคํายินยอม

ข้อกำหนด

1. คุณต้องแจ้งว่าบัญชีของผู้ใช้จะลิงก์กับ Google ไม่ใช่ผลิตภัณฑ์บางอย่างของ Google เช่น Google Home หรือ Google Assistant

คำแนะนำ

เราขอแนะนําให้คุณทําสิ่งต่อไปนี้

1. แสดงนโยบายความเป็นส่วนตัวของ Google ใส่ลิงก์ไปยังนโยบายความเป็นส่วนตัวของ Google ในหน้าจอคํายินยอม

2. ข้อมูลที่จะแชร์ ใช้ภาษาที่ชัดเจนและกระชับเพื่อบอกผู้ใช้ว่า Google ต้องการข้อมูลใดและเพราะเหตุใด

3. คํากระตุ้นการตัดสินใจที่ชัดเจน ระบุคํากระตุ้นการตัดสินใจที่ชัดเจนบนหน้าจอคํายินยอม เช่น "ยอมรับและลิงก์" เนื่องจากผู้ใช้ต้องเข้าใจว่าข้อมูลใดที่ตนเองต้องแชร์กับ Google เพื่อลิงก์บัญชีของตน

4. ความสามารถในการยกเลิก ระบุวิธีให้ผู้ใช้ย้อนกลับหรือยกเลิกได้หากผู้ใช้เลือกที่จะไม่ลิงก์

5. ล้างกระบวนการลงชื่อเข้าใช้ ตรวจสอบว่าผู้ใช้มีวิธีลงชื่อเข้าใช้บัญชี Google ที่ชัดเจน เช่น ช่องสําหรับชื่อผู้ใช้และรหัสผ่าน หรือลงชื่อเข้าใช้ด้วย Google

6. ความสามารถในการยกเลิกการลิงก์ มีกลไกให้ผู้ใช้ยกเลิกการลิงก์ เช่น URL ไปยังการตั้งค่าบัญชีในแพลตฟอร์ม หรือใส่ลิงก์ไปยังบัญชี Google ก็ได้ ซึ่งผู้ใช้จะจัดการบัญชีที่ลิงก์ไว้ได้

7. ความสามารถในการเปลี่ยนบัญชีผู้ใช้ แนะนําวิธีการให้ผู้ใช้เปลี่ยนบัญชี ซึ่งจะเป็นประโยชน์อย่างยิ่งหากผู้ใช้มีแนวโน้มที่จะมีหลายบัญชี

   • หากผู้ใช้ต้องปิดหน้าจอคํายินยอมเพื่อสลับบัญชี ให้ส่งข้อผิดพลาดที่กู้คืนได้ไปยัง Google เพื่อให้ผู้ใช้ลงชื่อเข้าใช้บัญชีที่ต้องการได้ด้วยการลิงก์ OAuth และขั้นตอนโดยนัย

8. ใส่โลโก้ของคุณ แสดงโลโก้บริษัทในหน้าจอคํายินยอม ใช้หลักเกณฑ์รูปแบบในการวางโลโก้ หากต้องการแสดงโลโก้ Google&#39 ด้วย โปรดดูโลโก้และเครื่องหมายการค้า

รูปที่ 2 หลักเกณฑ์การออกแบบสําหรับผู้ใช้ในการลงชื่อเข้าใช้ Google และหน้าจอคํายินยอม

สร้างโปรเจ็กต์

หมายเหตุ: คุณนําโปรเจ็กต์ที่มีอยู่มาใช้ซ้ำได้และไม่จําเป็นต้องสร้างโปรเจ็กต์ใหม่เพื่อลิงก์บัญชีเป็นหลัก

วิธีสร้างโปรเจ็กต์เพื่อใช้การลิงก์บัญชี

1. Go to the Google API Console.
2. คลิก สร้างโครงการ
3. ป้อนชื่อหรือยอมรับคำแนะนำที่สร้างขึ้น
4. ยืนยันหรือแก้ไขฟิลด์ที่เหลือ
5. คลิก สร้าง

วิธีดูรหัสโครงการของคุณ:

1. Go to the Google API Console.
2. ค้นหาโครงการของคุณในตารางบนหน้า Landing Page รหัสโครงการจะปรากฏในคอลัมน์ ID

กำหนดค่าหน้าจอขอความยินยอม OAuth

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

1. เปิดหน้าหน้าจอขอความยินยอม OAuth ของคอนโซล Google APIs
2. เมื่อได้รับข้อความแจ้ง ให้เลือกโปรเจ็กต์ที่คุณเพิ่งสร้าง

3. ในหน้า "หน้าจอขอความยินยอม OAuth" ให้กรอกแบบฟอร์มแล้วคลิกปุ่ม "บันทึก"

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

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

   อีเมลสนับสนุน: เพื่อให้ผู้ใช้ติดต่อคุณเมื่อมีคำถามเกี่ยวกับความยินยอม

   ขอบเขตสำหรับ Google APIs: ขอบเขตช่วยให้แอปพลิเคชันของคุณเข้าถึงข้อมูล Google ส่วนตัวของผู้ใช้ สำหรับ Use Case การลิงก์บัญชี Google ขอบเขตเริ่มต้น (อีเมล, โปรไฟล์, openid) นั้นเพียงพอแล้ว คุณไม่จำเป็นต้องเพิ่มขอบเขตที่ละเอียดอ่อนใดๆ โดยทั่วไปแล้ว แนวทางปฏิบัติแนะนำคือให้ขอขอบเขตเพิ่มขึ้นเรื่อยๆ ในเวลาที่จำเป็นต้องเข้าถึง แทนที่จะขอตั้งแต่แรก ดูข้อมูลเพิ่มเติม

   โดเมนที่ได้รับอนุญาต: Google จะอนุญาตเฉพาะแอปพลิเคชันที่ตรวจสอบสิทธิ์โดยใช้ OAuth ให้ใช้โดเมนที่ได้รับอนุญาตเพื่อปกป้องคุณและผู้ใช้ ลิงก์ของแอปพลิเคชันต้องโฮสต์บนโดเมนที่ได้รับอนุญาต ดูข้อมูลเพิ่มเติม

   ลิงก์หน้าแรกของแอปพลิเคชัน: หน้าแรกของแอปพลิเคชัน ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   ลิงก์นโยบายความเป็นส่วนตัวของแอปพลิเคชัน: แสดงในหน้าจอขอความยินยอมการลิงก์บัญชี Google ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   ลิงก์ข้อกำหนดในการให้บริการของแอปพลิเคชัน (ไม่บังคับ): ต้องโฮสต์ในโดเมนที่ได้รับอนุญาต

   

   รูปที่ 1 หน้าจอแสดงความยินยอมในการเชื่อมโยงบัญชี Google สำหรับแอปพลิเคชันที่สมมติขึ้น เช่น Tunery

4. ตรวจสอบ "สถานะการยืนยัน" หากใบสมัครของคุณต้องมีการยืนยัน ให้คลิกปุ่ม "ส่งเพื่อขอรับการยืนยัน" เพื่อส่งใบสมัครเข้ารับการยืนยัน โปรดดูรายละเอียดที่ข้อกำหนดการยืนยัน OAuth

ใช้งานเซิร์ฟเวอร์ OAuth

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

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

เซสชันโฟลว์รหัสการให้สิทธิ์ OAuth 2.0 ที่เริ่มต้นโดย Google มีขั้นตอนดังต่อไปนี้:

1. Google เปิดจุดสิ้นสุดการให้สิทธิ์ของคุณในเบราว์เซอร์ของผู้ใช้ หากโฟลว์เริ่มต้นบนอุปกรณ์ที่ใช้เสียงเท่านั้นสำหรับการดำเนินการ Google จะโอนการดำเนินการไปยังโทรศัพท์
2. ผู้ใช้ลงชื่อเข้าใช้ หากยังไม่ได้ลงชื่อเข้าใช้ และให้สิทธิ์ Google ในการเข้าถึงข้อมูลของพวกเขาด้วย API ของคุณ หากพวกเขายังไม่ได้ให้สิทธิ์
3. บริการของคุณจะสร้างรหัสอนุมัติและส่งกลับไปยัง Google ในการดำเนินการดังกล่าว ให้เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้กลับไปที่ Google พร้อมแนบรหัสการให้สิทธิ์กับคำขอ
4. Google จะส่งรหัสอนุมัติเพื่อปลายทางแลกเปลี่ยนโทเค็นของคุณซึ่งจะตรวจสอบความถูกต้องของรหัสและผลตอบแทนการเข้าถึงโทเค็นและการฟื้นฟูโทเค็น โทเค็นการเข้าถึงเป็นโทเค็นอายุสั้นที่บริการของคุณยอมรับเป็นข้อมูลรับรองในการเข้าถึง API โทเค็นการรีเฟรชเป็นโทเค็นที่มีอายุการใช้งานยาวนานซึ่ง Google สามารถจัดเก็บและใช้เพื่อรับโทเค็นการเข้าถึงใหม่เมื่อหมดอายุ
5. หลังจากที่ผู้ใช้เสร็จสิ้นขั้นตอนการเชื่อมโยงบัญชีแล้ว ทุกๆ คำขอที่ตามมาที่ส่งจาก Google จะมีโทเค็นการเข้าถึง

จัดการคำขออนุญาต

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

พารามิเตอร์ปลายทางการอนุญาต
client_id	รหัสลูกค้าที่คุณกำหนดให้กับ Google
redirect_uri	URL ที่คุณส่งการตอบกลับคำขอนี้
state	มูลค่าการทำบัญชีที่ส่งกลับไปยัง Google ไม่เปลี่ยนแปลงใน URI การเปลี่ยนเส้นทาง
scope	ตัวเลือก: ชุดคั่นด้วยช่องว่างของสตริงขอบเขตที่ระบุข้อมูลที่ Google จะขออนุมัติ
response_type	ประเภทของค่าที่จะส่งคืนในการตอบกลับ สำหรับสิทธิ์ OAuth 2.0 ไหลรหัสประเภทการตอบสนองอยู่เสมอ code
user_locale	การตั้งค่าภาษาในบัญชี Google RFC5646 รูปแบบที่ใช้ในการ จำกัด เนื้อหาของคุณในภาษาที่ต้องการของผู้ใช้

ตัวอย่างเช่นถ้าปลายทางอนุมัติของคุณที่มีอยู่ใน https://myservice.example.com/auth คำขออาจมีลักษณะดังต่อไปนี้:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

เพื่อให้ปลายทางการให้สิทธิ์จัดการคำขอลงชื่อเข้าใช้ ให้ทำตามขั้นตอนต่อไปนี้:

1. ตรวจสอบว่า client_id ตรงกับรหัสลูกค้าที่คุณได้รับมอบหมายให้ Google และว่า redirect_uri ตรงกับ URL เปลี่ยนเส้นทางให้บริการโดย Google สำหรับการให้บริการของคุณ การตรวจสอบเหล่านี้มีความสำคัญในการป้องกันการให้สิทธิ์เข้าถึงแอปไคลเอ็นต์ที่ไม่ได้ตั้งใจหรือกำหนดค่าผิดพลาด หากคุณสนับสนุนหลายกระแส OAuth 2.0 นอกจากนี้ยังยืนยันว่า response_type เป็น code
2. ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่ หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ให้ทำตามขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้ของบริการ
3. สร้างรหัสการให้สิทธิ์สำหรับ Google เพื่อใช้ในการเข้าถึง API ของคุณ รหัสการให้สิทธิ์สามารถเป็นค่าสตริงใดๆ ก็ได้ แต่ต้องแสดงเฉพาะผู้ใช้ ลูกค้าที่ใช้โทเค็น และเวลาหมดอายุของรหัส และต้องไม่สามารถคาดเดาได้ โดยทั่วไป คุณจะออกรหัสการให้สิทธิ์ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 10 นาที
4. ยืนยันว่า URL ที่ระบุโดย redirect_uri พารามิเตอร์มีรูปแบบต่อไปนี้:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. เปลี่ยนเส้นทางเบราว์เซอร์ของผู้ใช้ไปยัง URL ที่ระบุโดย redirect_uri พารามิเตอร์ รวมรหัสการอนุมัติคุณเพียงแค่สร้างและเป็นต้นฉบับที่มูลค่ารัฐยังไม่แปรเมื่อคุณเปลี่ยนเส้นทางโดยการผนวก code และ state พารามิเตอร์ ต่อไปนี้เป็นตัวอย่างของ URL ที่เป็นผลลัพธ์ที่:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

จัดการคำขอแลกเปลี่ยนโทเค็น

จุดสิ้นสุดการแลกเปลี่ยนโทเค็นของบริการของคุณรับผิดชอบการแลกเปลี่ยนโทเค็นสองประเภท:

• แลกเปลี่ยนรหัสการอนุญาตสำหรับโทเค็นการเข้าถึงและรีเฟรชโทเค็น
• แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นการเข้าถึง

คำขอแลกเปลี่ยนโทเค็นรวมถึงพารามิเตอร์ต่อไปนี้:

พารามิเตอร์ปลายทางการแลกเปลี่ยนโทเค็น
client_id	สตริงที่ระบุแหล่งที่มาของคำขอเป็น Google ต้องลงทะเบียนสตริงนี้ภายในระบบของคุณเป็นตัวระบุเฉพาะของ Google
client_secret	สตริงลับที่คุณลงทะเบียนกับ Google สำหรับบริการของคุณ
grant_type	ประเภทของโทเค็นที่แลกเปลี่ยน ก็ทั้ง authorization_code หรือ refresh_token
code	เมื่อ grant_type=authorization_code พารามิเตอร์นี้คือรหัส Google ได้รับจากทั้งลงชื่อเข้าใช้หรือปลายทางแลกเปลี่ยนโทเค็น
redirect_uri	เมื่อ grant_type=authorization_code พารามิเตอร์นี้คือ URL ที่ใช้ในคำขออนุมัติเบื้องต้น
refresh_token	เมื่อ grant_type=refresh_token พารามิเตอร์นี้คือการฟื้นฟูโทเค็นของ Google ได้รับจากปลายทางแลกเปลี่ยนโทเค็นของคุณ

แลกเปลี่ยนรหัสการอนุญาตสำหรับโทเค็นการเข้าถึงและรีเฟรชโทเค็น

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

สำหรับการร้องขอเหล่านี้ค่าของ grant_type เป็น authorization_code และความคุ้มค่าของ code คือค่าของรหัสอนุมัติที่คุณได้รับก่อนหน้านี้ไปยัง Google ต่อไปนี้คือตัวอย่างคำขอแลกเปลี่ยนรหัสการอนุญาตสำหรับโทเค็นการเข้าถึงและโทเค็นการรีเฟรช:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

เพื่อแลกเปลี่ยนรหัสการอนุมัติสำหรับการเข้าถึงโทเค็นและการฟื้นฟูโทเค็นตอบสนองแลกเปลี่ยนปลายทางโทเค็นของคุณเพื่อ POST คำขอโดยการดำเนินการตามขั้นตอนต่อไปนี้:

1. ตรวจสอบว่า client_id ระบุแหล่งที่มาของการร้องขอในฐานะที่เป็นแหล่งกำเนิดที่ได้รับอนุญาตและที่ client_secret ตรงกับค่าที่คาดหวัง
2. ตรวจสอบว่ารหัสการให้สิทธิ์ถูกต้องและไม่หมดอายุ และรหัสไคลเอ็นต์ที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับรหัสการให้สิทธิ์
3. ยืนยันว่า URL ที่ระบุโดย redirect_uri พารามิเตอร์จะเหมือนกับค่าที่ใช้ในการขออนุมัติการเริ่มต้น
4. ถ้าคุณไม่สามารถตรวจสอบได้ทุกเกณฑ์ข้างต้นกลับ HTTP 400 ข้อผิดพลาดการร้องขอไม่ถูกกับ {"error": "invalid_grant"} ในขณะที่ร่างกาย
5. มิฉะนั้น ให้ใช้ ID ผู้ใช้จากรหัสการให้สิทธิ์เพื่อสร้างโทเค็นการรีเฟรชและโทเค็นการเข้าถึง โทเค็นเหล่านี้สามารถเป็นค่าสตริงใดๆ ก็ได้ แต่ต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่โทเค็นนั้นไม่ซ้ำกัน และต้องไม่สามารถคาดเดาได้ สำหรับโทเค็นการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย ซึ่งโดยทั่วไปคือหนึ่งชั่วโมงหลังจากที่คุณออกโทเค็น โทเค็นการรีเฟรชไม่มีวันหมดอายุ
6. กลับวัตถุ JSON ต่อไปนี้ในการตอบสนองของร่างกาย HTTPS ที่:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }
   

Google เก็บโทเค็นการเข้าถึงและโทเค็นการรีเฟรชสำหรับผู้ใช้ และบันทึกการหมดอายุของโทเค็นการเข้าถึง เมื่อโทเค็นการเข้าถึงหมดอายุ Google จะใช้โทเค็นการรีเฟรชเพื่อรับโทเค็นการเข้าถึงใหม่จากปลายทางการแลกเปลี่ยนโทเค็นของคุณ

แลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นการเข้าถึง

เมื่อโทเค็นการเข้าถึงหมดอายุ Google จะส่งคำขอไปยังปลายทางการแลกเปลี่ยนโทเค็นของคุณเพื่อแลกเปลี่ยนโทเค็นการรีเฟรชเป็นโทเค็นการเข้าถึงใหม่

สำหรับการร้องขอเหล่านี้ค่าของ grant_type เป็น refresh_token และความคุ้มค่าของ refresh_token คือค่าของการฟื้นฟูโทเค็นที่คุณได้รับก่อนหน้านี้ไปยัง Google ต่อไปนี้คือตัวอย่างคำขอแลกเปลี่ยนโทเค็นการรีเฟรชสำหรับโทเค็นการเข้าถึง:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

เพื่อแลกเปลี่ยนรีเฟรช token สำหรับโทเค็นการเข้าถึงการตอบสนองแลกเปลี่ยนปลายทางโทเค็นของคุณเพื่อ POST คำขอโดยการดำเนินการตามขั้นตอนต่อไปนี้:

1. ตรวจสอบว่า client_id ระบุแหล่งที่มาร้องขอ Google, และที่ client_secret ตรงกับค่าที่คาดหวัง
2. ตรวจสอบว่าโทเค็นการรีเฟรชถูกต้อง และรหัสไคลเอ็นต์ที่ระบุในคำขอตรงกับรหัสไคลเอ็นต์ที่เชื่อมโยงกับโทเค็นการรีเฟรช
3. ถ้าคุณไม่สามารถตรวจสอบได้ทุกเกณฑ์ข้างต้นกลับ HTTP 400 ข้อผิดพลาดการร้องขอไม่ถูกกับ {"error": "invalid_grant"} ในขณะที่ร่างกาย
4. มิฉะนั้น ให้ใช้ ID ผู้ใช้จากโทเค็นการรีเฟรชเพื่อสร้างโทเค็นการเข้าถึง โทเค็นเหล่านี้สามารถเป็นค่าสตริงใดๆ ก็ได้ แต่ต้องแสดงถึงผู้ใช้และไคลเอ็นต์ที่โทเค็นนั้นไม่ซ้ำกัน และต้องไม่สามารถคาดเดาได้ สำหรับโทเค็นการเข้าถึง ให้บันทึกเวลาหมดอายุของโทเค็นด้วย โดยทั่วไปแล้วหนึ่งชั่วโมงหลังจากที่คุณออกโทเค็น
5. ส่งคืนวัตถุ JSON ต่อไปนี้ในเนื้อหาของการตอบสนอง HTTPS:

   {
   "token_type": "Bearer",
   "access_token": " ACCESS_TOKEN ",
   "expires_in": SECONDS_TO_EXPIRATION
   }

หมายเหตุ: คุณสามารถเลือกที่จะกลับมาใหม่ refresh_token ในการตอบสนองของคุณ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเมื่อกลับมาใหม่ refresh_token เป็นที่ต้องการเห็น การทำงานกับโทเค็น

จัดการคำขอข้อมูลผู้ใช้

ปลายทาง UserInfo เป็นทรัพยากร OAuth 2.0 การป้องกันว่าการเรียกร้องผลตอบแทนที่เกี่ยวกับผู้ใช้ที่เชื่อมโยง การใช้งานและโฮสต์จุดสิ้นสุดข้อมูลผู้ใช้เป็นทางเลือก ยกเว้นกรณีการใช้งานต่อไปนี้:

• บัญชีที่เชื่อมโยงเข้าสู่ระบบ กับ Google หนึ่งแตะ
• สมัครสมาชิกฝืด บนแอนดรอยด์ทีวี

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

ส่วนหัวคำขอปลายทางข้อมูลผู้ใช้
Authorization header	โทเค็นการเข้าถึงของประเภท Bearer

ตัวอย่างเช่นถ้าปลายทางของคุณ UserInfo สามารถใช้ได้ที่ https://myservice.example.com/userinfo คำขออาจมีลักษณะดังต่อไปนี้:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

เพื่อให้ปลายทางข้อมูลผู้ใช้ของคุณจัดการกับคำขอ ให้ทำตามขั้นตอนต่อไปนี้:

1. แยกโทเค็นการเข้าถึงออกจากส่วนหัวการให้สิทธิ์และส่งคืนข้อมูลสำหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นการเข้าถึง
2. ถ้าโทเค็นการเข้าถึงไม่ถูกต้องกลับ HTTP 401 ข้อผิดพลาดไม่ได้รับอนุญาตในการใช้ WWW-Authenticate ตอบสนองส่วนหัว ด้านล่างนี้เป็นตัวอย่างของการตอบสนองต่อข้อผิดพลาด UserInfo นี้:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

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

3. ถ้าโทเค็นการเข้าถึงที่ถูกต้องผลตอบแทนและ HTTP 200 ตอบสนองกับวัตถุ JSON ต่อไปในร่างกายของการตอบสนอง https:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }
   

   หาก UserInfo ปลายทางผลตอบแทนการตอบสนองความสำเร็จ HTTP 200 ที่ดึงโทเค็นและสิทธิเรียกร้องได้รับการจดทะเบียนกับผู้ใช้ Google บัญชีผู้ใช้.

   userinfo การตอบสนองปลายทาง
   sub	ID เฉพาะที่ระบุผู้ใช้ในระบบของคุณ
   email	ที่อยู่อีเมลของผู้ใช้
   given_name	ตัวเลือก: ชื่อจริงของผู้ใช้
   family_name	ตัวเลือก: นามสกุลของผู้ใช้
   name	ตัวเลือก: ชื่อเต็มของผู้ใช้
   picture	รูปโปรไฟล์ของผู้ใช้ตัวเลือก:

การตรวจสอบการติดตั้งใช้งาน

คุณสามารถตรวจสอบการดำเนินงานของคุณโดยใช้ OAuth 2.0 สนามเด็กเล่น เครื่องมือ

ในเครื่องมือ ให้ทำตามขั้นตอนต่อไปนี้:

1. คลิกการกำหนดค่า เพื่อเปิดหน้าต่าง OAuth 2.0 การกำหนดค่า
2. ในด้านการไหล OAuth เลือกฝั่งไคลเอ็นต์
3. ในฟิลด์ OAuth ปลายทางเลือกที่กำหนดเอง
4. ระบุตำแหน่งข้อมูล OAuth 2.0 และรหัสไคลเอ็นต์ที่คุณกำหนดให้กับ Google ในช่องที่เกี่ยวข้อง
5. ในขั้นตอนที่ 1 ส่วนที่ไม่ได้เลือกขอบเขตใด ๆ ของ Google ให้ปล่อยฟิลด์นี้ว่างไว้หรือพิมพ์ขอบเขตที่ถูกต้องสำหรับเซิร์ฟเวอร์ของคุณ (หรือสตริงที่กำหนดเองหากคุณไม่ได้ใช้ขอบเขต OAuth) เมื่อคุณทำเสร็จแล้วคลิกอนุญาต APIs
6. ในขั้นตอนที่ 2 และขั้นตอนที่ 3 ส่วนไปไหลผ่าน OAuth 2.0 และตรวจสอบว่าแต่ละขั้นตอนการทำงานตามที่ตั้งใจไว้

คุณสามารถตรวจสอบการดำเนินงานของคุณโดยใช้ บัญชี Google เชื่อมโยงการสาธิต เครื่องมือ

ในเครื่องมือ ให้ทำตามขั้นตอนต่อไปนี้:

1. คลิกเข้าสู่ระบบด้วยปุ่ม Google
2. เลือกบัญชีที่คุณต้องการเชื่อมโยง
3. ป้อนรหัสบริการ
4. เลือกป้อนขอบเขตอย่างน้อยหนึ่งขอบเขตที่คุณจะร้องขอการเข้าถึง
5. คลิกเริ่มการสาธิต
6. เมื่อได้รับแจ้ง ให้ยืนยันว่าคุณอาจยินยอมและปฏิเสธคำขอเชื่อมโยง
7. ยืนยันว่าคุณถูกเปลี่ยนเส้นทางไปยังแพลตฟอร์มของคุณ