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

OpenID Connect

API ของ OAuth 2.0 ของ 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 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สร้างโทเค็นสถานะการป้องกันการปลอมแปลง
ส่งคําขอตรวจสอบสิทธิ์ไปยัง Google
ยืนยันโทเค็นการป้องกันสถานะการปลอมแปลง
Exchange 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

ขั้นตอนถัดไปคือการสร้างคําขอ HTTPS GET ด้วยพารามิเตอร์ URI ที่เหมาะสม โปรดสังเกตการใช้ HTTPS แทน HTTP ในทุกขั้นตอนของกระบวนการนี้ และจะปฏิเสธการเชื่อมต่อ HTTP คุณควรดึงข้อมูล URI ฐานจากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตา 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 ConsoleCredentials pageหากค่านี้ไม่ตรงกับ URI ที่ได้รับอนุญาต คําขอจะล้มเหลวเพราะมีข้อผิดพลาด redirect_uri_mismatch
state ควรรวมค่าของโทเค็นเซสชันที่ไม่ซ้ํากันสําหรับการปลอมแปลง รวมไปถึงข้อมูลอื่นๆ ที่จําเป็นในการกู้คืนบริบทเมื่อผู้ใช้กลับไปที่แอปพลิเคชัน เช่น URL เริ่มต้น (อ่านเพิ่มเติมที่ state)
nonce เป็นค่าแบบสุ่มที่สร้างโดยแอปซึ่งจะเปิดใช้การป้องกันการเล่นซ้ําหากมี
login_hint อาจเป็นอีเมลของผู้ใช้หรือสตริง sub ก็ได้ ซึ่งเทียบเท่ากับรหัส Google ของผู้ใช้ หากคุณไม่ได้ระบุ login_hint และผู้ใช้ลงชื่อเข้าสู่ระบบอยู่ หน้าจอคํายินยอมจะมีคําขออนุมัติให้ปล่อยอีเมลของผู้ใช้ออกจากแอป (อ่านข้อมูลเพิ่มเติมได้ที่ login_hint)
ใช้พารามิเตอร์ hd เพื่อเพิ่มประสิทธิภาพโฟลว์ OpenID Connect ให้กับผู้ใช้ในโดเมนที่ต้องการที่เชื่อมโยงกับองค์กร Google 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

// 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

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

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

ช่อง
`code`	รหัสการให้สิทธิ์ที่แสดงผลจากคําขอเริ่มต้น
`client_id`	รหัสไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0
`client_secret`	รหัสลับไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลรับรอง OAuth 2.0
`redirect_uri`	URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตของ `client_id` หนึ่งๆ ที่ระบุใน API Console Credentials 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 ที่เข้ารหัสฐาน 64 ที่เข้ารหัสแบบเข้ารหัส ปกติแล้วคุณจําเป็นต้องตรวจสอบโทเค็นรหัสก่อนที่จะใช้งาน แต่เนื่องจากคุณกําลังสื่อสารกับ Google โดยตรงผ่านช่องทาง HTTPS ที่ไม่มีตัวกลาง และใช้ข้อมูลลับของไคลเอ็นต์เพื่อตรวจสอบสิทธิ์ตัวเองกับ Google คุณจะมั่นใจได้ว่าโทเค็นที่คุณได้รับมาจาก Google และถูกต้องจริงๆ หากเซิร์ฟเวอร์ส่งโทเค็นรหัสไปยังคอมโพเนนต์อื่นๆ ของแอป องค์ประกอบอื่นๆ จะต้องตรวจสอบโทเค็นก่อนที่จะใช้งาน

เนื่องจากไลบรารี API ส่วนใหญ่จะรวมการตรวจสอบกับการดําเนินการถอดรหัสค่าฐาน 64url และแยกวิเคราะห์ 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"
}

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

การอ้างสิทธิ์	ระบุแล้ว	คำอธิบาย
`aud`	ทุกครั้ง	กลุ่มเป้าหมายที่ใช้โทเค็นรหัสนี้ ซึ่งต้องเป็นรหัสไคลเอ็นต์ OAuth 2.0 ของแอปพลิเคชัน
`exp`	ทุกครั้ง	ระบบจะไม่ยอมรับเวลาหมดอายุของโทเค็นรหัสหรือหลังจากนั้น แสดงในเวลา Unix (จํานวนเต็มวินาที)
`iat`	ทุกครั้ง	เวลาที่ออกโทเค็นรหัส แสดงในเวลา Unix (จํานวนเต็มวินาที)
`iss`	ทุกครั้ง	ตัวระบุผู้ออกใบรับรองสําหรับผู้ออกใบรับรอง `https://accounts.google.com` หรือ `accounts.google.com` สําหรับโทเค็นรหัส Google เสมอ
`sub`	ทุกครั้ง	ตัวระบุผู้ใช้ รหัสที่ไม่ซ้ํากันในบัญชี Google ทั้งหมดและไม่นํามาใช้ซ้ํา บัญชี Google หนึ่งสามารถมีอีเมลหลายรายการในเวลาที่ต่างกัน แต่ค่า `sub` จะไม่มีการเปลี่ยนแปลง ใช้ `sub` ภายในแอปพลิเคชันเป็นคีย์ตัวระบุที่ไม่ซ้ํากันของผู้ใช้ ความยาวสูงสุด 255 อักขระซึ่งคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ของ ASCII
`at_hash`		แฮชโทเค็นเพื่อการเข้าถึง ตรวจสอบความถูกต้องของโทเค็นเพื่อการเข้าถึงที่เชื่อมโยงกับโทเค็นข้อมูลประจําตัว หากสร้างโทเค็นรหัสด้วยค่า `access_token` ในขั้นตอนของเซิร์ฟเวอร์ การอ้างสิทธิ์นี้จะรวมอยู่ในเสมอ คํากล่าวอ้างนี้ใช้เป็นกลไกทางเลือกในการป้องกันการโจมตีแบบการปลอมแปลงคําขอข้ามเว็บไซต์ได้ แต่หากคุณทําตามขั้นตอนที่ 1และขั้นตอนที่ 3 ไม่จําเป็นต้องยืนยันโทเค็นเพื่อการเข้าถึง
`azp`		`client_id` ของผู้นําเสนอที่ได้รับอนุญาต ต้องใช้การอ้างสิทธิ์เมื่อฝ่ายที่ขอโทเค็นรหัสไม่ใช่กลุ่มเดียวกับกลุ่มเป้าหมายของโทเค็นรหัส กรณีนี้อาจเกิดขึ้นที่ Google สําหรับแอปแบบผสม ซึ่งเว็บแอปพลิเคชันและแอป Android มี OAuth 2.0 `client_id` ต่างกันแต่มีโปรเจ็กต์ Google API เหมือนกัน
`email`		อีเมลของผู้ใช้ ค่านี้อาจไม่ซ้ํากับผู้ใช้รายนี้และไม่เหมาะกับการใช้งานเป็นคีย์หลัก ระบุต่อเมื่อขอบเขตมีค่าขอบเขต `email` เท่านั้น
`email_verified`		เป็นจริงหากอีเมลของผู้ใช้ได้รับการยืนยันแล้ว มิฉะนั้นจะเป็น false
`family_name`		นามสกุลหรือนามสกุลของผู้ใช้ อาจระบุเมื่อมีการอ้างสิทธิ์ `name`
`given_name`		ชื่อหรือชื่อผู้ใช้ที่ระบุของผู้ใช้ อาจระบุเมื่อมีการอ้างสิทธิ์ `name`
`hd`		โดเมนที่เชื่อมโยงกับองค์กร Google Cloud ของผู้ใช้ ระบุเมื่อผู้ใช้เป็นส่วนหนึ่งขององค์กร Google Cloud
`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 Exchange โทเค็นการรีเฟรชช่วยให้แอปเข้าถึง Google API ได้อย่างต่อเนื่องขณะที่ผู้ใช้ไม่ได้อยู่ในแอปพลิเคชัน หากต้องการขอโทเค็นการรีเฟรช ให้เพิ่มพารามิเตอร์ access_type เป็น offline ในคําขอการตรวจสอบสิทธิ์

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

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

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

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

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

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

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

พารามิเตอร์	จำเป็น	คำอธิบาย
`client_id`	(ต้องระบุ)	สตริงรหัสไคลเอ็นต์ที่ได้จาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0
`nonce`	(ต้องระบุ)	ค่าแบบสุ่มที่สร้างโดยแอปซึ่งจะเปิดใช้การป้องกันการเล่นซ้ํา
`response_type`	(ต้องระบุ)	หากค่าเป็น `code` ให้เปิดตัวขั้นตอนการให้สิทธิ์การให้สิทธิ์ขั้นพื้นฐานโดยใช้ `POST` ไปยังปลายทางของโทเค็นเพื่อรับโทเค็น หากค่าเป็น `token id_token` หรือ `id_token token` ก็จะเปิดตัวโฟลว์แบบไม่เจาะจงปลายทาง ซึ่งจําเป็นต้องใช้ JavaScript ที่ URI การเปลี่ยนเส้นทางเพื่อเรียกโทเค็นจาก URI `#fragment`ตัวระบุ
`redirect_uri`	(ต้องระบุ)	กําหนดว่าจะให้ส่งคําตอบไปที่ใด ค่าของพารามิเตอร์นี้ต้องตรงกับค่าการเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าใดค่าหนึ่งใน API Console Credentials page (รวมถึงรูปแบบ HTTP หรือ HTTPS, กรณี และปิดท้าย '/' หากมี)
`scope`	(ต้องระบุ)	พารามิเตอร์ขอบเขตต้องขึ้นต้นด้วยค่า `openid` แล้วใส่ค่า `profile` ค่า `email` หรือทั้ง 2 อย่าง หากมีค่าขอบเขต `profile` อยู่ โทเค็นรหัสอาจ (แต่ไม่รับประกัน) รวมการอ้างสิทธิ์ `profile` เริ่มต้นของผู้ใช้ หากมีค่าขอบเขต `email` โทเค็นรหัสจะมีการอ้างสิทธิ์ `email` และ `email_verified` นอกเหนือจากขอบเขตเฉพาะสําหรับ OpenID แล้ว อาร์กิวเมนต์ขอบเขตยังรวมค่าขอบเขตอื่นๆ ได้ ค่าขอบเขตทั้งหมดต้องคั่นด้วยช่องว่าง เช่น หากต้องการสิทธิ์การเข้าถึง Google ไดรฟ์ของผู้ใช้ 1 ไฟล์ พารามิเตอร์ขอบเขตอาจเป็น `openid profile email https://www.googleapis.com/auth/drive.file` ดูข้อมูลเกี่ยวกับขอบเขตที่พร้อมใช้งานได้ที่ขอบเขต OAuth 2.0 สําหรับ Google API หรือเอกสารประกอบสําหรับ Google API ที่ต้องการใช้
`state`	(ไม่บังคับแต่แนะนํา)	สตริงที่คลุมเครือซึ่งถูกปัดไว้ในโปรโตคอล กล่าวคือ ระบบจะแสดงผลเป็นพารามิเตอร์ URI ในขั้นตอนพื้นฐาน และในตัวระบุ URI `#fragment` ในขั้นตอนแบบไม่เจาะจงปลายทาง `state` มีประโยชน์สําหรับความสัมพันธ์คําขอและการตอบกลับ เนื่องจากระบบเดา `redirect_uri` ได้ การใช้ค่า `state` จะเพิ่มความมั่นใจสําหรับการเชื่อมต่อที่เข้ามาใหม่ซึ่งมาจากคําขอการตรวจสอบสิทธิ์ที่แอปเริ่มไว้ หากคุณสร้างสตริงแบบสุ่มหรือเข้ารหัสแฮชของสถานะไคลเอ็นต์บางรายการ (เช่น คุกกี้) ในตัวแปร `state` นี้ คุณจะตรวจสอบได้ว่าการตอบกลับนั้นมาจากคําขอและเบราว์เซอร์เดียวกันหรือไม่ ซึ่งจะช่วยป้องกันการโจมตี เช่น การปลอมแปลงคําขอแบบข้ามเว็บไซต์
`access_type`	(ไม่บังคับ)	ค่าที่อนุญาตคือ `offline` และ `online` เอฟเฟกต์แสดงอยู่ในการเข้าถึงแบบออฟไลน์ หากมีการขอโทเค็นเพื่อการเข้าถึง ไคลเอ็นต์จะไม่ได้รับโทเค็นการรีเฟรช เว้นแต่จะระบุค่า `offline` ไว้
`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` เซิร์ฟเวอร์การให้สิทธิ์จะแจ้งผู้ใช้ให้เลือกบัญชีผู้ใช้ ซึ่งช่วยให้ผู้ใช้ที่มีหลายบัญชีในเซิร์ฟเวอร์การให้สิทธิ์เลือกระหว่างหลายบัญชีที่มีเซสชันปัจจุบันได้ หากไม่ได้ระบุค่าไว้และผู้ใช้ไม่ได้ให้สิทธิ์เข้าถึงมาก่อน ระบบจะแสดงหน้าจอคํายินยอม

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

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

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

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

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

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

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

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

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

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

OpenID Connect ช่วยให้การใช้งาน OpenID Connect ง่ายขึ้นโดยใช้เอกสาร "Discovery เอกสารการค้นพบสําหรับบริการ OpenID Connect ของ Google อาจดึงมาจาก

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

หากต้องการใช้บริการ OpenID Connect ของ Google คุณควรฮาร์ดโค้ด URI ของเอกสาร Discovery (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 โดยการแคชค่าจากเอกสาร Discovery ส่วนหัวการแคช 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. Exchange code สําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส

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

โทเค็นรหัส'เพย์โหลด

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

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

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

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

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

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

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

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

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

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

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

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