คุณใช้ API ของ OAuth 2.0 ของ Google ได้ทั้งสำหรับการตรวจสอบสิทธิ์และการให้สิทธิ์ เอกสารนี้ อธิบายการติดตั้งใช้งาน OAuth 2.0 ของเราสำหรับการตรวจสอบสิทธิ์ ซึ่งเป็นไปตามข้อกำหนด OpenID Connect และ ได้รับการรับรอง OpenID เอกสารประกอบที่อยู่ในการใช้ OAuth 2.0 เพื่อเข้าถึง Google APIs ยังใช้กับบริการนี้ด้วย หากต้องการสำรวจโปรโตคอลนี้แบบอินเทอร์แอกทีฟ เราขอแนะนำให้ใช้ Google OAuth 2.0 Playground หากต้องการรับความช่วยเหลือใน Stack Overflow ให้ติดแท็กคำถามด้วย "google-oauth"
การตั้งค่า OAuth 2.0
ก่อนที่แอปพลิเคชันจะใช้ระบบการตรวจสอบสิทธิ์ OAuth 2.0 ของ Google สำหรับการเข้าสู่ระบบของผู้ใช้ได้ คุณต้องตั้งค่าโปรเจ็กต์ใน เพื่อรับข้อมูลเข้าสู่ระบบ OAuth 2.0 ตั้งค่า URI การเปลี่ยนเส้นทาง และ (ไม่บังคับ) ปรับแต่งข้อมูลการสร้างแบรนด์ที่ผู้ใช้เห็นในหน้าจอคำยินยอมของผู้ใช้ นอกจากนี้ คุณยังใช้ เพื่อ สร้างบัญชีบริการ เปิดใช้การเรียกเก็บเงิน ตั้งค่าการกรอง และทํางานอื่นๆ ได้ด้วย ดูรายละเอียดเพิ่มเติมได้ที่ ความช่วยเหลือ
รับข้อมูลเข้าสู่ระบบ OAuth 2.0
คุณต้องมีข้อมูลเข้าสู่ระบบ OAuth 2.0 ซึ่งรวมถึงรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์เพื่อตรวจสอบสิทธิ์ผู้ใช้ และรับสิทธิ์เข้าถึง API ของ Google
ในการดูรหัสลูกค้าและข้อมูลลับของลูกค้าสำหรับข้อมูลรับรอง OAuth 2.0 ที่กำหนดให้คลิกข้อความต่อไปนี้: เลือกข้อมูลรับรอง ในหน้าต่างที่เปิดขึ้นให้เลือกโครงการและข้อมูลรับรองที่คุณต้องการจากนั้นคลิก ดู
หรือดูรหัสลูกค้าและข้อมูลลับลูกค้าของคุณจาก หน้าข้อมูลรับรอง ใน API Console :
- Go to the Credentials page.
- คลิกที่ชื่อหนังสือรับรองของคุณหรือไอคอนดินสอ ( create ) รหัสลูกค้าและความลับของคุณอยู่ที่ด้านบนของหน้า
ตั้งค่า URI การเปลี่ยนเส้นทาง
URI การเปลี่ยนเส้นทางที่คุณตั้งค่าใน จะกำหนด ตำแหน่งที่ Google ส่งคำตอบไปยังคำขอการตรวจสอบสิทธิ์
ในการสร้างดูหรือแก้ไข URIs การเปลี่ยนเส้นทางสำหรับข้อมูลรับรอง OAuth 2.0 ที่ระบุให้ทำดังต่อไปนี้:
- Go to the Credentials page.
- ในส่วน รหัสลูกค้า OAuth 2.0 ของหน้าคลิกข้อมูลรับรอง
- ดูหรือแก้ไข URIs การเปลี่ยนเส้นทาง
หากไม่มีส่วน รหัสลูกค้า OAuth 2.0 ในหน้าหนังสือรับรองแสดงว่าโครงการของคุณไม่มีข้อมูลรับรอง OAuth หากต้องการสร้างหนึ่งคลิก สร้างข้อมูลรับรอง
ปรับแต่งหน้าจอขอความยินยอมจากผู้ใช้
สำหรับผู้ใช้ของคุณ ประสบการณ์การตรวจสอบสิทธิ์ OAuth 2.0 จะมีหน้าจอคำยินยอมที่อธิบายข้อมูลที่ผู้ใช้เผยแพร่และข้อกำหนดที่เกี่ยวข้อง เช่น เมื่อผู้ใช้
เข้าสู่ระบบ ระบบอาจขอให้ผู้ใช้ให้สิทธิ์แอปของคุณเข้าถึงอีเมลและข้อมูลบัญชีพื้นฐาน
คุณขอสิทธิ์เข้าถึงข้อมูลนี้ได้โดยใช้พารามิเตอร์
scope ซึ่งแอปของคุณจะรวมไว้ใน
คำขอการตรวจสอบสิทธิ์ นอกจากนี้ คุณยังใช้ขอบเขตเพื่อขอสิทธิ์เข้าถึง
API อื่นๆ ของ Google ได้ด้วย
หน้าจอขอความยินยอมจากผู้ใช้ยังแสดงข้อมูลการสร้างแบรนด์ เช่น ชื่อผลิตภัณฑ์ โลโก้ และ URL ของหน้าแรก คุณควบคุมข้อมูลการสร้างแบรนด์ใน
วิธีเปิดใช้งานหน้าจอการยินยอมของโครงการ:
- เปิด 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 จึงไม่มีข้อมูลการสร้างแบรนด์ที่จะตั้งค่าใน )
การเข้าถึงบริการ
Google และบุคคลที่สามมีไลบรารีที่คุณใช้ดูแลรายละเอียดการติดตั้งใช้งานจำนวนมาก ในการตรวจสอบสิทธิ์ผู้ใช้และรับสิทธิ์เข้าถึง Google API ได้ ตัวอย่าง ได้แก่ Google Identity Services และ ไลบรารีของไคลเอ็นต์ Google ซึ่งพร้อมใช้งานสำหรับแพลตฟอร์ม ต่างๆ
หากเลือกที่จะไม่ใช้ไลบรารี ให้ทำตามวิธีการในส่วนที่เหลือของเอกสารนี้ ซึ่งอธิบายโฟลว์คำขอ HTTP ที่เป็นพื้นฐานของไลบรารีที่พร้อมใช้งาน
การตรวจสอบสิทธิ์ผู้ใช้
การตรวจสอบสิทธิ์ผู้ใช้เกี่ยวข้องกับการขอโทเค็นรหัสและตรวจสอบความถูกต้อง โทเค็นรหัส เป็นฟีเจอร์มาตรฐานของ OpenID Connect ที่ออกแบบมาเพื่อใช้ในการ แชร์การยืนยันตัวตนบนอินเทอร์เน็ต
แนวทางที่ใช้กันมากที่สุดในการตรวจสอบสิทธิ์ผู้ใช้และรับโทเค็นรหัสเรียกว่าโฟลว์ "เซิร์ฟเวอร์" และโฟลว์ "โดยนัย" ขั้นตอนของเซิร์ฟเวอร์ช่วยให้เซิร์ฟเวอร์แบ็กเอนด์ของ แอปพลิเคชันยืนยันตัวตนของบุคคลที่ใช้เบราว์เซอร์หรืออุปกรณ์เคลื่อนที่ได้ โฟลว์โดยนัยจะใช้เมื่อแอปพลิเคชันฝั่งไคลเอ็นต์ (โดยปกติคือแอป JavaScript ที่ทํางานใน เบราว์เซอร์) ต้องการเข้าถึง API โดยตรงแทนที่จะใช้เซิร์ฟเวอร์แบ็กเอนด์
เอกสารนี้อธิบายวิธีดำเนินการโฟลว์ฝั่งเซิร์ฟเวอร์เพื่อตรวจสอบสิทธิ์ผู้ใช้ โฟลว์โดยนัยมีความซับซ้อนมากกว่าอย่างมากเนื่องจากความเสี่ยงด้านความปลอดภัยในการจัดการและการใช้ โทเค็นในฝั่งไคลเอ็นต์ หากคุณต้องการใช้โฟลว์โดยนัย เราขอแนะนำให้ใช้บริการข้อมูลประจำตัวของ Google
โฟลว์ของเซิร์ฟเวอร์
โปรดตั้งค่าแอปใน เพื่อให้แอปใช้โปรโตคอลเหล่านี้และ ตรวจสอบสิทธิ์ผู้ใช้ได้ เมื่อผู้ใช้พยายามลงชื่อเข้าใช้ด้วย Google คุณต้องทำดังนี้
- สร้างโทเค็นสถานะป้องกันการปลอมแปลง
- ส่งคำขอการตรวจสอบสิทธิ์ไปยัง Google
- ยืนยันโทเค็นสถานะการป้องกันการปลอมแปลง
- แลกเปลี่ยน
codeเป็นโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส - รับข้อมูลผู้ใช้จากโทเค็นรหัส
- ตรวจสอบสิทธิ์ผู้ใช้
1. สร้างโทเค็นสถานะป้องกันการปลอมแปลง
คุณต้องปกป้องความปลอดภัยของผู้ใช้ด้วยการป้องกันการโจมตีแบบปลอมแปลงคำขอ ขั้นตอนแรก คือการสร้างโทเค็นเซสชันที่ไม่ซ้ำกันซึ่งเก็บสถานะระหว่างแอปกับไคลเอ็นต์ของผู้ใช้ จากนั้นคุณจะจับคู่โทเค็นเซสชันที่ไม่ซ้ำกันนี้กับการตอบกลับการตรวจสอบสิทธิ์ที่บริการลงชื่อเข้าใช้ Google OAuth ส่งคืนมาเพื่อยืนยันว่าผู้ใช้เป็นผู้ส่งคำขอ ไม่ใช่ผู้โจมตีที่เป็นอันตราย โทเค็นเหล่านี้มักเรียกว่าโทเค็นการปลอมแปลงคำขอข้ามเว็บไซต์ (CSRF)
ตัวเลือกที่ดีสำหรับโทเค็นสถานะคือสตริงที่มีอักขระประมาณ 30 ตัวซึ่งสร้างขึ้นโดยใช้ เครื่องมือสร้างตัวเลขสุ่มคุณภาพสูง อีกวิธีคือแฮชที่สร้างขึ้นโดยการลงนามตัวแปรสถานะเซสชันบางตัวด้วยคีย์ที่เก็บไว้เป็นความลับในแบ็กเอนด์
โค้ดต่อไปนี้แสดงการสร้างโทเค็นเซสชันที่ไม่ซ้ำกัน
PHP
คุณต้องดาวน์โหลด ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ PHP เพื่อใช้ตัวอย่างนี้
// Create a state token to prevent request forgery. // Store it in the session for later validation. $state = bin2hex(random_bytes(128/8)); $app['session']->set('state', $state); // Set the client ID, token state, and application name in the HTML while // serving it. return $app['twig']->render('index.html', array( 'CLIENT_ID' => CLIENT_ID, 'STATE' => $state, 'APPLICATION_NAME' => APPLICATION_NAME ));
Java
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สำหรับ Java เพื่อใช้ตัวอย่างนี้
// Create a state token to prevent request forgery. // Store it in the session for later validation. String state = new BigInteger(130, new SecureRandom()).toString(32); request.session().attribute("state", state); // Read index.html into memory, and set the client ID, // token state, and application name in the HTML before serving it. return new Scanner(new File("index.html"), "UTF-8") .useDelimiter("\\A").next() .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID) .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state) .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}", APPLICATION_NAME);
Python
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สำหรับ Python เพื่อใช้ตัวอย่างนี้
# Create a state token to prevent request forgery. # Store it in the session for later validation. state = hashlib.sha256(os.urandom(1024)).hexdigest() session['state'] = state # Set the client ID, token state, and application name in the HTML while # serving it. response = make_response( render_template('index.html', CLIENT_ID=CLIENT_ID, STATE=state, APPLICATION_NAME=APPLICATION_NAME))
2. ส่งคำขอการตรวจสอบสิทธิ์ไปยัง Google
ขั้นตอนถัดไปคือการสร้างGETคำขอ HTTPS ด้วยพารามิเตอร์ URI ที่เหมาะสม
โปรดสังเกตการใช้ HTTPS แทน HTTP ในทุกขั้นตอนของกระบวนการนี้ ระบบจะปฏิเสธการเชื่อมต่อ HTTP
คุณควรกู้ URI ฐานจากเอกสารการค้นพบ
โดยใช้ค่าข้อมูลเมตา authorization_endpoint การอภิปรายต่อไปนี้ถือว่า
URI ฐานคือ https://accounts.google.com/o/oauth2/v2/auth
สำหรับคำขอพื้นฐาน ให้ระบุพารามิเตอร์ต่อไปนี้
client_idซึ่งคุณได้รับจากresponse_typeซึ่งในคำขอขั้นตอนรหัสการให้สิทธิ์พื้นฐานควรเป็นcode(อ่านเพิ่มเติมที่response_type)scopeซึ่งในคำขอพื้นฐานควรเป็นopenid email(อ่านเพิ่มเติมที่scope)redirect_uriควรเป็นปลายทาง HTTP ในเซิร์ฟเวอร์ของคุณที่จะได้รับการตอบกลับจาก Google ค่าต้องตรงกับ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตสำหรับไคลเอ็นต์ OAuth 2.0 ซึ่งคุณกำหนดค่าไว้ใน Credentials pageหากค่านี้ไม่ตรงกับ URI ที่ได้รับอนุญาต คำขอจะล้มเหลวพร้อมข้อผิดพลาดredirect_uri_mismatchstateควรมีค่าของโทเค็นเซสชันที่ไม่ซ้ำกันเพื่อป้องกันการปลอมแปลง รวมถึงข้อมูลอื่นๆ ที่จำเป็นในการกู้คืนบริบทเมื่อผู้ใช้กลับมายังแอปพลิเคชันของคุณ เช่น URL เริ่มต้น (อ่านเพิ่มเติมที่state)nonceคือค่าแบบสุ่มที่แอปสร้างขึ้นซึ่งเปิดใช้การป้องกันการเล่นซ้ำ เมื่อมีอยู่login_hintอาจเป็นอีเมลของผู้ใช้หรือสตริงsubซึ่งเทียบเท่ากับรหัส Google ของผู้ใช้ หากคุณไม่ระบุlogin_hintและผู้ใช้เข้าสู่ระบบ หน้าจอขอความยินยอมจะรวมคำขออนุมัติเพื่อ เปิดเผยอีเมลของผู้ใช้ให้แอปของคุณ (อ่านเพิ่มเติมได้ที่login_hint)- ใช้พารามิเตอร์
hdเพื่อเพิ่มประสิทธิภาพขั้นตอน OpenID Connect สำหรับผู้ใช้โดเมนหนึ่งๆ ที่เชื่อมโยงกับองค์กร Google Workspace หรือ Cloud (อ่านเพิ่มเติมได้ที่hd)
ตัวอย่าง URI การตรวจสอบสิทธิ์ OpenID Connect ที่สมบูรณ์พร้อมการขึ้นบรรทัดใหม่และช่องว่าง เพื่อให้สามารถอ่านได้มีดังนี้
https://accounts.google.com/o/oauth2/v2/auth? response_type=code& client_id=424911365001.apps.googleusercontent.com& scope=openid%20email& redirect_uri=https%3A//oauth2.example.com/code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome& login_hint=jsmith@example.com& nonce=0394852-3190485-2490358& hd=example.com
ผู้ใช้ต้องให้ความยินยอมหากแอปขอข้อมูลใหม่เกี่ยวกับผู้ใช้ หรือหากแอปขอสิทธิ์เข้าถึงบัญชีที่ผู้ใช้ยังไม่อนุมัติ
3. ยืนยันโทเค็นสถานะป้องกันการปลอมแปลง
ระบบจะส่งการตอบกลับไปยัง redirect_uri ที่คุณระบุใน
คำขอ ระบบจะส่งคืนการตอบกลับทั้งหมดในสตริงการค้นหา
https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email
ในเซิร์ฟเวอร์ คุณต้องยืนยันว่า state ที่ได้รับจาก Google ตรงกับโทเค็นเซสชันที่คุณสร้างในขั้นตอนที่ 1 การยืนยันแบบไปกลับนี้
ช่วยยืนยันว่าผู้ใช้เป็นผู้ส่งคำขอ ไม่ใช่สคริปต์ที่เป็นอันตราย
โค้ดต่อไปนี้แสดงการยืนยันโทเค็นเซสชันที่คุณสร้างในขั้นตอนที่ 1
PHP
คุณต้องดาวน์โหลด ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ PHP เพื่อใช้ตัวอย่างนี้
// Ensure that there is no request forgery going on, and that the user // sending us this connect request is the user that was supposed to. if ($request->get('state') != ($app['session']->get('state'))) { return new Response('Invalid state parameter', 401); }
Java
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สำหรับ Java เพื่อใช้ตัวอย่างนี้
// Ensure that there is no request forgery going on, and that the user // sending us this connect request is the user that was supposed to. if (!request.queryParams("state").equals( request.session().attribute("state"))) { response.status(401); return GSON.toJson("Invalid state parameter."); }
Python
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ 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 ซึ่งเป็นรหัสการให้สิทธิ์แบบครั้งเดียวที่เซิร์ฟเวอร์ของคุณ
สามารถแลกเปลี่ยนเป็นโทเค็นเพื่อการเข้าถึงและโทเค็นรหัสได้ เซิร์ฟเวอร์ของคุณจะทำการแลกเปลี่ยนนี้โดยการส่งคำขอ HTTPS POST ระบบจะส่งคำขอ POST ไปยังปลายทางโทเค็น
ซึ่งคุณควรดึงข้อมูลจากเอกสารการค้นพบโดยใช้
ค่าข้อมูลเมตา token_endpoint การอภิปรายต่อไปนี้จะถือว่าปลายทางคือ
https://oauth2.googleapis.com/token คำขอต้องมีพารามิเตอร์ต่อไปนี้ในPOSTเนื้อหา
| ช่อง | |
|---|---|
code |
รหัสการให้สิทธิ์ที่ส่งคืนจาก คำขอเริ่มต้น |
client_id |
รหัสไคลเอ็นต์ที่คุณได้รับจาก ตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0 |
client_secret |
รหัสลับไคลเอ็นต์ที่คุณได้รับจาก ตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0 |
redirect_uri |
URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตสำหรับ client_id ที่ระบุใน
ตามที่อธิบายไว้ใน
ตั้งค่า 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 |
(ไม่บังคับ)
ฟิลด์นี้จะแสดงก็ต่อเมื่อตั้งค่าพารามิเตอร์
|
5. รับข้อมูลผู้ใช้จากโทเค็นรหัส
โทเค็นรหัสคือ JWT (JSON Web Token) ซึ่งเป็นออบเจ็กต์ JSON ที่เข้ารหัส Base64 และลงนามแบบเข้ารหัส โดยปกติแล้ว คุณต้องตรวจสอบโทเค็นรหัสก่อนที่จะใช้ แต่เนื่องจากคุณสื่อสารกับ Google โดยตรงผ่านช่อง HTTPS ที่ไม่มีตัวกลางและ ใช้ข้อมูลลับของไคลเอ็นต์เพื่อตรวจสอบสิทธิ์ตัวเองกับ Google คุณจึงมั่นใจได้ว่าโทเค็น ที่คุณได้รับมาจาก Google จริงๆ และใช้งานได้ หากเซิร์ฟเวอร์ส่งโทเค็นรหัสไปยังคอมโพเนนต์อื่นๆ ของแอป คอมโพเนนต์อื่นๆ จะต้องตรวจสอบโทเค็นก่อนใช้งาน
เนื่องจากไลบรารี API ส่วนใหญ่จะรวมการตรวจสอบเข้ากับการถอดรหัสค่าที่เข้ารหัส base64url และการแยกวิเคราะห์ JSON ภายใน คุณจึงอาจต้องตรวจสอบโทเค็นอยู่ดีเมื่อเข้าถึงการอ้างสิทธิ์ในโทเค็นรหัส
เพย์โหลดของโทเค็นรหัส
โทเค็นรหัสคือออบเจ็กต์ JSON ที่มีชุดคู่ชื่อ/ค่า ตัวอย่างที่จัดรูปแบบ เพื่อให้ง่ายต่อการอ่าน
{ "iss": "https://accounts.google.com", "azp": "1234987819200.apps.googleusercontent.com", "aud": "1234987819200.apps.googleusercontent.com", "sub": "10769150350006150715113082367", "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q", "hd": "example.com", "email": "jsmith@example.com", "email_verified": "true", "iat": 1353601026, "exp": 1353604926, "nonce": "0394852-3190485-2490358" }
โทเค็นรหัส Google อาจมีฟิลด์ต่อไปนี้ (เรียกว่าการอ้างสิทธิ์)
| อ้างสิทธิ์ | ระบุแล้ว | คำอธิบาย |
|---|---|---|
aud |
ทุกครั้ง | กลุ่มเป้าหมายที่โทเค็นรหัสนี้มีไว้สำหรับ ต้องเป็นรหัสไคลเอ็นต์ OAuth 2.0 รหัสใดรหัสหนึ่งของแอปพลิเคชัน |
exp |
ทุกครั้ง | เวลาหมดอายุที่ต้องไม่ยอมรับโทเค็นรหัส แสดงใน เวลา Unix Epoch (วินาทีจำนวนเต็ม) |
iat |
ทุกครั้ง | เวลาที่ออกโทเค็นรหัส แสดงในเวลา Unix Epoch (วินาทีจำนวนเต็ม) |
iss |
ทุกครั้ง | ตัวระบุผู้ออกสำหรับผู้ออกการตอบกลับ เสมอ
https://accounts.google.com หรือ accounts.google.com สำหรับ Google
โทเค็นรหัส |
sub |
ทุกครั้ง | ตัวระบุสำหรับผู้ใช้ที่ไม่ซ้ำกันในบัญชี Google ทั้งหมดและจะไม่มีการนำกลับมาใช้ซ้ำ บัญชี Google
อาจมีอีเมลหลายรายการในช่วงเวลาต่างๆ แต่ระบบจะไม่เปลี่ยนแปลงค่า
sub ใช้ sub ภายในแอปพลิเคชัน
เป็นคีย์ตัวระบุที่ไม่ซ้ำสำหรับผู้ใช้ ความยาวสูงสุด 255 อักขระ ASCII ที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
|
at_hash |
แฮชโทเค็นเพื่อการเข้าถึง ให้การตรวจสอบว่าโทเค็นเพื่อการเข้าถึงเชื่อมโยงกับโทเค็นรหัส
หากออกโทเค็นรหัสที่มีค่า access_token ในโฟลว์ฝั่งเซิร์ฟเวอร์
ระบบจะรวมการอ้างสิทธิ์นี้เสมอ การอ้างสิทธิ์นี้สามารถใช้เป็นกลไกสำรองเพื่อ
ป้องกันการโจมตีแบบ Cross-Site Request Forgery แต่หากคุณทำตามขั้นตอนที่ 1 และขั้นตอนที่ 3 ก็ไม่จำเป็นต้อง
ยืนยันโทเค็นเพื่อการเข้าถึง |
|
azp |
client_id ของผู้นำเสนอที่ได้รับอนุญาต การอ้างสิทธิ์นี้จำเป็นเฉพาะในกรณีที่
ฝ่ายที่ขอโทเค็นรหัสไม่ใช่กลุ่มเป้าหมายของโทเค็นรหัส กรณีนี้อาจเกิดขึ้นที่ Google สำหรับแอปแบบไฮบริดที่เว็บแอปพลิเคชันและแอป Android มี client_id OAuth 2.0 ที่แตกต่างกัน แต่ใช้โปรเจ็กต์ Google APIs เดียวกัน |
|
email |
อีเมลของผู้ใช้ ระบุเฉพาะในกรณีที่คุณรวมขอบเขต email ไว้ใน
คำขอ ค่าของการอ้างสิทธิ์นี้อาจไม่ซ้ำกันสำหรับบัญชีนี้และอาจเปลี่ยนแปลง
เมื่อเวลาผ่านไป ดังนั้นคุณจึงไม่ควรใช้ค่านี้เป็นตัวระบุหลักเพื่อลิงก์กับ
บันทึกผู้ใช้ นอกจากนี้ คุณยังไม่สามารถใช้โดเมนของemailอ้างสิทธิ์เพื่อ
ระบุผู้ใช้ Google Workspace หรือองค์กร Cloud ได้ แต่ให้ใช้hdอ้างสิทธิ์
แทน
|
|
email_verified |
จริง หากยืนยันอีเมลของผู้ใช้แล้ว หรือเท็จ | |
family_name |
นามสกุลของผู้ใช้ อาจระบุเมื่อมีคำกล่าวอ้าง
name |
|
given_name |
ชื่อต้นของผู้ใช้ อาจระบุเมื่อมีคำกล่าวอ้าง
name |
|
hd |
โดเมนที่เชื่อมโยงกับองค์กร Google Workspace หรือ Cloud ของผู้ใช้ ระบุในกรณีที่ผู้ใช้เป็นสมาชิกขององค์กร Google Cloud เท่านั้น คุณต้องตรวจสอบการอ้างสิทธิ์นี้ เมื่อจำกัดการเข้าถึงทรัพยากรไว้เฉพาะสมาชิกของโดเมนบางโดเมน การไม่มีการอ้างสิทธิ์นี้แสดงว่าบัญชีไม่ได้เป็นของโดเมนที่ Google โฮสต์ | |
locale |
ภาษาของผู้ใช้ ซึ่งแสดงด้วยแท็กภาษา BCP 47
อาจระบุเมื่อมีคำกล่าวอ้าง name
อยู่ |
|
name |
ชื่อและนามสกุลของผู้ใช้ในรูปแบบที่แสดงได้ อาจระบุเมื่อ
เมื่อมีคำกล่าวอ้าง |
|
nonce |
ค่าของ nonce ที่แอปของคุณระบุในคำขอการตรวจสอบสิทธิ์
คุณควรป้องกันการโจมตีแบบเล่นซ้ำโดยแสดงค่านี้เพียงครั้งเดียว |
|
picture |
URL ของรูปโปรไฟล์ของผู้ใช้ อาจระบุเมื่อ
เมื่อมีข้ออ้างสิทธิ์ |
|
profile |
URL ของหน้าโปรไฟล์ผู้ใช้ อาจระบุเมื่อ
เมื่อมีข้ออ้างสิทธิ์ |
6. ตรวจสอบสิทธิ์ผู้ใช้
หลังจากได้รับข้อมูลผู้ใช้จากโทเค็นรหัสแล้ว คุณควรค้นหาฐานข้อมูลผู้ใช้ของแอป หากผู้ใช้มีอยู่ในฐานข้อมูลแล้ว คุณควรเริ่มเซสชันแอปพลิเคชันสำหรับผู้ใช้รายนั้น หากการตอบกลับจาก Google API เป็นไปตามข้อกำหนดในการเข้าสู่ระบบทั้งหมด
หากไม่มีผู้ใช้ในฐานข้อมูลผู้ใช้ คุณควรเปลี่ยนเส้นทางผู้ใช้ไปยังขั้นตอนการลงชื่อสมัครใช้สำหรับผู้ใช้ใหม่ คุณอาจลงทะเบียนผู้ใช้โดยอัตโนมัติตามข้อมูลที่ได้รับจาก Google หรืออย่างน้อยที่สุด คุณอาจป้อนข้อมูลล่วงหน้าในช่องหลายช่องที่คุณต้องการในแบบฟอร์มลงทะเบียน นอกจากข้อมูลในโทเค็นรหัสแล้ว คุณยังดูข้อมูลโปรไฟล์ผู้ใช้เพิ่มเติมได้ที่ ปลายทางโปรไฟล์ผู้ใช้
หัวข้อขั้นสูง
ส่วนต่อไปนี้จะอธิบาย Google OAuth 2.0 API โดยละเอียด ข้อมูลนี้มีไว้สำหรับนักพัฒนาแอปที่มีข้อกำหนดขั้นสูงเกี่ยวกับการตรวจสอบสิทธิ์และการให้สิทธิ์
การเข้าถึง Google API อื่นๆ
ข้อดีอย่างหนึ่งของการใช้ OAuth 2.0 สำหรับการตรวจสอบสิทธิ์คือแอปพลิเคชันของคุณจะได้รับสิทธิ์ในการใช้ Google API อื่นๆ ในนามของผู้ใช้ (เช่น YouTube, Google ไดรฟ์, ปฏิทิน หรือรายชื่อติดต่อ) พร้อมๆ กับการตรวจสอบสิทธิ์ผู้ใช้ โดยให้ระบุ
ขอบเขตอื่นๆ ที่คุณต้องการในคำขอการตรวจสอบสิทธิ์ที่คุณ
ส่งไปยัง Google เช่น หากต้องการเพิ่มกลุ่มอายุของผู้ใช้ในคำขอการตรวจสอบสิทธิ์ ให้ส่งพารามิเตอร์ขอบเขตของ
openid email https://www.googleapis.com/auth/profile.agerange.read ระบบจะแจ้งให้ผู้ใช้ทราบอย่างเหมาะสมในหน้าจอคำยินยอม โทเค็นเพื่อการเข้าถึง
ที่คุณได้รับจาก Google จะช่วยให้แอปพลิเคชันเข้าถึง API ทั้งหมดที่เกี่ยวข้องกับ
ขอบเขตการเข้าถึงที่คุณขอและได้รับสิทธิ์
โทเค็นการรีเฟรช
ในคำขอสิทธิ์เข้าถึง API คุณสามารถขอให้ระบบส่งโทเค็นการรีเฟรชกลับมาในระหว่างcodeการแลกเปลี่ยน โทเค็นการรีเฟรชช่วยให้แอปของคุณ
เข้าถึง Google API ได้อย่างต่อเนื่องในขณะที่ผู้ใช้ไม่ได้อยู่ในแอปพลิเคชัน หากต้องการขอ
โทเค็นการรีเฟรช ให้เพิ่มพารามิเตอร์
access_type เป็น offline ใน
คำขอการตรวจสอบสิทธิ์
ข้อควรพิจารณา
- โปรดเก็บโทเค็นการรีเฟรชอย่างปลอดภัยและถาวร เนื่องจากคุณจะรับโทเค็นการรีเฟรชได้เป็นครั้งแรกเท่านั้นเมื่อทำตามขั้นตอนการแลกรหัส
- โดยมีการจำกัดจำนวนโทเค็นการรีเฟรชที่ออกให้ ดังนี้ การจำกัด 1 รายการต่อชุดค่าผสมไคลเอ็นต์/ผู้ใช้ และอีก 1 รายการต่อผู้ใช้ในไคลเอ็นต์ทั้งหมด หากแอปพลิเคชันขอโทเค็นการรีเฟรชมากเกินไป แอปพลิเคชันอาจเกินขีดจำกัดเหล่านี้ ในกรณีนี้ โทเค็นการรีเฟรชที่เก่ากว่าจะหยุด ทำงาน
ดูข้อมูลเพิ่มเติมได้ที่ การรีเฟรชโทเค็นเพื่อการเข้าถึง (การเข้าถึงแบบออฟไลน์)
การแจ้งให้ขอความยินยอมอีกครั้ง
คุณสามารถแจ้งให้ผู้ใช้ให้สิทธิ์แอปอีกครั้งได้โดยตั้งค่าพารามิเตอร์
prompt เป็น consent ใน
คำขอการตรวจสอบสิทธิ์ เมื่อระบุ prompt=consent หน้าจอขอความยินยอมจะแสดงทุกครั้งที่แอปขอสิทธิ์เข้าถึงขอบเขต
แม้ว่าก่อนหน้านี้โปรเจ็กต์ Google APIs จะได้รับสิทธิ์เข้าถึงขอบเขตทั้งหมดแล้วก็ตาม ด้วยเหตุนี้
จึงควรใส่ prompt=consent เมื่อจำเป็นเท่านั้น
ดูข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์ prompt ได้ที่ prompt
ในตารางพารามิเตอร์ URI การตรวจสอบสิทธิ์
พารามิเตอร์ URI การตรวจสอบสิทธิ์
ตารางต่อไปนี้อธิบายพารามิเตอร์ที่ API การตรวจสอบสิทธิ์ OAuth 2.0 ของ Google ยอมรับอย่างละเอียดมากขึ้น
| พารามิเตอร์ | ต้องระบุ | คำอธิบาย |
|---|---|---|
client_id |
(จำเป็น) | สตริงรหัสไคลเอ็นต์ที่คุณได้รับจาก ตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0 |
nonce |
(จำเป็น) | ค่าแบบสุ่มที่แอปสร้างขึ้นซึ่งช่วยให้การป้องกันการเล่นซ้ำ |
response_type |
(จำเป็น) | หากค่าเป็น code จะเปิดใช้
ขั้นตอนการใช้รหัสการให้สิทธิ์พื้นฐาน
ซึ่งต้องใช้ POST ไปยังปลายทางโทเค็นเพื่อรับโทเค็น หากค่าเป็น token id_token หรือ id_token token จะเปิดใช้โฟลว์โดยนัย ซึ่งต้องใช้ JavaScript ที่ URI การเปลี่ยนเส้นทางเพื่อดึงโทเค็นจากตัวระบุ URI #fragment |
redirect_uri |
(จำเป็น) | กำหนดตำแหน่งที่จะส่งคำตอบ ค่าของพารามิเตอร์นี้ต้องตรงกับค่าการเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าใดค่าหนึ่งที่คุณตั้งค่าไว้ใน (รวมถึงรูปแบบ HTTP หรือ HTTPS, ตัวพิมพ์เล็ก-ใหญ่ และ '/' ต่อท้าย หากมี) |
scope |
(จำเป็น) | พารามิเตอร์ขอบเขตต้องเริ่มต้นด้วยค่า หากมีค่าขอบเขต หากมีค่าขอบเขต นอกจากขอบเขตที่เจาะจง OpenID เหล่านี้แล้ว อาร์กิวเมนต์ขอบเขตยังรวมค่าขอบเขตอื่นๆ ได้ด้วย
ค่าขอบเขตทั้งหมดต้องคั่นด้วยช่องว่าง เช่น หากต้องการ
สิทธิ์เข้าถึงต่อไฟล์ใน Google ไดรฟ์ของผู้ใช้ พารามิเตอร์ขอบเขตอาจเป็น
ดูข้อมูลเกี่ยวกับขอบเขตที่ใช้ได้ที่ ขอบเขต OAuth 2.0 สำหรับ Google APIs หรือ เอกสารประกอบสำหรับ Google API ที่คุณต้องการใช้ |
state |
(ไม่บังคับ แต่ขอแนะนำอย่างยิ่ง) | สตริงทึบแสงที่ส่งกลับในโปรโตคอล กล่าวคือ สตริงนี้จะ
แสดงเป็นพารามิเตอร์ URI ในโฟลว์พื้นฐาน และในตัวระบุ URI
|
access_type |
(ไม่บังคับ) | ค่าที่อนุญาตคือ offline และ online ผลลัพธ์จะ
ระบุไว้ใน
การเข้าถึงแบบออฟไลน์ หากมีการขอโทเค็นเพื่อเข้าถึง
ไคลเอ็นต์จะไม่ได้รับโทเค็นการรีเฟรช เว้นแต่จะระบุค่า offline |
display |
(ไม่บังคับ) | ค่าสตริง ASCII สำหรับระบุวิธีที่เซิร์ฟเวอร์การให้สิทธิ์แสดงหน้าอินเทอร์เฟซผู้ใช้สำหรับการตรวจสอบสิทธิ์และความยินยอม
ค่าต่อไปนี้จะได้รับการระบุและ
ยอมรับโดยเซิร์ฟเวอร์ของ Google แต่จะไม่มีผลต่อลักษณะการทำงานของโฟลว์โปรโตคอล
page, popup, touch และ wap |
hd |
(ไม่บังคับ) | เพิ่มประสิทธิภาพกระบวนการเข้าสู่ระบบสำหรับบัญชีที่เป็นขององค์กร Google Cloud การระบุโดเมนขององค์กร Google Cloud (เช่น mycollege.edu) จะช่วยให้คุณระบุได้ว่าควรเพิ่มประสิทธิภาพ UI การเลือกบัญชีสำหรับบัญชีในโดเมนนั้น หากต้องการเพิ่มประสิทธิภาพสำหรับบัญชีองค์กร Google Cloud โดยทั่วไปแทนที่จะเป็นโดเมนองค์กร Google Cloud เพียงโดเมนเดียว ให้ตั้งค่าเป็นเครื่องหมายดอกจัน ( อย่าใช้การเพิ่มประสิทธิภาพ UI นี้เพื่อควบคุมผู้ที่เข้าถึงแอปได้ เนื่องจากคำขอฝั่งไคลเอ็นต์
อาจได้รับการแก้ไข อย่าลืมตรวจสอบว่า
โทเค็นรหัสที่ส่งคืนมีค่าการอ้างสิทธิ์ |
include_granted_scopes |
(ไม่บังคับ) | หากระบุพารามิเตอร์นี้ด้วยค่า true และได้รับคำขอให้สิทธิ์
การให้สิทธิ์จะรวมการให้สิทธิ์ก่อนหน้านี้ที่ให้แก่ชุดค่าผสมผู้ใช้/แอปพลิเคชันนี้สำหรับขอบเขตอื่นๆ ด้วย โปรดดูการให้สิทธิ์แบบเพิ่มทีละรายการ
โปรดทราบว่าคุณไม่สามารถทำการให้สิทธิ์แบบเพิ่มทีละรายการด้วยโฟลว์แอปที่ติดตั้ง |
login_hint |
(ไม่บังคับ) | เมื่อแอปทราบว่าผู้ใช้รายใดที่พยายามตรวจสอบสิทธิ์ แอปจะระบุพารามิเตอร์นี้เป็นคำแนะนำไปยังเซิร์ฟเวอร์การตรวจสอบสิทธิ์ได้
การส่งคำใบ้นี้จะระงับตัวเลือกบัญชี และจะกรอกข้อมูลล่วงหน้าในช่องอีเมลในแบบฟอร์มลงชื่อเข้าใช้ หรือเลือกเซสชันที่เหมาะสม (หากผู้ใช้ใช้การลงชื่อเข้าใช้หลายรายการ)
ซึ่งจะช่วยให้คุณหลีกเลี่ยงปัญหาที่เกิดขึ้นหากแอปของคุณเข้าสู่ระบบบัญชีผู้ใช้ที่ไม่ถูกต้อง
ค่าอาจเป็นอีเมลหรือสตริง sub ซึ่งเทียบเท่ากับรหัส Google ของผู้ใช้
|
prompt |
(ไม่บังคับ) | รายการค่าสตริงที่คั่นด้วยช่องว่างซึ่งระบุว่าเซิร์ฟเวอร์การให้สิทธิ์
จะแจ้งให้ผู้ใช้ตรวจสอบสิทธิ์และให้ความยินยอมอีกครั้งหรือไม่ โดยค่าที่เลือกได้มีดังนี้
หากไม่ได้ระบุค่าไว้และผู้ใช้ไม่เคยให้สิทธิ์เข้าถึงมาก่อน ระบบจะแสดงหน้าจอขอความยินยอมต่อผู้ใช้ |
การตรวจสอบโทเค็นรหัส
คุณต้องตรวจสอบโทเค็นรหัสทั้งหมดในเซิร์ฟเวอร์ เว้นแต่จะทราบว่าโทเค็นดังกล่าวมาจาก Google โดยตรง ตัวอย่างเช่น เซิร์ฟเวอร์ต้องยืนยันว่าโทเค็นรหัสที่ได้รับจากแอปไคลเอ็นต์ของคุณเป็นของแท้
สถานการณ์ที่พบบ่อยซึ่งคุณอาจส่งโทเค็นรหัสไปยังเซิร์ฟเวอร์มีดังนี้
- ส่งโทเค็นรหัสพร้อมคำขอที่ต้องมีการตรวจสอบสิทธิ์ โทเค็นรหัสจะบอกคุณเกี่ยวกับ ผู้ใช้ที่เฉพาะเจาะจงซึ่งส่งคำขอและไคลเอ็นต์ที่ได้รับโทเค็นรหัสนั้น
โทเค็นรหัสมีความละเอียดอ่อนและอาจถูกนำไปใช้ในทางที่ผิดหากถูกดัก คุณต้องตรวจสอบว่าโทเค็นเหล่านี้ ได้รับการจัดการอย่างปลอดภัยโดยการส่งผ่าน HTTPS เท่านั้น และใช้ข้อมูล POST หรือภายใน ส่วนหัวของคำขอเท่านั้น หากจัดเก็บโทเค็นรหัสในเซิร์ฟเวอร์ คุณก็ต้องจัดเก็บอย่างปลอดภัยด้วย
สิ่งหนึ่งที่ทำให้โทเค็นรหัสมีประโยชน์คือคุณสามารถส่งโทเค็นไปยังคอมโพเนนต์ต่างๆ ของแอปได้ คอมโพเนนต์เหล่านี้สามารถใช้โทเค็นรหัสเป็นกลไกการตรวจสอบสิทธิ์ที่มีน้ำหนักเบา ซึ่งจะตรวจสอบสิทธิ์แอปและผู้ใช้ แต่ก่อนที่จะใช้ข้อมูลในโทเค็น ID หรือใช้เป็นข้อความยืนยันว่าผู้ใช้ได้ตรวจสอบสิทธิ์แล้ว คุณต้องตรวจสอบความถูกต้องของโทเค็น
การตรวจสอบโทเค็นรหัสต้องมีหลายขั้นตอน ดังนี้
- ตรวจสอบว่าโทเค็นรหัสได้รับการลงนามอย่างถูกต้องจากผู้ออก โทเค็นที่ Google ออกให้จะได้รับการลงนาม
โดยใช้ใบรับรองรายการใดรายการหนึ่งที่พบใน URI ที่ระบุในค่า
jwks_uriข้อมูลเมตา ของเอกสารการค้นพบ - ยืนยันว่าค่าของการอ้างสิทธิ์
issในโทเค็นรหัสเท่ากับhttps://accounts.google.comหรือaccounts.google.com - ยืนยันว่าค่าของ
audการอ้างสิทธิ์ในโทเค็นรหัสเท่ากับรหัสไคลเอ็นต์ของแอป - ตรวจสอบว่าเวลาหมดอายุ (อ้างสิทธิ์
exp) ของโทเค็นรหัสยังไม่หมดอายุ - หากคุณระบุค่าพารามิเตอร์ hd ในคำขอ ให้ตรวจสอบว่าโทเค็น
รหัสมีอ้างสิทธิ์
hdที่ตรงกับโดเมนที่ยอมรับซึ่งเชื่อมโยงกับองค์กร Google Cloud
ขั้นตอนที่ 2-5 เกี่ยวข้องกับการเปรียบเทียบสตริงและวันที่เท่านั้น ซึ่งค่อนข้างตรงไปตรงมา ดังนั้นเราจึงจะไม่แสดงรายละเอียดไว้ที่นี่
ขั้นตอนแรกมีความซับซ้อนกว่าและเกี่ยวข้องกับการตรวจสอบลายเซ็นการเข้ารหัส คุณสามารถใช้ปลายทาง tokeninfo ของ Google เพื่อเปรียบเทียบกับ
การประมวลผลในเครื่องที่ติดตั้งใช้งานในเซิร์ฟเวอร์หรืออุปกรณ์เพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่อง สมมติว่าค่าของโทเค็นรหัสคือ
XYZ123 จากนั้นคุณจะยกเลิกการอ้างอิง URI
https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123 หากลายเซ็นโทเค็น
ถูกต้อง การตอบกลับจะเป็นเพย์โหลด JWT ในรูปแบบออบเจ็กต์ JSON ที่ถอดรหัสแล้ว
tokeninfo ปลายทางมีประโยชน์สำหรับการแก้ไขข้อบกพร่อง แต่สำหรับการใช้งานจริง ให้เรียกคีย์สาธารณะของ Google จากปลายทางคีย์และทำการตรวจสอบในเครื่อง คุณควรกู้ URI ของคีย์จากเอกสารการค้นหา
โดยใช้ค่าข้อมูลเมตา jwks_uri คำขอไปยังปลายทางการแก้ไขข้อบกพร่องอาจถูก
จำกัดอัตราหรืออาจเกิดข้อผิดพลาดเป็นระยะๆ
เนื่องจาก Google เปลี่ยนคีย์สาธารณะไม่บ่อยนัก คุณจึงแคชคีย์เหล่านั้นได้โดยใช้คำสั่งแคชของการตอบสนอง HTTP และในกรณีส่วนใหญ่ การตรวจสอบในเครื่องจะมีประสิทธิภาพมากกว่าการใช้ปลายทาง tokeninfo มาก การตรวจสอบนี้
ต้องดึงและแยกวิเคราะห์ใบรับรอง รวมถึงทำการเรียกใช้การเข้ารหัสที่เหมาะสมเพื่อ
ตรวจสอบลายเซ็น โชคดีที่มีไลบรารีที่ผ่านการแก้ไขข้อบกพร่องมาเป็นอย่างดีในภาษาต่างๆ มากมาย
เพื่อช่วยให้คุณทำสิ่งนี้ได้ (ดู jwt.io)
การขอข้อมูลโปรไฟล์ผู้ใช้
หากต้องการรับข้อมูลโปรไฟล์เพิ่มเติมเกี่ยวกับผู้ใช้ คุณสามารถใช้โทเค็นการเข้าถึง (ซึ่งแอปพลิเคชันของคุณจะได้รับในระหว่างขั้นตอนการตรวจสอบสิทธิ์) และมาตรฐาน OpenID Connect ได้โดยทำดังนี้
หากต้องการให้เป็นไปตามข้อกำหนดของ OpenID คุณต้องระบุค่า
openid profileขอบเขตในคำขอการตรวจสอบสิทธิ์หากต้องการรวมอีเมลของผู้ใช้ ให้ระบุค่าขอบเขตเพิ่มเติมเป็น
emailหากต้องการระบุทั้งprofileและemailคุณสามารถใส่พารามิเตอร์ต่อไปนี้ ใน URI คำขอการตรวจสอบสิทธิ์scope=openid%20profile%20email
- เพิ่มโทเค็นเพื่อการเข้าถึงลงในส่วนหัวการให้สิทธิ์และส่ง
GETคำขอ HTTPS ไปยังปลายทาง userinfo ซึ่งคุณควรดึงข้อมูลจากเอกสารการค้นพบโดยใช้ค่าuserinfo_endpointข้อมูลเมตา การตอบกลับ userinfo จะมีข้อมูลเกี่ยวกับผู้ใช้ตามที่อธิบายไว้ในOpenID Connect Standard Claimsและค่าข้อมูลเมตาclaims_supportedของเอกสารการค้นพบ ผู้ใช้หรือองค์กรของผู้ใช้อาจเลือกที่จะระบุหรือไม่ระบุบางช่อง ดังนั้นคุณอาจไม่ได้รับข้อมูลในทุกช่องสำหรับขอบเขตการเข้าถึงที่ได้รับอนุญาต
เอกสารการค้นพบ
โปรโตคอล OpenID Connect กำหนดให้ใช้ปลายทางหลายรายการเพื่อตรวจสอบสิทธิ์ผู้ใช้ และเพื่อขอทรัพยากรต่างๆ รวมถึงโทเค็น ข้อมูลผู้ใช้ และคีย์สาธารณะ
OpenID Connect อนุญาตให้ใช้ "เอกสารการค้นหา" ซึ่งเป็นเอกสาร JSON ที่อยู่ในตำแหน่งที่รู้จักกันดีซึ่งมีคู่คีย์-ค่า ซึ่งให้รายละเอียดเกี่ยวกับการกำหนดค่าของผู้ให้บริการ OpenID Connect รวมถึง URI ของ ปลายทางการให้สิทธิ์ โทเค็น การเพิกถอน userinfo และคีย์สาธารณะ เพื่อให้การติดตั้งใช้งานง่ายขึ้นและมีความยืดหยุ่นมากขึ้น คุณสามารถดึงข้อมูลเอกสารการค้นพบสำหรับบริการ OpenID Connect ของ Google ได้จาก
https://accounts.google.com/.well-known/openid-configuration
หากต้องการใช้บริการ OpenID Connect ของ Google คุณควรฮาร์ดโค้ด URI ของเอกสารการค้นหา
(https://accounts.google.com/.well-known/openid-configuration) ลงในแอปพลิเคชัน
แอปพลิเคชันจะดึงข้อมูลเอกสาร ใช้กฎการแคชในการตอบกลับ แล้วดึงข้อมูล URI ของปลายทางจากเอกสารตามต้องการ
เช่น หากต้องการตรวจสอบสิทธิ์ผู้ใช้ โค้ดของคุณจะเรียกค่าข้อมูลเมตา
authorization_endpoint
(https://accounts.google.com/o/oauth2/v2/auth ในตัวอย่างด้านล่าง)
เป็น URI ฐานสำหรับคำขอการตรวจสอบสิทธิ์ที่ส่งไปยัง Google
ตัวอย่างเอกสารดังกล่าวมีดังนี้ โดยชื่อฟิลด์คือชื่อที่ระบุไว้ใน OpenID Connect Discovery 1.0 (โปรดดูความหมายของชื่อฟิลด์ในเอกสารดังกล่าว) ค่าต่างๆ เป็นเพียงภาพประกอบและอาจเปลี่ยนแปลงได้ แม้ว่าจะคัดลอกมาจากเอกสาร Google Discovery เวอร์ชันล่าสุด ก็ตาม
{ "issuer": "https://accounts.google.com", "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth", "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code", "token_endpoint": "https://oauth2.googleapis.com/token", "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo", "revocation_endpoint": "https://oauth2.googleapis.com/revoke", "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs", "response_types_supported": [ "code", "token", "id_token", "code token", "code id_token", "token id_token", "code token id_token", "none" ], "subject_types_supported": [ "public" ], "id_token_signing_alg_values_supported": [ "RS256" ], "scopes_supported": [ "openid", "email", "profile" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "claims_supported": [ "aud", "email", "email_verified", "exp", "family_name", "given_name", "iat", "iss", "locale", "name", "picture", "sub" ], "code_challenge_methods_supported": [ "plain", "S256" ] }
คุณอาจหลีกเลี่ยงการรับส่ง HTTP ได้โดยการแคชค่าจากเอกสารการค้นหา ระบบจะใช้ส่วนหัวการแคช HTTP มาตรฐานและควรปฏิบัติตาม
ไลบรารีของไคลเอ็นต์
ไลบรารีของไคลเอ็นต์ต่อไปนี้ช่วยให้การติดตั้งใช้งาน OAuth 2.0 ง่ายขึ้นด้วยการผสานรวมกับเฟรมเวิร์กยอดนิยม
- ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ Java
- ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ Python
- ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ .NET
- ไลบรารีของไคลเอ็นต์ Google API สำหรับ Ruby
- ไลบรารีของไคลเอ็นต์ Google APIs สำหรับ PHP
- ไลบรารี OAuth 2.0 สำหรับ Google Web Toolkit
- ตัวควบคุม OAuth 2.0 ของกล่องเครื่องมือของ Google สำหรับ Mac
การปฏิบัติตามข้อกำหนดของ OpenID Connect
ระบบการตรวจสอบสิทธิ์ OAuth 2.0 ของ Google รองรับฟีเจอร์ที่จำเป็นของข้อกำหนด OpenID Connect Core ไคลเอ็นต์ใดก็ตามที่ออกแบบมาให้ทำงานกับ OpenID Connect ควรทำงานร่วมกับบริการนี้ได้ (ยกเว้น ออบเจ็กต์คำขอ OpenID)