หน้านี้ได้รับการแปลโดย Cloud Translation API

OpenID Connect

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

หมายเหตุ: หากต้องการแสดงปุ่ม "ลงชื่อเข้าใช้ด้วย Google" ในเว็บไซต์ ให้ใช้ บริการข้อมูลประจำตัวของ Google ซึ่งเป็นคลังไคลเอ็นต์การลงชื่อเข้าใช้ที่เราสร้างขึ้น ในโปรโตคอล OpenID Connect ไลบรารีนี้มีโทเค็นรหัสที่จัดรูปแบบ OpenID Connect แอป Android ควรใช้ Credential Manager API เพื่อใช้ขั้นตอนการลงชื่อเข้าใช้ด้วย Google

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

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

รับข้อมูลเข้าสู่ระบบ OAuth 2.0

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

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

หรือดูรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์จาก Clients page ใน Cloud Console

Go to the Clients page.
คลิกชื่อลูกค้าหรือไอคอนแก้ไข () รหัสไคลเอ็นต์และรหัสลับจะอยู่ที่ด้านบนของหน้า

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

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

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

Go to the Clients page.
คลิกลูกค้า
ดูหรือแก้ไข URI การเปลี่ยนเส้นทาง

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

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

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

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

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

เปิด Branding page ใน Google Cloud Console
If prompted, select a project, or create a new one.
กรอกแบบฟอร์มแล้วคลิกบันทึก

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

ตัวอย่างหน้าความยินยอม — **รูปที่ 1** ภาพหน้าจอของหน้าความยินยอม

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

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

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

หากเลือกที่จะไม่ใช้ไลบรารี ให้ทำตามวิธีการในส่วนที่เหลือของเอกสารนี้ ซึ่งอธิบายโฟลว์คำขอ HTTP ที่เป็นพื้นฐานของไลบรารีที่มีอยู่

การตรวจสอบสิทธิ์ผู้ใช้

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

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

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

โฟลว์ของเซิร์ฟเวอร์

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

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

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

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

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

client_id ซึ่งคุณจะได้รับจาก Cloud Console Clients page
response_type ซึ่งในคำขอขั้นตอนรหัสการให้สิทธิ์พื้นฐานควรเป็น code (อ่านเพิ่มเติมที่ response_type)
scope ซึ่งในคำขอพื้นฐานควรเป็น openid email (อ่านเพิ่มเติมที่ scope)
redirect_uri ควรเป็นปลายทาง HTTP ในเซิร์ฟเวอร์ของคุณที่จะรับการตอบกลับจาก Google ค่าต้องตรงกับ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตสำหรับไคลเอ็นต์ OAuth 2.0 ซึ่งคุณกำหนดค่าไว้ใน Cloud Console Credentials pageหากค่านี้ไม่ตรงกับ URI ที่ได้รับอนุญาต คำขอจะล้มเหลวพร้อมข้อผิดพลาด redirect_uri_mismatch
state ควรมีค่าของโทเค็นเซสชันที่ไม่ซ้ำกันเพื่อป้องกันการปลอมแปลง รวมถึงข้อมูลอื่นๆ ที่จำเป็นในการกู้คืนบริบทเมื่อผู้ใช้กลับมาที่แอปพลิเคชันของคุณ เช่น URL เริ่มต้น (อ่านเพิ่มเติมที่ state)
nonce คือค่าแบบสุ่มที่แอปสร้างขึ้นซึ่งเปิดใช้การป้องกันการเล่นซ้ำ เมื่อมีอยู่
login_hint อาจเป็นอีเมลของผู้ใช้หรือสตริง sub ซึ่งเทียบเท่ากับรหัส Google ของผู้ใช้ หากคุณไม่ระบุ login_hint และผู้ใช้เข้าสู่ระบบ หน้าจอขอความยินยอมจะรวมคำขออนุมัติเพื่อ เปิดเผยอีเมลของผู้ใช้ให้แอปของคุณ (อ่านเพิ่มเติมได้ที่ login_hint)
ใช้พารามิเตอร์ hd เพื่อเพิ่มประสิทธิภาพขั้นตอน OpenID Connect สำหรับผู้ใช้โดเมนหนึ่งๆ ที่เชื่อมโยงกับองค์กร Google Workspace หรือ Cloud (อ่านเพิ่มเติมได้ที่ 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

# 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` เป็นโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส

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

ช่อง
`code`	รหัสการให้สิทธิ์ที่ส่งคืนจาก คำขอเริ่มต้น
`client_id`	รหัสไคลเอ็นต์ที่คุณได้รับจาก Cloud Console Clients pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0
`client_secret`	รหัสลับไคลเอ็นต์ที่คุณได้รับจาก Cloud Console Clients pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0
`redirect_uri`	URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตสำหรับ `client_id` ที่ระบุใน Cloud Console Clients pageตามที่อธิบายไว้ใน ตั้งค่า 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` แสดงเป็นรายการสตริงที่คั่นด้วยช่องว่างและคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
`token_type`	ระบุประเภทโทเค็นที่แสดงผล ในขณะนี้ ช่องนี้จะมีค่าเป็น `Bearer` เสมอ
`refresh_token`	(ไม่บังคับ) ฟิลด์นี้จะแสดงก็ต่อเมื่อตั้งค่าพารามิเตอร์ `access_type` เป็น `offline` ในคำขอการตรวจสอบสิทธิ์ โปรดดูรายละเอียดที่หัวข้อโทเค็นการรีเฟรช

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

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

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

เพย์โหลดของโทเค็นรหัส

โทเค็นรหัสคือออบเจ็กต์ 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"
}

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

โทเค็นรหัส Google อาจมีฟิลด์ต่อไปนี้ (เรียกว่าการอ้างสิทธิ์)

อ้างสิทธิ์	ระบุแล้ว	คำอธิบาย
`aud`	ทุกครั้ง	กลุ่มเป้าหมายที่โทเค็นรหัสนี้มีไว้สำหรับ ต้องเป็นรหัสไคลเอ็นต์ OAuth 2.0 รหัสใดรหัสหนึ่งของแอปพลิเคชัน
`exp`	ทุกครั้ง	เวลาหมดอายุที่ต้องไม่ยอมรับโทเค็นรหัส แสดงใน เวลา Unix Epoch (วินาทีจำนวนเต็ม)
`iat`	ทุกครั้ง	เวลาที่ออกโทเค็นรหัส แสดงในเวลา Unix Epoch (วินาทีที่เป็นจำนวนเต็ม)
`iss`	ทุกครั้ง	ตัวระบุผู้ออกสำหรับผู้ออกการตอบกลับ เสมอ `https://accounts.google.com` หรือ `accounts.google.com` สำหรับโทเค็น รหัส Google
`sub`	ทุกครั้ง	ตัวระบุสำหรับผู้ใช้ที่ไม่ซ้ำกันในบัญชี Google ทั้งหมดและจะไม่มีการนำกลับมาใช้ซ้ำ บัญชี Google อาจมีอีเมลหลายรายการในเวลาต่างๆ แต่`sub`ค่าจะไม่เปลี่ยนแปลง ใช้ `sub` ภายในแอปพลิเคชัน เป็นคีย์ตัวระบุที่ไม่ซ้ำสำหรับผู้ใช้ ความยาวสูงสุด 255 อักขระ ASCII ที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
`auth_time`		เวลาที่การตรวจสอบสิทธิ์ผู้ใช้เกิดขึ้น ซึ่งเป็นตัวเลข JSON ที่แสดงจำนวน วินาทีที่ผ่านไปตั้งแต่ Epoch ของ Unix (1 มกราคม 1970, 00:00:00 UTC) ระบุเมื่อมีการรวมการอ้างสิทธิ์ `auth_time` ไว้ในคำขอการตรวจสอบสิทธิ์และเปิดใช้ในการตั้งค่า
`at_hash`		แฮชโทเค็นเพื่อการเข้าถึง ให้การตรวจสอบว่าโทเค็นเพื่อการเข้าถึงเชื่อมโยงกับโทเค็นรหัส หากออกโทเค็นรหัสที่มีค่า `access_token` ในโฟลว์ฝั่งเซิร์ฟเวอร์ ระบบจะรวมการอ้างสิทธิ์นี้เสมอ การอ้างสิทธิ์นี้สามารถใช้เป็นกลไกสำรองเพื่อ ป้องกันการโจมตีแบบ Cross-Site Request Forgery แต่หากคุณทำตามขั้นตอนที่ 1 และขั้นตอนที่ 3 ก็ไม่จำเป็นต้อง ยืนยันโทเค็นเพื่อการเข้าถึง
`azp`		`client_id` ของผู้นำเสนอที่ได้รับอนุญาต การอ้างสิทธิ์นี้จำเป็นเฉพาะในกรณีที่ ฝ่ายที่ขอโทเค็นรหัสไม่ใช่กลุ่มเป้าหมายของโทเค็นรหัส กรณีนี้อาจเกิดขึ้นที่ Google สำหรับแอปแบบไฮบริดที่เว็บแอปพลิเคชันและแอป Android มี `client_id` OAuth 2.0 ที่แตกต่างกัน แต่ใช้โปรเจ็กต์ Google APIs เดียวกัน
`email`		อีเมลของผู้ใช้ ระบุเฉพาะในกรณีที่คุณรวมขอบเขต `email` ไว้ใน คำขอ ค่าของการอ้างสิทธิ์นี้อาจไม่ซ้ำกันสำหรับบัญชีนี้และอาจเปลี่ยนแปลง เมื่อเวลาผ่านไป ดังนั้นคุณไม่ควรใช้ค่านี้เป็นตัวระบุหลักเพื่อลิงก์กับ บันทึกผู้ใช้ นอกจากนี้ คุณยังไม่สามารถใช้โดเมนของ`email`การอ้างสิทธิ์เพื่อ ระบุผู้ใช้ Google Workspace หรือองค์กร Cloud ได้ แต่ให้ใช้การอ้างสิทธิ์ `hd` แทน คำเตือน: อย่าใช้ฟิลด์ `email` เป็นตัวระบุที่ไม่ซ้ำกัน สำหรับผู้ใช้ ใช้ช่อง `sub` เสมอ
`email_verified`		จริง หากยืนยันอีเมลของผู้ใช้แล้ว หรือเท็จ
`family_name`		นามสกุลของผู้ใช้ อาจระบุเมื่อมีคำกล่าวอ้าง `name`
`given_name`		ชื่อต้นของผู้ใช้ อาจระบุเมื่อมีคำกล่าวอ้าง `name`
`hd`		โดเมนที่เชื่อมโยงกับองค์กร Google Workspace หรือ Cloud ของผู้ใช้ ระบุในกรณีที่ผู้ใช้เป็นสมาชิกขององค์กร Google Cloud เท่านั้น คุณต้องตรวจสอบการอ้างสิทธิ์นี้ เมื่อจำกัดการเข้าถึงทรัพยากรให้เฉพาะสมาชิกของโดเมนบางโดเมนเท่านั้น การไม่มีการอ้างสิทธิ์นี้แสดงว่าบัญชีไม่ได้เป็นของโดเมนที่ Google โฮสต์
`locale`		ภาษาของผู้ใช้ ซึ่งแสดงด้วยแท็กภาษา BCP 47 อาจระบุเมื่อมีคำกล่าวอ้าง `name` อยู่
`name`		ชื่อและนามสกุลของผู้ใช้ในรูปแบบที่แสดงได้ อาจระบุเมื่อ ขอบเขตคำขอมีสตริง "profile" ระบบจะแสดงโทเค็นรหัสจากการรีเฟรชโทเค็น เมื่อมีคำกล่าวอ้าง `name` คุณจะใช้คำกล่าวอ้างเหล่านั้นเพื่ออัปเดตบันทึกผู้ใช้ของแอปได้ โปรดทราบว่าเราไม่รับประกันว่าการอ้างสิทธิ์นี้จะปรากฏ
`nonce`		ค่าของ `nonce` ที่แอปของคุณระบุในคำขอตรวจสอบสิทธิ์ คุณควรป้องกันการโจมตีแบบเล่นซ้ำโดยแสดงค่านี้เพียงครั้งเดียว
`picture`		URL ของรูปโปรไฟล์ของผู้ใช้ อาจระบุเมื่อ ขอบเขตคำขอมีสตริง "profile" ระบบจะแสดงโทเค็นรหัสจากการรีเฟรชโทเค็น เมื่อมีข้อมูลการอ้างสิทธิ์ `picture` คุณจะใช้ข้อมูลดังกล่าวเพื่ออัปเดต บันทึกผู้ใช้ของแอปได้ โปรดทราบว่าเราไม่รับประกันว่าการอ้างสิทธิ์นี้จะปรากฏ
`profile`		URL ของหน้าโปรไฟล์ผู้ใช้ อาจระบุเมื่อ ขอบเขตคำขอมีสตริง "profile" ระบบจะแสดงโทเค็นรหัสจากการรีเฟรชโทเค็น เมื่อมีข้อมูลการอ้างสิทธิ์ `profile` คุณจะใช้ข้อมูลดังกล่าวเพื่ออัปเดต บันทึกผู้ใช้ของแอปได้ โปรดทราบว่าเราไม่รับประกันว่าการอ้างสิทธิ์นี้จะปรากฏ

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

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

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

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

ส่วนต่อไปนี้จะอธิบาย 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 ในคำขอการตรวจสอบสิทธิ์

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

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

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์ prompt ได้ที่ prompt ในตารางพารามิเตอร์ URI การตรวจสอบสิทธิ์

พารามิเตอร์ URI การตรวจสอบสิทธิ์

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

พารามิเตอร์ ต้องระบุ คำอธิบาย

client_id (จำเป็น) สตริงรหัสไคลเอ็นต์ที่คุณได้รับจาก Cloud Console Clients pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0

nonce (จำเป็น) ค่าแบบสุ่มที่แอปสร้างขึ้นซึ่งช่วยให้การป้องกันการเล่นซ้ำ

response_type (จำเป็น) หากค่าเป็น code จะเปิดใช้ ขั้นตอนการใช้รหัสการให้สิทธิ์พื้นฐาน ซึ่งต้องใช้ POST กับปลายทางโทเค็นเพื่อรับโทเค็น หากค่าเป็น token id_token หรือ id_token token จะเปิดใช้โฟลว์โดยนัย ซึ่งกำหนดให้ใช้ JavaScript ที่ URI การเปลี่ยนเส้นทางเพื่อดึงโทเค็นจากตัวระบุ URI #fragment

redirect_uri (จำเป็น) กำหนดตำแหน่งที่จะส่งคำตอบ ค่าของพารามิเตอร์นี้ต้องตรงกับค่าการเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าใดค่าหนึ่งที่คุณตั้งค่าไว้ใน Cloud Console Clients page (รวมถึงรูปแบบ HTTP หรือ HTTPS, ตัวพิมพ์เล็ก-ใหญ่ และ '/' ต่อท้าย หากมี)

scope

(จำเป็น)

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

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

หากมีค่าขอบเขต email โทเค็นรหัสจะมีเคลม email และ email_verified

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

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

state

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

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

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

access_type (ไม่บังคับ) ค่าที่อนุญาตคือ offline และ online ผลลัพธ์จะ ระบุไว้ใน การเข้าถึงแบบออฟไลน์ หากมีการขอโทเค็นเพื่อเข้าถึง ไคลเอ็นต์จะไม่ได้รับโทเค็นการรีเฟรช เว้นแต่จะระบุค่าของ offline

claims

(ไม่บังคับ)

พารามิเตอร์ claims ใช้เพื่อระบุฟิลด์ที่ไม่บังคับอย่างน้อย 1 รายการที่จะรวมไว้ใน ประเภทการตอบกลับโทเค็นรหัสคำขอการตรวจสอบสิทธิ์หรือปลายทาง userinfo ค่านี้คือออบเจ็กต์ JSON ที่มีประเภทการตอบกลับและการอ้างสิทธิ์ที่ขอ เซิร์ฟเวอร์ของ Google ยอมรับคำขออ้างสิทธิ์ต่อไปนี้

คำขออ้างสิทธิ์

auth_time ขอเวลาที่ผู้ใช้ได้รับการตรวจสอบสิทธิ์ครั้งล่าสุด หากต้องการแสดงผล auth_time เป็นฟิลด์ในการตอบกลับโทเค็นรหัส ให้ใส่ claims พารามิเตอร์คำขอ: claims={"id_token":{"auth_time":{"essential":true}}} ต้องเปิดใช้ในการตั้งค่า

display (ไม่บังคับ) ค่าสตริง ASCII สำหรับระบุวิธีที่เซิร์ฟเวอร์การให้สิทธิ์แสดงหน้าอินเทอร์เฟซผู้ใช้สำหรับการตรวจสอบสิทธิ์และความยินยอม ค่าต่อไปนี้จะได้รับการระบุและ ยอมรับโดยเซิร์ฟเวอร์ของ Google แต่จะไม่มีผลต่อลักษณะการทำงานของโฟลว์โปรโตคอล page, popup, touch และ wap

hd

(ไม่บังคับ)

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

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

include_granted_scopes

(ไม่บังคับ)

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

โปรดทราบว่าคุณไม่สามารถทำการให้สิทธิ์แบบเพิ่มทีละรายการด้วยโฟลว์แอปที่ติดตั้ง

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

prompt

(ไม่บังคับ)

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

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

หากไม่ได้ระบุค่าไว้และผู้ใช้ไม่เคยให้สิทธิ์เข้าถึงมาก่อน ระบบจะแสดงหน้าจอขอความยินยอมต่อผู้ใช้

hl (ไม่บังคับ) แท็กภาษา BCP 47 ที่ใช้เพื่อระบุ ภาษาที่แสดงสำหรับหน้าจอลงชื่อเข้าใช้ ตัวเลือกบัญชี และหน้าจอความยินยอม หากไม่ได้ระบุพารามิเตอร์นี้ ระบบจะใช้ภาษาเริ่มต้นตามการตั้งค่าบัญชี Google หรือเบราว์เซอร์ของผู้ใช้ เช่น หากต้องการขอ UI เป็นภาษาอังกฤษแบบอังกฤษ ให้ตั้งค่าพารามิเตอร์เป็น en-GB

การตรวจสอบโทเค็นรหัส

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

สถานการณ์ที่พบบ่อยซึ่งคุณอาจส่งโทเค็นรหัสไปยังเซิร์ฟเวอร์มีดังนี้

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

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

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

การตรวจสอบโทเค็นรหัสต้องมีหลายขั้นตอน ดังนี้

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

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

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

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

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

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

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

หากต้องการให้เป็นไปตามข้อกำหนดของ OpenID คุณต้องระบุ openid profile ค่าขอบเขตในคำขอการตรวจสอบสิทธิ์

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

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

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

OpenID Connect อนุญาตให้ใช้ "เอกสารการค้นหา" ซึ่งเป็นเอกสาร JSON ที่อยู่ในตำแหน่งที่รู้จักกันดีซึ่งมีคู่คีย์-ค่า ซึ่งให้รายละเอียดเกี่ยวกับการกำหนดค่าของผู้ให้บริการ OpenID Connect รวมถึง URI ของ ปลายทางการให้สิทธิ์ โทเค็น การเพิกถอน userinfo และคีย์สาธารณะ เพื่อให้การติดตั้งใช้งานง่ายขึ้นและมีความยืดหยุ่นมากขึ้น คุณสามารถดึงข้อมูลเอกสารการค้นพบสำหรับบริการ 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 ได้โดยการแคชค่าจากเอกสารการค้นพบ ระบบจะใช้ส่วนหัวการแคช HTTP มาตรฐานและควรปฏิบัติตาม

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

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

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

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

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

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

รับข้อมูลเข้าสู่ระบบ OAuth 2.0

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

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

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

การตรวจสอบสิทธิ์ผู้ใช้

โฟลว์ของเซิร์ฟเวอร์

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

PHP

Java

Python

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

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

PHP

Java

Python

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

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

เพย์โหลดของโทเค็นรหัส

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

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

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

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

การแจ้งให้ขอความยินยอมอีกครั้ง

พารามิเตอร์ URI การตรวจสอบสิทธิ์

การตรวจสอบโทเค็นรหัส

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

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

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

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

OpenID Connect

4. แลกเปลี่ยน `code` เป็นโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส