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

OpenID Connect

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

To view the client ID and client secret for a given OAuth 2.0 credential, click the following text: Select credential. In the window that opens, choose your project and the credential you want, then click View.

Or, view your client ID and client secret from the Credentials page in API Console:

Go to the Credentials page.
Click the name of your credential or the pencil () icon. Your client ID and secret are at the top of the 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 ซึ่งออกแบบมาเพื่อใช้ในการยืนยันตัวตนในอินเทอร์เน็ต

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

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

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

โปรดตรวจสอบว่าได้ตั้งค่าแอปใน API 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 API สําหรับ 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 ของผู้ใช้ได้ หากคุณไม่ได้ระบุ 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 ConsoleCredentials 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) ซึ่งก็คือออบเจ็กต์ 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"
}

โทเค็นรหัส 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`		เป็นจริงหากอีเมลของผู้ใช้ได้รับการยืนยันแล้ว หรือเป็น "เท็จ"
`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 รายการต่อไคลเอ็นต์/ผู้ใช้ และอีกโทเค็นหนึ่งต่อผู้ใช้ในไคลเอ็นต์ทั้งหมด หากแอปพลิเคชันขอโทเค็นการรีเฟรชมากเกินไป โทเค็นอาจถึงขีดจํากัดเหล่านี้ ซึ่งในกรณีนี้โทเค็นการรีเฟรชเก่าจะหยุดทํางาน

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

คุณแจ้งให้ผู้ใช้ให้สิทธิ์แอปอีกครั้งได้โดยตั้งค่าพารามิเตอร์ prompt เป็น consent ในคําขอการตรวจสอบสิทธิ์ เมื่อรวม prompt=consent ไว้ด้วย หน้าจอขอความยินยอมจะแสดงทุกครั้งที่แอปขอสิทธิ์ในขอบเขตการเข้าถึง แม้จะเคยให้สิทธิ์ขอบเขตทั้งหมดในโปรเจ็กต์ Google APIs แล้วก็ตาม ดังนั้น ให้รวม 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 การเปลี่ยนเส้นทางเพื่อเรียกโทเค็นจากตัวระบุ `#fragment` URI
`redirect_uri`	(จำเป็น)	กําหนดตําแหน่งที่จะส่งคําตอบ ค่าของพารามิเตอร์นี้ต้องตรงกับค่าเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าที่ตั้งไว้ใน API ConsoleCredentials 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 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 ของเอกสาร Discovery
ตรวจสอบว่าค่าของการอ้างสิทธิ์ 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 ของคีย์จากเอกสาร Discovery โดยใช้ค่าข้อมูลเมตา jwks_uri คําขอที่ส่งไปยังปลายทางการแก้ไขข้อบกพร่องอาจถูกควบคุมหรืออาจมีข้อผิดพลาดที่ไม่ต่อเนื่อง

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

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

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

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

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

เอกสาร Discovery

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

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

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

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

เอกสาร Discovery

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

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

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