OpenID Connect

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ภาพหน้าจอหน้าคํายินยอม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PHP

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

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

Java

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

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

Python

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

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

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

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

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

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

Java

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

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

Python

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

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

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

การตอบกลับมีพารามิเตอร์ code ซึ่งเป็นรหัสการให้สิทธิ์แบบใช้ครั้งเดียวที่เซิร์ฟเวอร์ของคุณแลกเปลี่ยนสําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นรหัสได้ เซิร์ฟเวอร์ของคุณแลกเปลี่ยน Exchange นี้โดยการส่งคําขอ 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 Web Token) ซึ่งก็คือออบเจ็กต์ JSON ที่เข้ารหัสฐาน 64 ที่เข้ารหัสแบบเข้ารหัส โดยปกติสิ่งสําคัญคือคุณต้องตรวจสอบโทเค็นรหัสก่อนใช้งาน แต่เนื่องจากคุณกําลังสื่อสารกับ 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 ภายในแอปพลิเคชันเป็นคีย์ตัวระบุที่ไม่ซ้ํากันสําหรับผู้ใช้ ความยาวสูงสุดของอักขระ ASCII ที่คํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่สูงสุด 255 อักขระ
at_hash แฮชโทเค็นเพื่อการเข้าถึง ยืนยันว่าโทเค็นเพื่อการเข้าถึงเชื่อมโยงกับโทเค็นข้อมูลประจําตัว หากออกโทเค็นรหัสด้วยค่า access_token ในขั้นตอนของเซิร์ฟเวอร์ การอ้างสิทธิ์นี้จะรวมอยู่ในการอ้างสิทธิ์เสมอ คุณอาจใช้การอ้างสิทธิ์นี้เป็นกลไกสํารองเพื่อป้องกันการโจมตีแบบปลอมแปลงแบบข้ามเว็บไซต์ได้ แต่หากทําตามขั้นตอนที่ 1 และขั้นตอนที่ 3 คุณก็ไม่จําเป็นต้องยืนยันโทเค็นเพื่อการเข้าถึง
azp client_id ของผู้นําเสนอที่ได้รับอนุญาต ต้องใช้การอ้างสิทธิ์นี้เฉพาะในกรณีที่ฝ่ายที่ขอโทเค็นรหัสไม่เหมือนกับกลุ่มเป้าหมายของโทเค็นรหัส โดยอาจพบใน Google สําหรับแอปลูกผสมที่เว็บแอปพลิเคชันและแอป Android มี OAuth 2.0 ที่ต่างกัน client_id แต่ใช้โปรเจ็กต์ Google APIs เดียวกัน
email อีเมลของผู้ใช้ ค่านี้อาจไม่ซ้ําสําหรับผู้ใช้รายนี้และไม่เหมาะสําหรับการใช้เป็นคีย์หลัก ระบุเฉพาะเมื่อขอบเขตมีค่าค่าของ email เท่านั้น
email_verified เป็นจริงหากอีเมลของผู้ใช้ได้รับการยืนยันหรือเท็จ
family_name นามสกุลหรือนามสกุลของผู้ใช้ ระบบอาจระบุเมื่อมีการอ้างสิทธิ์ name อยู่
given_name ชื่อหรือชื่อของผู้ใช้ ระบบอาจระบุเมื่อมีการอ้างสิทธิ์ name อยู่
hd โดเมนที่เชื่อมโยงกับองค์กร 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 APIs อื่นๆ

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

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

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

ข้อควรพิจารณามีดังนี้

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

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

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

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

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

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

พารามิเตอร์ จำเป็น คำอธิบาย
client_id (ต้องระบุ) สตริงรหัสไคลเอ็นต์ที่ได้รับจาก API ConsoleCredentials pageตามที่อธิบายไว้ในรับข้อมูลเข้าสู่ระบบ OAuth 2.0
nonce (ต้องระบุ) ค่าแบบสุ่มที่สร้างโดยแอปของคุณที่ให้การปกป้องการเล่นซ้ํา
response_type (ต้องระบุ) หากค่าเป็น code ให้เปิดใช้ขั้นตอนการให้สิทธิ์แบบพื้นฐาน ซึ่งต้องใช้ POST กับปลายทางของโทเค็นเพื่อรับโทเค็น หากค่าเป็น token id_token หรือ id_token token ให้เปิดตัวโฟลว์แบบไม่เจาะจงปลายทาง ซึ่งจะต้องใช้ JavaScript ที่ URI การเปลี่ยนเส้นทางเพื่อเรียกโทเค็นจากตัวระบุ #fragment ของ URI
redirect_uri (ต้องระบุ) ระบุตําแหน่งที่จะส่งการตอบกลับ ค่าของพารามิเตอร์นี้ต้องตรงกับค่าเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าใดค่าหนึ่งใน API Console Credentials 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
display (ไม่บังคับ) ค่าสตริง ASCII สําหรับระบุว่าเซิร์ฟเวอร์การให้สิทธิ์แสดงหน้าอินเทอร์เฟซการตรวจสอบสิทธิ์และคํายินยอมของผู้ใช้อย่างไร ระบบจะระบุค่าต่อไปนี้และยอมรับโดยเซิร์ฟเวอร์ของ Google แต่จะไม่มีผลต่อลักษณะการทํางานของ page, popup, touch และ wap
hd (ไม่บังคับ)

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

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

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

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

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

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

  • consent

    เซิร์ฟเวอร์การให้สิทธิ์จะแจ้งให้ผู้ใช้ขอคํายินยอมก่อนส่งคืนข้อมูลให้ลูกค้า

  • select_account

    เซิร์ฟเวอร์การให้สิทธิ์จะแจ้งให้ผู้ใช้เลือกบัญชีผู้ใช้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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