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

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

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

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

ตั้งค่า 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 และไลบรารีของไคลเอ็นต์ Google ซึ่งพร้อมใช้งานสําหรับแพลตฟอร์มที่หลากหลาย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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

// 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);
}

// 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.");
}

# 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

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

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

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 อาจมีช่องต่อไปนี้ (หรือที่เรียกว่าการอ้างสิทธิ์)

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 ยอมรับ

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

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

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

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

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

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

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

1. ยืนยันว่าผู้ออกโทเค็นโทเค็นลงนามอย่างถูกต้อง โทเค็นที่ออกโดย Google ได้รับการลงนามโดยใช้ใบรับรองที่พบใน URI ที่ระบุไว้ในค่าข้อมูลเมตา jwks_uri ของเอกสาร Discovery
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 ของคีย์จากเอกสาร Discovery โดยใช้ค่าข้อมูลเมตา 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 ซึ่งคุณควรเรียกข้อมูลจากเอกสาร 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 ได้ง่ายขึ้นด้วยการผสานรวมกับเฟรมเวิร์กยอดนิยม

• ไลบรารีของไคลเอ็นต์ Google APIs สําหรับ Java
• ไลบรารีของไคลเอ็นต์ Google APIs สําหรับ Python
• ไลบรารีของไคลเอ็นต์ Google APIs สําหรับ .NET
• ไลบรารีของไคลเอ็นต์ Google APIs สําหรับ Ruby
• ไลบรารีของไคลเอ็นต์ Google APIs สําหรับ PHP
• ไลบรารี OAuth 2.0 สําหรับ Google Web Toolkit
• กล่องเครื่องมือของ Google สําหรับตัวควบคุม OAuth 2.0 ของ Mac

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

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