Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติให้กับชุมชนคนผิวดำ ดูวิธีการ

OpenID Connect

ปลายทาง OpenID Connect ของ Google ได้รับการรับรอง OpenID

OAuth 2.0 API ของ Google สามารถใช้ได้ทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์ เอกสารนี้อธิบายถึงการใช้งาน OAuth 2.0 สำหรับการตรวจสอบสิทธิ์ซึ่งเป็นไปตามข้อกำหนด OpenID Connect และ ได้รับการรับรอง OpenID เอกสารที่พบใน การใช้ OAuth 2.0 เพื่อเข้าถึง Google API ก็มีผลกับบริการนี้เช่นกัน หากคุณต้องการสำรวจโปรโตคอลนี้ในเชิงโต้ตอบเราขอแนะนำ Google OAuth 2.0 Playground หากต้องการความช่วยเหลือเกี่ยวกับ Stack Overflow ให้แท็กคำถามของคุณด้วย "google-oauth"

การตั้งค่า OAuth 2.0

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

รับข้อมูลรับรอง OAuth 2.0

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

ในการดูรหัสลูกค้าและข้อมูลลับของลูกค้าสำหรับข้อมูลรับรอง OAuth 2.0 ที่กำหนดให้คลิกข้อความต่อไปนี้: เลือกข้อมูลรับรอง ในหน้าต่างที่เปิดขึ้นให้เลือกโครงการและข้อมูลรับรองที่คุณต้องการจากนั้นคลิก ดู

หรือดูรหัสลูกค้าและข้อมูลลับลูกค้าของคุณจาก หน้าข้อมูลรับรอง ใน API Console :

  1. Go to the Credentials page.
  2. คลิกที่ชื่อหนังสือรับรองของคุณหรือไอคอนดินสอ ( ) รหัสลูกค้าและความลับของคุณอยู่ที่ด้านบนของหน้า

ตั้งค่า URI การเปลี่ยนเส้นทาง

URI การเปลี่ยนเส้นทางที่คุณตั้งไว้ใน API Console จะกำหนดตำแหน่งที่ Google จะส่งคำตอบไปยัง คำขอการตรวจสอบสิทธิ์ ของคุณ

ในการสร้างดูหรือแก้ไข URIs การเปลี่ยนเส้นทางสำหรับข้อมูลรับรอง OAuth 2.0 ที่ระบุให้ทำดังต่อไปนี้:

  1. Go to the Credentials page.
  2. ในส่วน รหัสลูกค้า OAuth 2.0 ของหน้าคลิกข้อมูลรับรอง
  3. ดูหรือแก้ไข URIs การเปลี่ยนเส้นทาง

หากไม่มีส่วน รหัสลูกค้า OAuth 2.0 ในหน้าหนังสือรับรองแสดงว่าโครงการของคุณไม่มีข้อมูลรับรอง OAuth หากต้องการสร้างหนึ่งคลิก สร้างข้อมูลรับรอง

ปรับแต่งหน้าจอคำยินยอมของผู้ใช้

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

หน้าจอคำยินยอมของผู้ใช้ยังแสดงข้อมูลการสร้างแบรนด์เช่นชื่อผลิตภัณฑ์โลโก้และ URL ของหน้าแรก คุณควบคุมข้อมูลการสร้างแบรนด์ใน API Console

วิธีเปิดใช้งานหน้าจอการยินยอมของโครงการ:

  1. เปิด Consent Screen page ใน Google API Console
  2. If prompted, select a project, or create a new one.
  3. กรอกแบบฟอร์มและคลิก บันทึก

กล่องโต้ตอบคำยินยอมต่อไปนี้จะแสดงสิ่งที่ผู้ใช้จะเห็นเมื่อมีการรวมกันของขอบเขต OAuth 2.0 และ Google ไดรฟ์ในคำขอ (กล่องโต้ตอบทั่วไปนี้สร้างขึ้นโดยใช้ Google OAuth 2.0 Playground ดังนั้นจึงไม่รวมข้อมูลการสร้างแบรนด์ที่จะตั้งค่าใน API Console)

ภาพหน้าจอแสดงความยินยอม

การเข้าถึงบริการ

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

หากคุณเลือกที่จะไม่ใช้ไลบรารีให้ทำตามคำแนะนำในส่วนที่เหลือของเอกสารนี้ซึ่งอธิบายขั้นตอนการร้องขอ HTTP ที่อยู่ภายใต้ไลบรารีที่มีอยู่

รับรองความถูกต้องของผู้ใช้

การพิสูจน์ตัวตนผู้ใช้เกี่ยวข้องกับการขอรับ ID โทเค็นและการตรวจสอบความถูกต้อง ID โทเค็น เป็นคุณสมบัติมาตรฐานของ OpenID Connect ที่ ออกแบบมาเพื่อใช้ในการแบ่งปันการยืนยันตัวตนบนอินเทอร์เน็ต

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

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

การไหลของเซิร์ฟเวอร์

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

  1. สร้างโทเค็นสถานะต่อต้านการปลอมแปลง
  2. ส่งคำขอการตรวจสอบสิทธิ์ไปยัง Google
  3. ยืนยันโทเค็นสถานะต่อต้านการปลอมแปลง
  4. แลกเปลี่ยน code สำหรับโทเค็นการเข้าถึงและโทเค็น ID
  5. รับข้อมูลผู้ใช้จากโทเค็น ID
  6. รับรองความถูกต้องของผู้ใช้

1. สร้างโทเค็นสถานะต่อต้านการปลอมแปลง

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

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

รหัสต่อไปนี้แสดงให้เห็นถึงการสร้างโทเค็นเซสชันที่ไม่ซ้ำกัน

PHP

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ PHP เพื่อใช้ตัวอย่างนี้

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

Java

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ Java เพื่อใช้ตัวอย่างนี้

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

Python

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ Python เพื่อใช้ตัวอย่างนี้

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. ส่งคำขอการตรวจสอบสิทธิ์ไปยัง Google

ขั้นตอนต่อไปคือการสร้างคำขอ HTTPS GET ด้วยพารามิเตอร์ URI ที่เหมาะสม สังเกตการใช้ HTTPS แทน HTTP ในทุกขั้นตอนของกระบวนการนี้ การเชื่อมต่อ HTTP ถูกปฏิเสธ คุณควรดึงข้อมูล URI พื้นฐานจาก เอกสาร Discovery โดยใช้ค่าข้อมูลเมตาของ authorization_endpoint การสนทนาต่อไปนี้ถือว่า URI พื้นฐานคือ https://accounts.google.com/o/oauth2/v2/auth

สำหรับคำขอพื้นฐานระบุพารามิเตอร์ต่อไปนี้:

  • client_id ซึ่งคุณได้รับจาก API Console Credentials page
  • response_type ซึ่งในคำขอโฟลว์รหัสการอนุญาตพื้นฐานควรเป็น code (อ่านเพิ่มเติมได้ที่ response_type )
  • scope ซึ่งในคำขอพื้นฐานควรเป็น openid email เปิด (อ่านเพิ่มเติมที่ scope )
  • redirect_uri ควรเป็นปลายทาง HTTP บนเซิร์ฟเวอร์ของคุณที่จะได้รับการตอบกลับจาก Google ค่าต้องตรงกับ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตรายการหนึ่งสำหรับไคลเอ็นต์ OAuth 2.0 ซึ่งคุณกำหนดค่าไว้ใน API Console Credentials page หากค่านี้ไม่ตรงกับ URI ที่ได้รับอนุญาตคำขอจะล้มเหลวโดยมีข้อผิดพลาด redirect_uri_mismatch
  • state ควรรวมค่าของโทเค็นเซสชันที่ไม่ซ้ำกันเพื่อต่อต้านการปลอมแปลงรวมถึงข้อมูลอื่น ๆ ที่จำเป็นในการกู้คืนบริบทเมื่อผู้ใช้กลับไปที่แอปพลิเคชันของคุณเช่น URL เริ่มต้น (อ่านเพิ่มเติมที่ state )
  • nonce คือค่าสุ่มที่สร้างขึ้นโดยแอปของคุณซึ่งเปิดใช้งานการป้องกันการเล่นซ้ำเมื่อมีอยู่
  • login_hint อาจเป็นที่อยู่อีเมลของผู้ใช้หรือสตริง sub ซึ่งเทียบเท่ากับ Google ID ของผู้ใช้ หากคุณไม่ได้ระบุ login_hint และผู้ใช้กำลังเข้าสู่ระบบอยู่หน้าจอคำยินยอมจะมีคำขออนุมัติเพื่อเผยแพร่ที่อยู่อีเมลของผู้ใช้ไปยังแอปของคุณ (อ่านเพิ่มเติมได้ที่ login_hint )
  • ใช้พารามิเตอร์ hd เพื่อเพิ่มประสิทธิภาพขั้นตอนการเชื่อมต่อ OpenID สำหรับผู้ใช้โดเมน G Suite โดยเฉพาะ (อ่านเพิ่มเติมได้ที่ hd .)

นี่คือตัวอย่าง URI การพิสูจน์ตัวตน OpenID Connect ที่สมบูรณ์พร้อมตัวแบ่งบรรทัดและช่องว่างเพื่อให้อ่านง่าย:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

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

3. ยืนยันโทเค็นสถานะต่อต้านการปลอมแปลง

การตอบกลับจะถูกส่งไปยัง redirect_uri ที่คุณระบุไว้ใน คำขอ การตอบกลับทั้งหมดจะถูกส่งกลับในสตริงการสืบค้นดังที่แสดงด้านล่าง:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

บนเซิร์ฟเวอร์คุณต้องยืนยันว่า state ได้รับจาก Google ตรงกับโทเค็นเซสชันที่คุณสร้างใน ขั้นตอนที่ 1 การตรวจสอบแบบไปกลับนี้ช่วยให้มั่นใจได้ว่าผู้ใช้ไม่ใช่สคริปต์ที่เป็นอันตรายกำลังส่งคำขอ

รหัสต่อไปนี้แสดงให้เห็นถึงการยืนยันโทเค็นเซสชันที่คุณสร้างในขั้นตอนที่ 1:

PHP

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ PHP เพื่อใช้ตัวอย่างนี้

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

Java

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ Java เพื่อใช้ตัวอย่างนี้

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

Python

คุณต้องดาวน์โหลด ไลบรารีไคลเอ็นต์ Google APIs สำหรับ Python เพื่อใช้ตัวอย่างนี้

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. แลกเปลี่ยน code สำหรับโทเค็นการเข้าถึงและโทเค็น ID

การตอบกลับประกอบด้วยพารามิเตอร์ code การอนุญาตแบบครั้งเดียวที่เซิร์ฟเวอร์ของคุณสามารถแลกเปลี่ยนเป็นโทเค็นการเข้าถึงและโทเค็น ID เซิร์ฟเวอร์ของคุณทำการแลกเปลี่ยนนี้โดยส่งคำขอ HTTPS POST คำขอ POST จะถูกส่งไปยังปลายทางโทเค็นซึ่งคุณควรดึงข้อมูลจาก เอกสาร Discovery โดยใช้ค่าข้อมูลเมตา token_endpoint การสนทนาต่อไปนี้ถือว่าจุดสิ้นสุดคือ https://oauth2.googleapis.com/token คำขอต้องมีพารามิเตอร์ต่อไปนี้ในเนื้อหา POST :

ฟิลด์
code รหัสการอนุญาตที่ส่งคืนจาก คำขอเริ่มต้น
client_id รหัสไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials page ตามที่อธิบายไว้ใน Obtain OAuth 2.0 credentials
client_secret ความลับของไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials page ตามที่อธิบายไว้ใน ขอรับข้อมูลรับรอง OAuth 2.0
redirect_uri URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตสำหรับ client_id ระบุที่ระบุใน API Console Credentials page ตามที่อธิบายไว้ใน Set a redirect URI
grant_type ช่องนี้ต้องมีค่า authorization_code ตามที่กำหนดไว้ในข้อกำหนด OAuth 2.0

คำขอจริงอาจมีลักษณะดังตัวอย่างต่อไปนี้:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

การตอบสนองต่อคำขอนี้สำเร็จประกอบด้วยฟิลด์ต่อไปนี้ในอาร์เรย์ JSON:

ฟิลด์
access_token โทเค็นที่สามารถส่งไปยัง Google API
expires_in อายุการใช้งานที่เหลือของโทเค็นการเข้าถึงเป็นวินาที
id_token JWT ที่มีข้อมูลประจำตัวเกี่ยวกับผู้ใช้ที่ Google ลงนามแบบดิจิทัล
scope ขอบเขตการเข้าถึงที่มอบให้โดย access_token แสดงเป็นรายการของสตริงที่คั่นด้วยช่องว่างและคำนึง access_token ตัวพิมพ์
token_type ระบุชนิดของโทเค็นที่ส่งคืน ในขณะนี้ฟิลด์นี้จะมีค่า Bearer อยู่เสมอ
refresh_token (ไม่จำเป็น)

ฟิลด์นี้จะปรากฏต่อเมื่อพารามิเตอร์ access_type ถูกตั้งค่าเป็น offline ใน คำขอการพิสูจน์ ตัว ตน สำหรับรายละเอียดโปรดดูที่การ รีเฟรชโทเค็น

5. รับข้อมูลผู้ใช้จากโทเค็น ID

ID Token คือ JWT (JSON Web Token) นั่นคือออบเจ็กต์ JSON ที่เข้ารหัส Base64 ที่เซ็นชื่อแบบเข้ารหัส โดยปกติแล้วสิ่งสำคัญคือคุณ ต้องตรวจสอบความถูกต้องของโทเค็น ID ก่อนที่จะใช้งาน แต่เนื่องจากคุณกำลังสื่อสารโดยตรงกับ Google ผ่านช่องทาง HTTPS ที่ไม่มีตัวกลางและการใช้ความลับของไคลเอนต์ในการตรวจสอบตัวเองกับ Google คุณจึงมั่นใจได้ว่าโทเค็นที่คุณ รับจริงๆมาจาก Google และถูกต้อง หากเซิร์ฟเวอร์ของคุณส่งรหัสโทเค็นไปยังส่วนประกอบอื่น ๆ ของแอปสิ่งสำคัญอย่างยิ่งที่ส่วนประกอบอื่น ๆ จะ ต้องตรวจสอบโทเค็น ก่อนใช้งาน

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

เพย์โหลดของโทเค็น ID

โทเค็น ID คือออบเจ็กต์ JSON ที่มีชุดคู่ชื่อ / ค่า นี่คือตัวอย่างที่จัดรูปแบบเพื่อให้อ่านง่าย:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Google ID Token อาจมีฟิลด์ต่อไปนี้ (เรียกว่าการ อ้างสิทธิ์ ):

อ้างสิทธิ์ ให้ คำอธิบาย
aud เสมอ ผู้ชมที่โทเค็นรหัสนี้มีไว้สำหรับ ต้องเป็นหนึ่งในรหัสไคลเอ็นต์ OAuth 2.0 ของแอปพลิเคชันของคุณ
exp เสมอ เวลาหมดอายุในหรือหลังจากนั้นต้องไม่ยอมรับโทเค็น ID แสดงในเวลา Unix (วินาทีจำนวนเต็ม)
iat เสมอ เวลาที่ออกโทเค็น ID แสดงในเวลา Unix (วินาทีจำนวนเต็ม)
iss เสมอ ตัวระบุผู้ออกสำหรับผู้ออกการตอบกลับ https://accounts.google.com หรือ accounts.google.com เสมอสำหรับโทเค็น Google ID
sub เสมอ ตัวระบุสำหรับผู้ใช้ไม่ซ้ำกันในบัญชี Google ทั้งหมดและไม่เคยใช้ซ้ำ บัญชี Google สามารถมีที่อยู่อีเมลได้หลายรายการในเวลาที่ต่างกัน แต่ค่า sub จะไม่มีการเปลี่ยนแปลง ใช้ sub ภายในแอปพลิเคชันของคุณเป็นคีย์ตัวระบุเฉพาะสำหรับผู้ใช้ ความยาวสูงสุด 255 อักขระ ASCII ที่คำนึงถึงขนาดตัวพิมพ์
at_hash แฮชโทเค็นการเข้าถึง ให้การตรวจสอบความถูกต้องว่าโทเค็นการเข้าถึงเชื่อมโยงกับโทเค็นข้อมูลประจำตัว หากรหัสโทเค็นออกโดยมีค่า access_token ในขั้นตอนของเซิร์ฟเวอร์การอ้างสิทธิ์นี้จะรวมอยู่ด้วยเสมอ การอ้างสิทธิ์นี้สามารถใช้เป็นกลไกทางเลือกเพื่อป้องกันการโจมตีด้วยการปลอมแปลงคำขอข้ามไซต์ แต่ถ้าคุณทำตาม ขั้นตอนที่ 1 และ ขั้นตอนที่ 3 ก็ไม่จำเป็นต้องตรวจสอบโทเค็นการเข้าถึง
azp client_id ของผู้นำเสนอที่ได้รับอนุญาต การอ้างสิทธิ์นี้จำเป็นเฉพาะเมื่อฝ่ายที่ร้องขอโทเค็นรหัสไม่เหมือนกับผู้ชมของโทเค็นรหัส อาจเป็นกรณีนี้ที่ Google สำหรับแอปไฮบริดที่เว็บแอปพลิเคชันและแอป Android มี OAuth 2.0 client_id แตกต่างกัน แต่แชร์โครงการ Google APIs เดียวกัน
email ที่อยู่อีเมลของผู้ใช้ ค่านี้อาจไม่ซ้ำกับผู้ใช้รายนี้และไม่เหมาะสำหรับใช้เป็นคีย์หลัก ให้เฉพาะในกรณีที่ขอบเขตของคุณมีค่าขอบเขต email
email_verified เป็นจริงหากที่อยู่อีเมลของผู้ใช้ได้รับการยืนยัน มิฉะนั้นเท็จ
family_name นามสกุลหรือนามสกุลของผู้ใช้ อาจมีให้เมื่อมีการอ้าง name
given_name ชื่อที่กำหนดของผู้ใช้หรือชื่อจริง อาจมีให้เมื่อมีการอ้าง name
hd โดเมน G Suite ที่โฮสต์ของผู้ใช้ ให้เฉพาะในกรณีที่ผู้ใช้อยู่ในโดเมนที่โฮสต์
locale โลแคลของผู้ใช้แสดงโดยแท็กภาษา BCP 47 อาจมีให้เมื่อมีการอ้าง name
name ชื่อเต็มของผู้ใช้ในรูปแบบที่แสดงได้ อาจจัดให้เมื่อ:
  • ขอบเขตคำขอรวมสตริง "profile"
  • โทเค็น ID จะถูกส่งคืนจากการรีเฟรชโทเค็น

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

nonce ค่าของ nonce ที่แอปของคุณให้มาในคำขอการตรวจสอบสิทธิ์ คุณควรบังคับใช้การป้องกันจากการโจมตีซ้ำโดยตรวจสอบให้แน่ใจว่ามีการนำเสนอเพียงครั้งเดียว
picture URL ของรูปโปรไฟล์ของผู้ใช้ อาจจัดให้เมื่อ:
  • ขอบเขตคำขอรวมสตริง "profile"
  • โทเค็น ID จะถูกส่งคืนจากการรีเฟรชโทเค็น

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

profile URL ของหน้าโปรไฟล์ของผู้ใช้ อาจจัดให้เมื่อ:
  • ขอบเขตคำขอรวมสตริง "profile"
  • โทเค็น ID จะถูกส่งคืนจากการรีเฟรชโทเค็น

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

6. รับรองความถูกต้องของผู้ใช้

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

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

หัวข้อขั้นสูง

ส่วนต่อไปนี้อธิบายรายละเอียดเพิ่มเติมเกี่ยวกับ Google OAuth 2.0 API ข้อมูลนี้มีไว้สำหรับนักพัฒนาที่มีข้อกำหนดขั้นสูงเกี่ยวกับการพิสูจน์ตัวตนและการอนุญาต

เข้าถึง Google API อื่น ๆ

ข้อดีอย่างหนึ่งของการใช้ OAuth 2.0 สำหรับการตรวจสอบสิทธิ์คือแอปพลิเคชันของคุณสามารถได้รับอนุญาตให้ใช้ Google API อื่น ๆ ในนามของผู้ใช้ (เช่น YouTube, Google ไดรฟ์, ปฏิทินหรือที่อยู่ติดต่อ) ในเวลาเดียวกับที่คุณตรวจสอบสิทธิ์ผู้ใช้ ในการดำเนินการนี้ให้รวมขอบเขตอื่น ๆ ที่คุณต้องการใน คำขอการตรวจสอบสิทธิ์ ที่คุณส่งไปยัง Google ตัวอย่างเช่นหากต้องการเพิ่มกลุ่มอายุของผู้ใช้ในคำขอการตรวจสอบสิทธิ์ของคุณให้ส่งผ่านพารามิเตอร์ขอบเขตของ openid email https://www.googleapis.com/auth/profile.agerange.read ผู้ใช้จะได้รับแจ้งอย่างเหมาะสมบน หน้าจอคำยินยอม โทเค็นการเข้าถึงที่คุณได้รับกลับมาจาก Google ช่วยให้คุณสามารถเข้าถึง API ทั้งหมดที่เกี่ยวข้องกับขอบเขตการเข้าถึงที่คุณร้องขอและได้รับอนุญาต

รีเฟรชโทเค็น

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

ข้อควรพิจารณา:

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

สำหรับข้อมูลเพิ่มเติมโปรดดูการ รีเฟรชโทเค็นการเข้าถึง (การเข้าถึงแบบออฟไลน์)

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ prompt พารามิเตอร์เห็น prompt ใน พารามิเตอร์รับรองความถูกต้อง URI ตาราง

พารามิเตอร์ URI การพิสูจน์ตัวตน

ตารางต่อไปนี้ให้คำอธิบายที่สมบูรณ์มากขึ้นเกี่ยวกับพารามิเตอร์ที่ยอมรับโดย API การตรวจสอบสิทธิ์ OAuth 2.0 ของ Google

พารามิเตอร์ จำเป็น คำอธิบาย
client_id (จำเป็น) สตริงรหัสไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials page ตามที่อธิบายไว้ใน Obtain OAuth 2.0 credentials
nonce (จำเป็น) ค่าสุ่มที่สร้างขึ้นโดยแอปของคุณซึ่งเปิดใช้งานการป้องกันการเล่นซ้ำ
response_type (จำเป็น) หากค่าเป็น code ให้เรียกใช้ โฟลว์รหัสการอนุญาตพื้นฐาน โดยต้องมีการ POST ไปยังปลายทางโทเค็นเพื่อรับโทเค็น ถ้าค่าเป็น token id_token หรือ id_token token ให้เปิดใช้งาน Implicit flow โดยต้องใช้ JavaScript ที่เปลี่ยนเส้นทาง URI เพื่อดึงโทเค็นจาก URI #fragment identifier
redirect_uri (จำเป็น) กำหนดว่าจะส่งการตอบกลับไปที่ใด ค่าของพารามิเตอร์นี้ต้องตรงกับค่าการเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าหนึ่งที่คุณตั้งไว้ใน API Console Credentials page (รวมถึงแบบแผน HTTP หรือ HTTPS กรณีและการต่อท้าย "/" หากมี)
scope (จำเป็น)

พารามิเตอร์ขอบเขตต้องเริ่มต้นด้วยค่า openid จากนั้นรวมค่า profile ค่า email หรือทั้งสองอย่าง

หากมีค่าขอบเขต profile โทเค็น ID อาจ (แต่ไม่รับประกันว่าจะ) รวมการอ้างสิทธิ์ profile เริ่มต้นของผู้ใช้

หากค่าขอบเขต email มีอยู่โทเค็น ID จะรวม email และ email email_verified อ้างสิทธิ์

นอกเหนือจากขอบเขตเฉพาะ OpenID แล้วอาร์กิวเมนต์ขอบเขตของคุณยังสามารถรวมค่าขอบเขตอื่น ๆ ค่าขอบเขตทั้งหมดต้องคั่นด้วยช่องว่าง ตัวอย่างเช่นหากคุณต้องการเข้าถึง Google ไดรฟ์ของผู้ใช้แต่ละไฟล์พารามิเตอร์ขอบเขตของคุณอาจเป็น openid profile email https://www.googleapis.com/auth/drive.file

สำหรับข้อมูลเกี่ยวกับขอบเขตที่มีให้ดูขอบเขต OAuth 2.0 สำหรับ Google API หรือเอกสารสำหรับ Google API ที่คุณต้องการใช้

state (ไม่บังคับ แต่แนะนำอย่างยิ่ง)

สตริงทึบที่สะดุดรอบในโปรโตคอล กล่าวคือจะส่งคืนเป็นพารามิเตอร์ URI ในโฟลว์พื้นฐานและใน URI #fragment identifier ในโฟลว์โดยนัย

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

access_type (ไม่จำเป็น) ค่าที่อนุญาตคือ offline และ online เอฟเฟกต์ถูกบันทึกไว้ใน การเข้าถึงแบบออฟไลน์ หากมีการร้องขอโทเค็นการเข้าถึงไคลเอนต์จะไม่ได้รับโทเค็นการรีเฟรชเว้นแต่จะระบุค่า offline ไว้
display (ไม่จำเป็น) ค่าสตริง ASCII สำหรับระบุว่าเซิร์ฟเวอร์การอนุญาตแสดงหน้าส่วนติดต่อผู้ใช้การพิสูจน์ตัวตนและการยินยอมอย่างไร ค่าต่อไปนี้ถูกระบุและยอมรับโดยเซิร์ฟเวอร์ของ Google แต่ไม่มีผลใด ๆ ต่อพฤติกรรมของมัน: page , popup , touch และ wap
hd (ไม่จำเป็น)

พารามิเตอร์ hd (โดเมนที่โฮสต์) ช่วยเพิ่มความคล่องตัวในกระบวนการเข้าสู่ระบบสำหรับบัญชีที่โฮสต์ของ G Suite เมื่อรวมโดเมนของผู้ใช้ G Suite (เช่น mycollege.edu ) คุณสามารถระบุได้ว่า UI การเลือกบัญชีควรได้รับการปรับให้เหมาะสมกับบัญชีในโดเมนนั้น หากต้องการเพิ่มประสิทธิภาพสำหรับบัญชี G Suite โดยทั่วไปแทนที่จะใช้เพียงโดเมนเดียวให้ตั้งค่าเครื่องหมายดอกจัน ( * ): hd=*

อย่าพึ่งพาการเพิ่มประสิทธิภาพ UI นี้เพื่อควบคุมว่าใครสามารถเข้าถึงแอปของคุณได้เนื่องจากคำขอฝั่งไคลเอ็นต์สามารถแก้ไขได้ อย่าลืม ตรวจสอบความถูกต้อง ว่า โทเค็น ID ที่ส่งคืน มีค่าการอ้างสิทธิ์ hd ที่ตรงกับสิ่งที่คุณคาดหวัง (เช่น mycolledge.edu ) ซึ่งแตกต่างจากพารามิเตอร์คำขอรหัสโทเค็น hd เรียกร้องอยู่ภายในการรักษาความปลอดภัย token จาก Google เพื่อให้ค่าที่สามารถเชื่อถือได้

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

โปรดทราบว่าคุณไม่สามารถทำการอนุญาตแบบเพิ่มหน่วยด้วยขั้นตอนแอปที่ติดตั้งได้

login_hint (ไม่จำเป็น) เมื่อแอปของคุณทราบว่าผู้ใช้รายใดพยายามตรวจสอบสิทธิ์แอปสามารถให้พารามิเตอร์นี้เป็นคำใบ้ให้กับเซิร์ฟเวอร์การตรวจสอบสิทธิ์ การผ่านคำใบ้นี้จะระงับตัวเลือกบัญชีผู้ใช้และกรอกอีเมลล่วงหน้าในแบบฟอร์มการลงชื่อเข้าใช้หรือเลือกเซสชันที่เหมาะสม (หากผู้ใช้ใช้ การลงชื่อเข้า ใช้ หลายบัญชี ) ซึ่งจะช่วยให้คุณหลีกเลี่ยงปัญหาที่เกิดขึ้นหากแอปของคุณ เข้าสู่ระบบบัญชีผู้ใช้ที่ไม่ถูกต้อง ค่าอาจเป็นที่อยู่อีเมลหรือสตริง sub ซึ่งเทียบเท่ากับ Google ID ของผู้ใช้
prompt (ไม่จำเป็น) รายการค่าสตริงที่คั่นด้วยช่องว่างที่ระบุว่าเซิร์ฟเวอร์การอนุญาตพร้อมต์ให้ผู้ใช้ตรวจสอบสิทธิ์และยินยอมอีกครั้งหรือไม่ ค่าที่เป็นไปได้คือ:
  • none

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

  • consent

    เซิร์ฟเวอร์การอนุญาตจะแจ้งผู้ใช้เพื่อขอความยินยอมก่อนที่จะส่งคืนข้อมูลไปยังไคลเอนต์

  • select_account

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

หากไม่มีการระบุค่าและผู้ใช้ไม่ได้รับอนุญาตการเข้าถึงก่อนหน้านี้ผู้ใช้จะแสดงหน้าจอคำยินยอม

การตรวจสอบความถูกต้องของโทเค็น ID

คุณต้องตรวจสอบความถูกต้องของโทเค็น ID ทั้งหมดบนเซิร์ฟเวอร์ของคุณเว้นแต่คุณจะรู้ว่ามาจาก Google โดยตรง ตัวอย่างเช่นเซิร์ฟเวอร์ของคุณต้องตรวจสอบว่าเป็นโทเค็น ID ที่ได้รับจากแอปไคลเอ็นต์ของคุณอย่างแท้จริง

ต่อไปนี้เป็นสถานการณ์ทั่วไปที่คุณอาจส่ง ID โทเค็นไปยังเซิร์ฟเวอร์ของคุณ:

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

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

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

การตรวจสอบความถูกต้องของโทเค็น ID ต้องใช้หลายขั้นตอน:

  1. ตรวจสอบว่าโทเค็น ID ได้รับการลงนามอย่างถูกต้องโดยผู้ออก โทเค็นที่ออกโดย Google ได้รับการลงนามโดยใช้หนึ่งในใบรับรองที่พบใน URI ที่ระบุในค่าข้อมูลเมตา jwks_uri ของ เอกสาร Discovery
  2. ตรวจสอบว่าค่าของการอ้างสิทธิ์ iss ในโทเค็น ID เท่ากับ https://accounts.google.com หรือ accounts.google.com
  3. ตรวจสอบว่าค่าของ aud เรียกร้องในโทเค็น ID เท่ากับรหัสลูกค้าของแอป
  4. ตรวจสอบว่าไม่ผ่านเวลาหมดอายุ (การอ้างสิทธิ์ exp ) ของโทเค็น ID
  5. หากคุณระบุ ค่าพารามิเตอร์ hd ในคำขอให้ตรวจสอบว่าโทเค็นรหัสมีการอ้างสิทธิ์ hd ที่ตรงกับโดเมนที่โฮสต์ของ G Suite ที่ยอมรับ

ขั้นตอนที่ 2 ถึง 5 เกี่ยวข้องกับการเปรียบเทียบสตริงและวันที่เท่านั้นซึ่งค่อนข้างตรงไปตรงมาดังนั้นเราจะไม่ลงรายละเอียดที่นี่

ขั้นตอนแรกซับซ้อนกว่าและเกี่ยวข้องกับการตรวจสอบลายเซ็นการเข้ารหัส สำหรับวัตถุประสงค์ในการ ดีบัก คุณสามารถใช้ปลายทาง tokeninfo ของ Google เพื่อเปรียบเทียบกับการประมวลผลภายในที่ใช้งานบนเซิร์ฟเวอร์หรืออุปกรณ์ของคุณ สมมติว่าค่าโทเค็น ID ของคุณคือ XYZ123 จากนั้นคุณจะยกเลิกการอ้างอิง URI https://oauth2.googleapis.com/tokeninfo?id_token= XYZ123 หากลายเซ็นโทเค็นถูกต้องการตอบสนองจะเป็นเพย์โหลด JWT ในรูปแบบอ็อบเจ็กต์ JSON ที่ถอดรหัส

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

เนื่องจาก Google เปลี่ยนคีย์สาธารณะเพียงไม่บ่อยครั้งคุณสามารถแคชโดยใช้คำสั่งแคชของการตอบสนอง HTTP และในกรณีส่วนใหญ่ทำการตรวจสอบความถูกต้องภายในได้อย่างมีประสิทธิภาพมากกว่าการใช้ปลายทาง tokeninfo การตรวจสอบความถูกต้องนี้ต้องมีการเรียกและแยกวิเคราะห์ใบรับรองและทำการเรียกใช้การเข้ารหัสที่เหมาะสมเพื่อตรวจสอบลายเซ็น โชคดีที่มีไลบรารีที่ดีบั๊กไว้ให้บริการในหลากหลายภาษาเพื่อให้บรรลุเป้าหมายนี้ (ดู jwt.io )

การรับข้อมูลโปรไฟล์ผู้ใช้

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

  1. เพื่อให้สอดคล้องกับ OpenID คุณต้องรวมค่าขอบเขต openid profile ใน คำขอการตรวจสอบสิทธิ์ ของคุณ

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

    scope=openid%20profile%20email
  2. เพิ่มโทเค็นการเข้าถึงของคุณไปยังส่วนหัวการอนุญาตและส่งคำขอ HTTPS GET ไปยังปลายทาง userinfo ซึ่งคุณควรดึงข้อมูลจาก เอกสาร Discovery โดยใช้ค่าข้อมูลเมตาของ userinfo_endpoint การตอบกลับ userinfo ประกอบด้วยข้อมูลเกี่ยวกับผู้ใช้ดังที่อธิบายไว้ใน OpenID Connect Standard Claims และค่า claims_supported metadata ของเอกสาร Discovery ผู้ใช้หรือองค์กรของพวกเขาอาจเลือกที่จะจัดหาหรือระงับบางฟิลด์ดังนั้นคุณอาจไม่ได้รับข้อมูลสำหรับทุกฟิลด์สำหรับขอบเขตการเข้าถึงที่ได้รับอนุญาตของคุณ

เอกสารการค้นพบ

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

เพื่อลดความซับซ้อนในการใช้งานและเพิ่มความยืดหยุ่น OpenID Connect อนุญาตให้ใช้ "เอกสารการค้นพบ" ซึ่งเป็นเอกสาร JSON ที่พบในตำแหน่งที่รู้จักกันดีซึ่งมีคู่คีย์ - ค่าซึ่งให้รายละเอียดเกี่ยวกับการกำหนดค่าของผู้ให้บริการ OpenID Connect รวมถึง URI ของการอนุญาต , โทเค็น, การเพิกถอน, ข้อมูลผู้ใช้และจุดสิ้นสุดของคีย์สาธารณะ เอกสารการค้นพบสำหรับบริการ OpenID Connect ของ Google อาจดึงมาจาก:

https://accounts.google.com/.well-known/openid-configuration

ในการใช้บริการ OpenID Connect ของ Google คุณควรฮาร์ดโค้ด URI เอกสารการค้นพบ ( https://accounts.google.com/.well-known/openid-configuration ) ลงในแอปพลิเคชันของคุณ แอปพลิเคชันของคุณดึงเอกสารใช้กฎการแคชในการตอบกลับจากนั้นดึงข้อมูล URI ปลายทางจากเอกสารนั้นตามต้องการ ตัวอย่างเช่นในการตรวจสอบสิทธิ์ผู้ใช้รหัสของคุณจะดึงค่าข้อมูลเมตาของ authorization_endpoint ( https://accounts.google.com/o/oauth2/v2/auth ในตัวอย่างด้านล่าง) เป็น URI พื้นฐานสำหรับคำขอการตรวจสอบสิทธิ์ที่ส่งไปยัง Google

นี่คือตัวอย่างของเอกสารดังกล่าว ชื่อฟิลด์คือชื่อที่ระบุไว้ใน OpenID Connect Discovery 1.0 (อ้างถึงความหมายของเอกสารนั้น) ค่านี้เป็นเพียงภาพประกอบเท่านั้นและอาจมีการเปลี่ยนแปลงแม้ว่าจะคัดลอกมาจากเอกสาร Google Discovery จริงเวอร์ชันล่าสุด:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

คุณอาจหลีกเลี่ยง HTTP round-trip ได้โดยการแคชค่าจากเอกสาร Discovery ใช้ส่วนหัวแคช HTTP มาตรฐานและควรเคารพ

ไลบรารีไคลเอ็นต์

ไลบรารีไคลเอ็นต์ต่อไปนี้ทำให้การใช้ OAuth 2.0 ง่ายขึ้นโดยการรวมเข้ากับเฟรมเวิร์กยอดนิยม:

การปฏิบัติตามข้อกำหนดของ OpenID Connect

ระบบตรวจสอบสิทธิ์ OAuth 2.0 ของ Google รองรับ คุณสมบัติที่จำเป็น ของข้อกำหนด OpenID Connect Core ไคลเอ็นต์ใด ๆ ที่ออกแบบมาเพื่อทำงานกับ OpenID Connect ควรทำงานร่วมกับบริการนี้ (ยกเว้น วัตถุคำขอ OpenID )