การลิงก์บัญชี Google กับ OAuth (โฟลว์โดยนัย - เก็บถาวร)

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

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

การลิงก์บัญชี Google: ขั้นตอน OAuth โดยนัย

แผนภาพลำดับต่อไปนี้แสดงรายละเอียดการโต้ตอบระหว่างผู้ใช้ Google และปลายทางของบริการ

ผู้ใช้ แอป Google / เบราว์เซอร์ ปลายทาง การตรวจสอบสิทธิ์ 1. ผู้ใช้เริ่มการลิงก์ 2. เปลี่ยนเส้นทางไปยังปลายทางการให้สิทธิ์ (GET) client_id, redirect_uri, state, scope 3. แสดงหน้าจอลงชื่อเข้าใช้และความยินยอม 4. ผู้ใช้ตรวจสอบสิทธิ์และให้ความยินยอม 5. เปลี่ยนเส้นทางกลับไปที่ Google พร้อมโทเค็น (GET) access_token, state 6. โทเค็นผู้ใช้ร้านค้า 7. เข้าถึงแหล่งข้อมูลของผู้ใช้
รูปที่ 1 ลำดับเหตุการณ์ในขั้นตอนการให้สิทธิ์โดยนัย OAuth 2.0 สำหรับการลิงก์บัญชี Google

บทบาทและความรับผิดชอบ

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

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

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

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

สูตรการติดตั้งใช้งาน

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

ขั้นตอนที่ 1: จัดการคำขอการให้สิทธิ์

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

หากต้องการจัดการคำขอ ให้ดำเนินการต่อไปนี้

  1. ตรวจสอบคำขอ

    • ยืนยันว่า client_id ตรงกับรหัสไคลเอ็นต์ที่กำหนดให้กับ Google
    • ยืนยันว่า redirect_uri ตรงกับ URL การเปลี่ยนเส้นทางของ Google ที่คาดไว้ ดังนี้ none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
    • ตรวจสอบว่า response_type เป็น token

  2. ตรวจสอบสิทธิ์ผู้ใช้:

    • ตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้บริการของคุณหรือไม่
    • หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ ให้แจ้งให้ผู้ใช้ดำเนินการขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อสมัครใช้ให้เสร็จสมบูรณ์

  3. สร้างโทเค็นเพื่อการเข้าถึง:

    • สร้างโทเค็นเพื่อการเข้าถึงที่ไม่ซ้ำกันและคาดเดาไม่ได้ซึ่งเชื่อมโยงกับผู้ใช้และไคลเอ็นต์

  4. เปลี่ยนเส้นทางกลับไปที่ Google

    • เปลี่ยนเส้นทางเบราว์เซอร์ไปยัง URL ที่ระบุใน redirect_uri
    • ผนวกพารามิเตอร์ต่อไปนี้ในส่วนย่อย URL (แฮช)
      • access_token: โทเค็นเพื่อการเข้าถึงที่คุณสร้างขึ้น
      • token_type: ต้องเป็น bearer
      • state: ค่าสถานะที่ได้รับจาก Google โดยไม่มีการแก้ไข
จัดการคำขอ Userinfo

ปลายทาง userinfo เป็นทรัพยากรที่มีการป้องกันด้วย OAuth 2.0 ซึ่งส่งกลับการอ้างสิทธิ์เกี่ยวกับผู้ใช้ที่ลิงก์ การติดตั้งใช้งานและการโฮสต์ปลายทาง userinfo เป็นตัวเลือกที่ไม่บังคับ ยกเว้นกรณีการใช้งานต่อไปนี้

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

ส่วนหัวของคำขอปลายทางของ userinfo
Authorization header โทเค็นเพื่อการเข้าถึงของประเภท Bearer

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

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

หากต้องการให้ปลายทาง userinfo จัดการคำขอ ให้ทำตามขั้นตอนต่อไปนี้

  1. แยกโทเค็นเพื่อการเข้าถึงจากส่วนหัวการให้สิทธิ์ แล้วแสดงผลข้อมูลสำหรับผู้ใช้ที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง
  2. หากโทเค็นเพื่อการเข้าถึงไม่ถูกต้อง ให้แสดงข้อผิดพลาด HTTP 401 Unauthorized ด้วยการใช้ส่วนหัวการตอบกลับ WWW-Authenticate ตัวอย่างการตอบกลับข้อผิดพลาดเกี่ยวกับ Userinfo มีดังนี้ 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    หากข้อผิดพลาด 401 Unauthorized หรือการตอบกลับที่ผิดพลาดอื่นๆ ที่ไม่สำเร็จในระหว่างกระบวนการลิงก์ ข้อผิดพลาดดังกล่าวจะกู้คืนไม่ได้ ระบบจะทิ้งโทเค็นที่ดึงมาและผู้ใช้จะต้องเริ่มกระบวนการลิงก์อีกครั้ง

  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 รหัสที่ไม่ซ้ำกันที่ระบุผู้ใช้ในระบบ
    email อีเมลของผู้ใช้
    given_name ไม่บังคับ: ชื่อของผู้ใช้
    family_name ไม่บังคับ: นามสกุลของผู้ใช้
    name ไม่บังคับ: ชื่อเต็มของผู้ใช้
    picture ไม่บังคับ: รูปโปรไฟล์ของผู้ใช้