API ของ OAuth 2.0 ของ Google สามารถใช้ได้กับทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์ เอกสารนี้อธิบายการใช้ OAuth 2.0 เพื่อการตรวจสอบสิทธิ์ ซึ่งเป็นไปตามข้อกําหนด OpenID Connect และได้ใบรับรอง OpenID เอกสารที่พบในการใช้ OAuth 2.0 เพื่อเข้าถึง Google API จะมีผลกับบริการนี้ด้วย หากต้องการสํารวจโปรโตคอลนี้แบบอินเทอร์แอกทีฟ ขอแนะนําให้ใช้ Google OAuth 2.0 Playground หากต้องการความช่วยเหลือเกี่ยวกับ Stack Overflow ให้ติดแท็กคําถามของคุณด้วย 'google-oauth'
การตั้งค่า OAuth 2.0
ก่อนที่แอปพลิเคชันจะใช้ระบบการตรวจสอบสิทธิ์ OAuth 2.0 ของ Google ในการเข้าสู่ระบบของผู้ใช้ได้ คุณต้องตั้งค่าโปรเจ็กต์ใน Google API Console เพื่อรับข้อมูลเข้าสู่ระบบ OAuth 2.0 ตั้งค่า URI การเปลี่ยนเส้นทาง และ (ไม่บังคับ) ปรับแต่งข้อมูลการสร้างแบรนด์ที่ผู้ใช้เห็นบนหน้าจอคํายินยอมของผู้ใช้ คุณยังใช้ API Console เพื่อสร้างบัญชีบริการ เปิดใช้การเรียกเก็บเงิน ตั้งค่า การกรอง และทํางานอื่นๆ ได้ด้วย ดูรายละเอียดเพิ่มเติมได้ที่ความช่วยเหลือของGoogle API Console
รับข้อมูลเข้าสู่ระบบ OAuth 2.0
คุณต้องมีข้อมูลเข้าสู่ระบบ OAuth 2.0 รวมถึงรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์เพื่อตรวจสอบสิทธิ์ผู้ใช้และรับสิทธิ์เข้าถึง API ของ Google
ในการดูรหัสลูกค้าและข้อมูลลับของลูกค้าสำหรับข้อมูลรับรอง OAuth 2.0 ที่กำหนดให้คลิกข้อความต่อไปนี้: เลือกข้อมูลรับรอง ในหน้าต่างที่เปิดขึ้นให้เลือกโครงการและข้อมูลรับรองที่คุณต้องการจากนั้นคลิก ดู
หรือดูรหัสลูกค้าและข้อมูลลับลูกค้าของคุณจาก หน้าข้อมูลรับรอง ใน API Console :
- Go to the Credentials page.
- คลิกที่ชื่อหนังสือรับรองของคุณหรือไอคอนดินสอ ( create ) รหัสลูกค้าและความลับของคุณอยู่ที่ด้านบนของหน้า
ตั้งค่า URI การเปลี่ยนเส้นทาง
URI การเปลี่ยนเส้นทางที่คุณตั้งค่าไว้ใน API Console กําหนดที่ Google จะส่งการตอบกลับไปยังคําขอการตรวจสอบสิทธิ์ของคุณ
ในการสร้างดูหรือแก้ไข URIs การเปลี่ยนเส้นทางสำหรับข้อมูลรับรอง OAuth 2.0 ที่ระบุให้ทำดังต่อไปนี้:
- Go to the Credentials page.
- ในส่วน รหัสลูกค้า OAuth 2.0 ของหน้าคลิกข้อมูลรับรอง
- ดูหรือแก้ไข URIs การเปลี่ยนเส้นทาง
หากไม่มีส่วน รหัสลูกค้า OAuth 2.0 ในหน้าหนังสือรับรองแสดงว่าโครงการของคุณไม่มีข้อมูลรับรอง OAuth หากต้องการสร้างหนึ่งคลิก สร้างข้อมูลรับรอง
ปรับแต่งหน้าจอคํายินยอมของผู้ใช้
สําหรับผู้ใช้ ประสบการณ์การตรวจสอบสิทธิ์ OAuth 2.0 จะมีหน้าจอคํายินยอมที่อธิบายข้อมูลที่ผู้ใช้เผยแพร่และข้อกําหนดที่มีผลบังคับใช้ เช่น เมื่อผู้ใช้ลงชื่อเข้าสู่ระบบ ระบบอาจขอให้แอปเข้าถึงอีเมลและข้อมูลบัญชีเบื้องต้น คุณขอสิทธิ์เข้าถึงข้อมูลนี้โดยใช้พารามิเตอร์ scope
ซึ่งแอปมีอยู่ในคําขอการตรวจสอบสิทธิ์ของแอป คุณยังใช้ขอบเขตเพื่อขอสิทธิ์เข้าถึง Google API อื่นๆ ได้ด้วย
หน้าจอขอความยินยอมของผู้ใช้จะแสดงข้อมูลแบรนด์ เช่น ชื่อผลิตภัณฑ์ โลโก้ และ URL ของหน้าแรกด้วย คุณสามารถควบคุมข้อมูลการสร้างแบรนด์ได้ใน API Console
วิธีเปิดใช้งานหน้าจอการยินยอมของโครงการ:
- เปิด Consent Screen page ใน Google API Console
- If prompted, select a project, or create a new one.
- กรอกแบบฟอร์มและคลิก บันทึก
กล่องโต้ตอบคํายินยอมต่อไปนี้จะแสดงสิ่งที่ผู้ใช้จะเห็นเมื่อมีชุดค่าผสมของขอบเขต OAuth 2.0 และ Google ไดรฟ์ในคําขอ (กล่องโต้ตอบทั่วไปนี้สร้างขึ้นโดยใช้ Google OAuth 2.0 Playground จึงไม่รวมข้อมูลการสร้างแบรนด์ที่ระบบจะตั้งค่าใน API Console)

การเข้าถึงบริการ
Google และบุคคลที่สามให้บริการไลบรารีที่คุณใช้ดูแลรายละเอียดการใช้งานมากมายของการตรวจสอบสิทธิ์ผู้ใช้และรับสิทธิ์เข้าถึง Google API ได้ เช่น บริการข้อมูลประจําตัวของ Google และไลบรารีของไคลเอ็นต์ Google ซึ่งใช้ได้กับแพลตฟอร์มที่หลากหลาย
หากคุณเลือกที่จะไม่ใช้ไลบรารี ให้ทําตามวิธีการในส่วนที่เหลือของเอกสารนี้ ซึ่งจะอธิบายถึงโฟลว์คําขอ HTTP ที่ไลบรารีที่พร้อมใช้งาน
การตรวจสอบสิทธิ์ผู้ใช้
การตรวจสอบสิทธิ์ผู้ใช้เกี่ยวข้องกับการรับโทเค็นรหัสและตรวจสอบความถูกต้อง โทเค็นรหัสเป็นฟีเจอร์มาตรฐานของ OpenID Connect ซึ่งออกแบบมาเพื่อใช้ในการยืนยันตัวตนในอินเทอร์เน็ต
วิธีที่ใช้กันโดยทั่วไปสําหรับการตรวจสอบสิทธิ์ผู้ใช้และการรับโทเค็นรหัสเรียกว่าโฟลว์ "server" และโฟลว์ "implicit" โฟลว์เซิร์ฟเวอร์ช่วยให้เซิร์ฟเวอร์แบ็กเอนด์ของแอปพลิเคชันสามารถยืนยันตัวตนของผู้ที่ใช้เบราว์เซอร์หรืออุปกรณ์เคลื่อนที่ได้ โฟลว์แบบไม่เจาะจงปลายทางจะใช้เมื่อแอปพลิเคชันฝั่งไคลเอ็นต์ (โดยทั่วไปคือแอป JavaScript ที่ทํางานในเบราว์เซอร์) ต้องเข้าถึง API โดยตรงแทนการเข้าถึงผ่านเซิร์ฟเวอร์แบ็กเอนด์
เอกสารนี้อธิบายวิธีดําเนินการโฟลว์เซิร์ฟเวอร์สําหรับการตรวจสอบสิทธิ์ผู้ใช้ โฟลว์แบบไม่เจาะจงปลายทางมีความซับซ้อนมากขึ้นอย่างมาก เนื่องจากมีความเสี่ยงด้านความปลอดภัยในการจัดการและใช้โทเค็นในฝั่งไคลเอ็นต์ หากต้องการใช้ขั้นตอนแบบไม่เจาะจง เราขอแนะนําให้ใช้บริการ Google Identity
โฟลว์เซิร์ฟเวอร์
อย่าลืมตั้งค่าแอปใน API Console เพื่อให้แอปใช้โปรโตคอลเหล่านี้และตรวจสอบสิทธิ์ผู้ใช้ได้ เมื่อผู้ใช้พยายามลงชื่อเข้าสู่ระบบด้วย Google คุณต้องดําเนินการดังนี้
- สร้างโทเค็นสถานะการป้องกันการปลอมแปลง
- ส่งคําขอตรวจสอบสิทธิ์ไปยัง Google
- ยืนยันโทเค็นการป้องกันสถานะการปลอมแปลง
- Exchange
code
สําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส - รับข้อมูลผู้ใช้จากโทเค็นรหัส
- ตรวจสอบสิทธิ์ผู้ใช้
1. สร้างโทเค็นสถานะต่อต้านการปลอมแปลง
คุณต้องปกป้องความปลอดภัยของผู้ใช้โดยการป้องกันการโจมตีแบบขอปลอมแปลง ขั้นตอนแรกคือการสร้างโทเค็นเซสชันที่ไม่ซ้ํากันที่รักษาสถานะระหว่างแอปกับไคลเอ็นต์ของผู้ใช้ จากนั้นคุณจับคู่โทเค็นเซสชันที่ไม่ซ้ํานี้กับการตอบสนองการตรวจสอบสิทธิ์ที่บริการการเข้าสู่ระบบ Google OAuth แสดงผลเพื่อยืนยันว่าผู้ใช้ส่งคําขอ ไม่ใช่ผู้โจมตีที่เป็นอันตราย โทเค็นเหล่านี้มักเรียกว่าโทเค็นคําขอข้ามเว็บไซต์ (CSRF)
ตัวเลือกที่ดีประการหนึ่งสําหรับโทเค็นสถานะคือสตริงอักขระ 30 ตัวขึ้นไปที่สร้างขึ้นโดยใช้โปรแกรมสร้างตัวเลขสุ่มคุณภาพสูง อีกตัวแปรหนึ่งคือแฮชที่สร้างขึ้นโดยการลงนามตัวแปรสถานะเซสชันบางรายการด้วยคีย์ที่มีจะเก็บเป็นความลับที่แบ็กเอนด์
โค้ดต่อไปนี้แสดงการสร้างโทเค็นของเซสชันที่ไม่ซ้ํา
PHP
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สําหรับ PHP เพื่อใช้ตัวอย่างนี้
// Create a state token to prevent request forgery. // Store it in the session for later validation. $state = bin2hex(random_bytes(128/8)); $app['session']->set('state', $state); // Set the client ID, token state, and application name in the HTML while // serving it. return $app['twig']->render('index.html', array( 'CLIENT_ID' => CLIENT_ID, 'STATE' => $state, 'APPLICATION_NAME' => APPLICATION_NAME ));
Java
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สําหรับ Java เพื่อใช้ตัวอย่างนี้
// Create a state token to prevent request forgery. // Store it in the session for later validation. String state = new BigInteger(130, new SecureRandom()).toString(32); request.session().attribute("state", state); // Read index.html into memory, and set the client ID, // token state, and application name in the HTML before serving it. return new Scanner(new File("index.html"), "UTF-8") .useDelimiter("\\A").next() .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID) .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state) .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}", APPLICATION_NAME);
Python
คุณต้องดาวน์โหลดไลบรารีของไคลเอ็นต์ Google APIs สําหรับ Python เพื่อใช้ตัวอย่างนี้
# Create a state token to prevent request forgery. # Store it in the session for later validation. state = hashlib.sha256(os.urandom(1024)).hexdigest() session['state'] = state # Set the client ID, token state, and application name in the HTML while # serving it. response = make_response( render_template('index.html', CLIENT_ID=CLIENT_ID, STATE=state, APPLICATION_NAME=APPLICATION_NAME))
2. ส่งคําขอตรวจสอบสิทธิ์ไปยัง Google
ขั้นตอนถัดไปคือการสร้างคําขอ HTTPS GET
ด้วยพารามิเตอร์ URI ที่เหมาะสม
โปรดสังเกตการใช้ HTTPS แทน HTTP ในทุกขั้นตอนของกระบวนการนี้ และจะปฏิเสธการเชื่อมต่อ HTTP คุณควรดึงข้อมูล URI ฐานจากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตา authorization_endpoint
การสนทนาต่อไปนี้จะถือว่า URI ฐานคือ https://accounts.google.com/o/oauth2/v2/auth
สําหรับคําขอพื้นฐาน ให้ระบุพารามิเตอร์ต่อไปนี้
client_id
ซึ่งคุณจะได้รับจาก API Console Credentials pageresponse_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. Exchange code
สําหรับโทเค็นเพื่อการเข้าถึงและโทเค็นรหัส
โดยการตอบกลับจะมีพารามิเตอร์ code
ซึ่งเป็นรหัสการให้สิทธิ์แบบครั้งเดียว ซึ่งเซิร์ฟเวอร์ของคุณแลกเปลี่ยนกับโทเค็นเพื่อการเข้าถึงและโทเค็นรหัสได้ เซิร์ฟเวอร์ของคุณทําการแลกเปลี่ยนนี้โดยการส่งคําขอ HTTPS POST
ระบบจะส่งคําขอ POST
ไปยังปลายทางของโทเค็น ซึ่งคุณควรเรียกข้อมูลจากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตา token_endpoint
การสนทนาต่อไปนี้จะถือว่าปลายทางคือ https://oauth2.googleapis.com/token
คําขอต้องมีพารามิเตอร์ต่อไปนี้ในเนื้อหาของ POST
ช่อง | |
---|---|
code |
รหัสการให้สิทธิ์ที่แสดงผลจากคําขอเริ่มต้น |
client_id |
รหัสไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0 |
client_secret |
รหัสลับไคลเอ็นต์ที่คุณได้รับจาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลรับรอง OAuth 2.0 |
redirect_uri |
URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตของ client_id หนึ่งๆ ที่ระบุใน
API Console
Credentials pageตามที่อธิบายไว้ใน
ตั้งค่า URI การเปลี่ยนเส้นทาง |
grant_type |
ช่องนี้ต้องมีค่า authorization_code และ
ตามที่กําหนดไว้ในข้อกําหนด OAuth 2.0 |
คําขอจริงอาจมีลักษณะตามตัวอย่างต่อไปนี้
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your-client-id& client_secret=your-client-secret& redirect_uri=https%3A//oauth2.example.com/code& grant_type=authorization_code
การตอบกลับคําขอนี้สําเร็จจะมีช่องต่อไปนี้ในอาร์เรย์ JSON
ช่อง | |
---|---|
access_token |
โทเค็นที่ส่งไปยัง Google API ได้ |
expires_in |
อายุการใช้งานที่เหลือของโทเค็นเพื่อการเข้าถึงเป็นวินาที |
id_token |
JWT ที่มีข้อมูลประจําตัวเกี่ยวกับผู้ใช้ที่ Google ลงนามแบบดิจิทัล |
scope |
ขอบเขตของการเข้าถึงที่ได้จาก access_token ซึ่งแสดงเป็นรายการสตริงที่คั่นด้วยช่องว่างและคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ |
token_type |
ระบุประเภทของโทเค็นที่ส่งคืน ตอนนี้ช่องนี้มีค่า Bearer เสมอ
|
refresh_token |
(ไม่บังคับ)
ช่องนี้จะปรากฏก็ต่อเมื่อตั้งค่าพารามิเตอร์ |
5. รับข้อมูลผู้ใช้จากโทเค็นรหัส
โทเค็นรหัสคือ JWT (JSON Web Token) ซึ่งก็คือออบเจ็กต์ JSON ที่เข้ารหัสฐาน 64 ที่เข้ารหัสแบบเข้ารหัส ปกติแล้วคุณจําเป็นต้องตรวจสอบโทเค็นรหัสก่อนที่จะใช้งาน แต่เนื่องจากคุณกําลังสื่อสารกับ Google โดยตรงผ่านช่องทาง HTTPS ที่ไม่มีตัวกลาง และใช้ข้อมูลลับของไคลเอ็นต์เพื่อตรวจสอบสิทธิ์ตัวเองกับ Google คุณจะมั่นใจได้ว่าโทเค็นที่คุณได้รับมาจาก Google และถูกต้องจริงๆ หากเซิร์ฟเวอร์ส่งโทเค็นรหัสไปยังคอมโพเนนต์อื่นๆ ของแอป องค์ประกอบอื่นๆ จะต้องตรวจสอบโทเค็นก่อนที่จะใช้งาน
เนื่องจากไลบรารี API ส่วนใหญ่จะรวมการตรวจสอบกับการดําเนินการถอดรหัสค่าฐาน 64url และแยกวิเคราะห์ JSON ภายใน คุณจึงอาจต้องตรวจสอบความถูกต้องของโทเค็นต่อไปในขณะที่เข้าถึงการอ้างสิทธิ์ในโทเค็นรหัส
โทเค็นรหัส'เพย์โหลด
โทเค็นรหัสเป็นออบเจ็กต์ JSON ที่มีชุดคู่ชื่อ/ค่า ต่อไปนี้คือตัวอย่างที่มีการจัดรูปแบบเพื่อให้อ่านได้ง่าย
{ "iss": "https://accounts.google.com", "azp": "1234987819200.apps.googleusercontent.com", "aud": "1234987819200.apps.googleusercontent.com", "sub": "10769150350006150715113082367", "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q", "hd": "example.com", "email": "jsmith@example.com", "email_verified": "true", "iat": 1353601026, "exp": 1353604926, "nonce": "0394852-3190485-2490358" }
โทเค็นรหัส Google อาจมีช่องต่อไปนี้ (เรียกว่าการอ้างสิทธิ์)
การอ้างสิทธิ์ | ระบุแล้ว | คำอธิบาย |
---|---|---|
aud |
ทุกครั้ง | กลุ่มเป้าหมายที่ใช้โทเค็นรหัสนี้ ซึ่งต้องเป็นรหัสไคลเอ็นต์ OAuth 2.0 ของแอปพลิเคชัน |
exp |
ทุกครั้ง | ระบบจะไม่ยอมรับเวลาหมดอายุของโทเค็นรหัสหรือหลังจากนั้น แสดงในเวลา Unix (จํานวนเต็มวินาที) |
iat |
ทุกครั้ง | เวลาที่ออกโทเค็นรหัส แสดงในเวลา Unix (จํานวนเต็มวินาที) |
iss |
ทุกครั้ง | ตัวระบุผู้ออกใบรับรองสําหรับผู้ออกใบรับรอง https://accounts.google.com หรือ accounts.google.com สําหรับโทเค็นรหัส Google
เสมอ |
sub |
ทุกครั้ง | ตัวระบุผู้ใช้ รหัสที่ไม่ซ้ํากันในบัญชี Google ทั้งหมดและไม่นํามาใช้ซ้ํา บัญชี Google หนึ่งสามารถมีอีเมลหลายรายการในเวลาที่ต่างกัน แต่ค่า sub จะไม่มีการเปลี่ยนแปลง ใช้ sub ภายในแอปพลิเคชันเป็นคีย์ตัวระบุที่ไม่ซ้ํากันของผู้ใช้ ความยาวสูงสุด 255 อักขระซึ่งคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ของ ASCII |
at_hash |
แฮชโทเค็นเพื่อการเข้าถึง ตรวจสอบความถูกต้องของโทเค็นเพื่อการเข้าถึงที่เชื่อมโยงกับโทเค็นข้อมูลประจําตัว หากสร้างโทเค็นรหัสด้วยค่า access_token ในขั้นตอนของเซิร์ฟเวอร์ การอ้างสิทธิ์นี้จะรวมอยู่ในเสมอ คํากล่าวอ้างนี้ใช้เป็นกลไกทางเลือกในการป้องกันการโจมตีแบบการปลอมแปลงคําขอข้ามเว็บไซต์ได้ แต่หากคุณทําตามขั้นตอนที่ 1และขั้นตอนที่ 3 ไม่จําเป็นต้องยืนยันโทเค็นเพื่อการเข้าถึง |
|
azp |
client_id ของผู้นําเสนอที่ได้รับอนุญาต ต้องใช้การอ้างสิทธิ์เมื่อฝ่ายที่ขอโทเค็นรหัสไม่ใช่กลุ่มเดียวกับกลุ่มเป้าหมายของโทเค็นรหัส กรณีนี้อาจเกิดขึ้นที่ Google สําหรับแอปแบบผสม ซึ่งเว็บแอปพลิเคชันและแอป Android มี OAuth 2.0 client_id ต่างกันแต่มีโปรเจ็กต์ Google API เหมือนกัน |
|
email |
อีเมลของผู้ใช้ ค่านี้อาจไม่ซ้ํากับผู้ใช้รายนี้และไม่เหมาะกับการใช้งานเป็นคีย์หลัก ระบุต่อเมื่อขอบเขตมีค่าขอบเขต email เท่านั้น |
|
email_verified |
เป็นจริงหากอีเมลของผู้ใช้ได้รับการยืนยันแล้ว มิฉะนั้นจะเป็น false | |
family_name |
นามสกุลหรือนามสกุลของผู้ใช้ อาจระบุเมื่อมีการอ้างสิทธิ์ name |
|
given_name |
ชื่อหรือชื่อผู้ใช้ที่ระบุของผู้ใช้ อาจระบุเมื่อมีการอ้างสิทธิ์ name |
|
hd |
โดเมนที่เชื่อมโยงกับองค์กร Google Cloud ของผู้ใช้ ระบุเมื่อผู้ใช้เป็นส่วนหนึ่งขององค์กร Google Cloud | |
locale |
ภาษา ซึ่งแสดงโดยแท็กภาษา BCP 47
อาจระบุเมื่อมีการอ้างสิทธิ์ name |
|
name |
ชื่อเต็มของผู้ใช้ในรูปแบบที่แสดงได้ อาจระบุเมื่อ
เมื่อมีการอ้างสิทธิ์ |
|
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
Exchange โทเค็นการรีเฟรชช่วยให้แอปเข้าถึง Google API ได้อย่างต่อเนื่องขณะที่ผู้ใช้ไม่ได้อยู่ในแอปพลิเคชัน หากต้องการขอโทเค็นการรีเฟรช ให้เพิ่มพารามิเตอร์ access_type
เป็น offline
ในคําขอการตรวจสอบสิทธิ์
ข้อควรพิจารณา
- โปรดเก็บโทเค็นการรีเฟรชไว้อย่างปลอดภัยอย่างถาวร เนื่องจากคุณจะได้รับโทเค็นการรีเฟรชในครั้งแรกที่ดําเนินการตามขั้นตอนการแลกเปลี่ยนโค้ดเท่านั้น
- ระบบจํากัดจํานวนโทเค็นการรีเฟรชที่ออก ได้แก่ การจํากัด 1 รายการต่อไคลเอ็นต์/ผู้ใช้ และ 1 รายการต่อผู้ใช้แต่ละคนในไคลเอ็นต์ทั้งหมด หากแอปพลิเคชันขอโทเค็นการรีเฟรชมากเกินไป โทเค็นดังกล่าวอาจถึงขีดจํากัดเหล่านี้ ซึ่งในกรณีนี้โทเค็นการรีเฟรชที่เก่ากว่าจะหยุดทํางาน
ดูข้อมูลเพิ่มเติมได้ในการรีเฟรชโทเค็นเพื่อการเข้าถึง (การเข้าถึงแบบออฟไลน์)
การแสดงข้อความแจ้งความยินยอมอีกครั้ง
คุณแจ้งให้ผู้ใช้ให้สิทธิ์แอปอีกครั้งได้โดยตั้งค่าพารามิเตอร์ prompt
เป็น consent
ในคําขอการตรวจสอบสิทธิ์ เมื่อมีการรวม prompt=consent
หน้าจอคํายินยอมจะแสดงทุกครั้งที่แอปขอการให้สิทธิ์ขอบเขตการเข้าถึง แม้ว่าก่อนหน้านี้จะมีการให้สิทธิ์ขอบเขตทั้งหมดกับโปรเจ็กต์ Google API ก็ตาม ด้วยเหตุนี้ ให้ใส่ prompt=consent
เมื่อจําเป็นเท่านั้น
ดูข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์ prompt
ได้ที่ prompt
ในตารางพารามิเตอร์ URI การตรวจสอบสิทธิ์
พารามิเตอร์ URI การตรวจสอบสิทธิ์
ตารางต่อไปนี้จะให้คําอธิบายที่สมบูรณ์มากขึ้นของพารามิเตอร์ที่ API การตรวจสอบสิทธิ์ OAuth 2.0 ของ Google' ยอมรับ
พารามิเตอร์ | จำเป็น | คำอธิบาย |
---|---|---|
client_id |
(ต้องระบุ) | สตริงรหัสไคลเอ็นต์ที่ได้จาก API Console Credentials pageตามที่อธิบายไว้ใน รับข้อมูลเข้าสู่ระบบ OAuth 2.0 |
nonce |
(ต้องระบุ) | ค่าแบบสุ่มที่สร้างโดยแอปซึ่งจะเปิดใช้การป้องกันการเล่นซ้ํา |
response_type |
(ต้องระบุ) | หากค่าเป็น code ให้เปิดตัวขั้นตอนการให้สิทธิ์การให้สิทธิ์ขั้นพื้นฐานโดยใช้ POST ไปยังปลายทางของโทเค็นเพื่อรับโทเค็น หากค่าเป็น token id_token หรือ id_token token ก็จะเปิดตัวโฟลว์แบบไม่เจาะจงปลายทาง ซึ่งจําเป็นต้องใช้ JavaScript ที่ URI การเปลี่ยนเส้นทางเพื่อเรียกโทเค็นจาก URI #fragment ตัวระบุ |
redirect_uri |
(ต้องระบุ) | กําหนดว่าจะให้ส่งคําตอบไปที่ใด ค่าของพารามิเตอร์นี้ต้องตรงกับค่าการเปลี่ยนเส้นทางที่ได้รับอนุญาตค่าใดค่าหนึ่งใน API Console Credentials page (รวมถึงรูปแบบ HTTP หรือ HTTPS, กรณี และปิดท้าย '/' หากมี) |
scope |
(ต้องระบุ) | พารามิเตอร์ขอบเขตต้องขึ้นต้นด้วยค่า หากมีค่าขอบเขต หากมีค่าขอบเขต นอกเหนือจากขอบเขตเฉพาะสําหรับ OpenID แล้ว อาร์กิวเมนต์ขอบเขตยังรวมค่าขอบเขตอื่นๆ ได้ ค่าขอบเขตทั้งหมดต้องคั่นด้วยช่องว่าง เช่น หากต้องการสิทธิ์การเข้าถึง Google ไดรฟ์ของผู้ใช้ 1 ไฟล์ พารามิเตอร์ขอบเขตอาจเป็น ดูข้อมูลเกี่ยวกับขอบเขตที่พร้อมใช้งานได้ที่ขอบเขต OAuth 2.0 สําหรับ Google API หรือเอกสารประกอบสําหรับ 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 เท่านั้นหรือภายในส่วนหัวของคําขอ หากจัดเก็บโทเค็นรหัสไว้ในเซิร์ฟเวอร์ คุณจะต้องจัดเก็บโทเค็นเหล่านั้นไว้อย่างปลอดภัยด้วย
สิ่งหนึ่งที่ทําให้โทเค็นรหัสเป็นประโยชน์คือ การที่คุณส่งผ่านโทเค็นรอบคอมโพเนนต์ต่างๆ ของแอปได้ คอมโพเนนต์เหล่านี้สามารถใช้โทเค็นรหัสเป็นกลไกการตรวจสอบสิทธิ์ที่ใช้เวลาน้อยในการตรวจสอบสิทธิ์แอปและผู้ใช้ แต่คุณจะต้องตรวจสอบก่อน จึงจะใช้ในโทเค็นรหัสหรือใช้การยืนยันเป็นคํายืนยันผู้ใช้ได้
การตรวจสอบโทเค็นรหัสมีขั้นตอนหลายขั้นตอน ดังนี้
- ยืนยันว่าผู้ออกโทเค็นโทเค็นลงชื่ออย่างถูกต้อง โทเค็นที่ Google ออกจะลงนามโดยใช้ใบรับรองที่พบใน URI ซึ่งระบุไว้ในค่าข้อมูลเมตา
jwks_uri
ของเอกสารการค้นพบ - ตรวจสอบว่าค่าของการอ้างสิทธิ์
iss
ในโทเค็นรหัสเท่ากับhttps://accounts.google.com
หรือaccounts.google.com
- ตรวจสอบว่าค่าของการอ้างสิทธิ์
aud
ในโทเค็นรหัสเท่ากับรหัสไคลเอ็นต์ของแอป - ยืนยันว่าวันหมดอายุของการอ้างสิทธิ์ (
exp
การอ้างสิทธิ์) ของโทเค็นรหัส - หากคุณระบุค่า พารามิเตอร์ hd ในคําขอ ให้ยืนยันว่าโทเค็นรหัสมีการอ้างสิทธิ์
hd
ที่ตรงกับโดเมนที่ยอมรับซึ่งเชื่อมโยงกับองค์กร Google Cloud
ขั้นตอนที่ 2 ถึง 5 จะใช้เฉพาะการเปรียบเทียบสตริงกับวันที่ที่ค่อนข้างตรงไปตรงมา เราจึงไม่ให้รายละเอียดที่นี่
ขั้นตอนแรกมีความซับซ้อนยิ่งขึ้นและต้องมีการตรวจสอบลายเซ็นแบบเข้ารหัส เพื่อจุดประสงค์ในการแก้ไขข้อบกพร่อง คุณสามารถใช้ปลายทาง tokeninfo
ของ Google เพื่อเปรียบเทียบกับการประมวลผลในระบบที่เซิร์ฟเวอร์หรืออุปกรณ์ของคุณใช้ สมมติว่าโทเค็นรหัสของคุณคือ ##39 จากนั้น ให้อ้างอิง URI
https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123
หากลายเซ็นโทเค็นถูกต้อง การตอบกลับจะเป็นเพย์โหลด JWT ในรูปแบบออบเจ็กต์ JSON ที่ถอดรหัสแล้ว
ปลายทาง tokeninfo
มีประโยชน์ในการแก้ไขข้อบกพร่อง แต่เพื่อจุดประสงค์ในการผลิต ให้เรียกใช้คีย์สาธารณะของ Google จากปลายทางคีย์และดําเนินการตรวจสอบความถูกต้องภายในเครื่อง คุณควรดึงข้อมูล URI ของคีย์จากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตา jwks_uri
ระบบอาจควบคุมคําขอที่ส่งไปยังปลายทางการแก้ไขข้อบกพร่องหรืออาจมีข้อผิดพลาดเกิดขึ้นเป็นระยะๆ
เนื่องจาก Google จะเปลี่ยนคีย์สาธารณะไม่บ่อยนัก คุณจึงแคชได้โดยใช้คําสั่งแคชของการตอบกลับ HTTP และในกรณีส่วนใหญ่ การตรวจสอบภายในจะมีประสิทธิภาพมากกว่าการใช้ปลายทาง tokeninfo
การตรวจสอบนี้ต้องใช้การดึงข้อมูลและแยกวิเคราะห์ใบรับรอง และเรียกการเข้ารหัสที่เหมาะสมเพื่อตรวจสอบลายเซ็น โชคดีที่มีไลบรารีที่แก้ไขข้อบกพร่องอย่างดีในหลายภาษา เพื่อดําเนินการดังกล่าว (ดู jwt.io)
การรับข้อมูลโปรไฟล์ผู้ใช้
หากต้องการดูข้อมูลโปรไฟล์เพิ่มเติมเกี่ยวกับผู้ใช้ ให้ใช้โทเค็นเพื่อการเข้าถึง (ซึ่งแอปพลิเคชันจะได้รับระหว่างขั้นตอนการตรวจสอบสิทธิ์) และมาตรฐาน OpenID Connect ดังนี้
คุณต้องใส่ค่าขอบเขต
openid profile
ในคําขอการตรวจสอบสิทธิ์เพื่อให้เป็นไปตามข้อกําหนดของ OpenIDหากต้องการใส่อีเมลของผู้ใช้ คุณจะระบุค่าขอบเขตเพิ่มเติมเป็น
email
ได้ หากต้องการระบุทั้งprofile
และemail
ให้ใส่พารามิเตอร์ต่อไปนี้ใน URI คําขอการตรวจสอบสิทธิ์scope=openid%20profile%20email
- เพิ่มโทเค็นเพื่อการเข้าถึงในส่วนหัวการให้สิทธิ์และส่งคําขอ
GET
ของ HTTPS ไปยังปลายทาง userinfo ซึ่งคุณควรเรียกข้อมูลจากเอกสารการค้นพบโดยใช้ค่าข้อมูลเมตาuserinfo_endpoint
การตอบกลับ userinfo จะมีข้อมูลเกี่ยวกับผู้ใช้ตามที่อธิบายไว้ในOpenID Connect Standard Claims
และค่าข้อมูลเมตาclaims_supported
ของเอกสาร Discovery ผู้ใช้หรือองค์กรอาจเลือกที่จะระบุหรือระงับบางช่อง คุณจึงอาจไม่ได้รับข้อมูลของทุกช่องสําหรับขอบเขตการเข้าถึงที่ได้รับอนุญาต
เอกสารการค้นพบ
โปรโตคอล OpenID Connect ต้องใช้ปลายทางหลายปลายทางในการตรวจสอบสิทธิ์ผู้ใช้ และสําหรับการขอทรัพยากร ซึ่งรวมถึงโทเค็น ข้อมูลผู้ใช้ และคีย์สาธารณะ
OpenID Connect ช่วยให้การใช้งาน OpenID Connect ง่ายขึ้นโดยใช้เอกสาร "Discovery เอกสารการค้นพบสําหรับบริการ OpenID Connect ของ Google อาจดึงมาจาก
https://accounts.google.com/.well-known/openid-configuration
หากต้องการใช้บริการ OpenID Connect ของ Google คุณควรฮาร์ดโค้ด URI ของเอกสาร Discovery (https://accounts.google.com/.well-known/openid-configuration
) ลงในแอปพลิเคชัน
แอปพลิเคชันของคุณจะดึงข้อมูลเอกสาร นํากฎการแคชมาใช้ในการตอบกลับ จากนั้นจะดึงข้อมูล URI ปลายทางจากตามความจําเป็น เช่น หากต้องการตรวจสอบสิทธิ์ผู้ใช้ โค้ดจะเรียกข้อมูลค่าข้อมูลเมตา authorization_endpoint
(https://accounts.google.com/o/oauth2/v2/auth
ในตัวอย่างด้านล่าง) เป็น URI ฐานสําหรับคําขอการตรวจสอบสิทธิ์ที่ส่งไปยัง Google
ต่อไปนี้คือตัวอย่างของเอกสารดังกล่าว ชื่อช่องจะเป็นชื่อที่ระบุอยู่ใน OpenID Connect Discovery 1.0 (โปรดดูความหมายของเอกสารนั้นในเอกสาร) ค่านี้ใช้เพื่อการอธิบายเท่านั้นและอาจมีการเปลี่ยนแปลง แม้ว่าข้อความเหล่านี้จะคัดลอกมาจากเอกสาร Google Discovery จริงเวอร์ชันล่าสุดก็ตาม
{ "issuer": "https://accounts.google.com", "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth", "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code", "token_endpoint": "https://oauth2.googleapis.com/token", "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo", "revocation_endpoint": "https://oauth2.googleapis.com/revoke", "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs", "response_types_supported": [ "code", "token", "id_token", "code token", "code id_token", "token id_token", "code token id_token", "none" ], "subject_types_supported": [ "public" ], "id_token_signing_alg_values_supported": [ "RS256" ], "scopes_supported": [ "openid", "email", "profile" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "claims_supported": [ "aud", "email", "email_verified", "exp", "family_name", "given_name", "iat", "iss", "locale", "name", "picture", "sub" ], "code_challenge_methods_supported": [ "plain", "S256" ] }
คุณอาจหลีกเลี่ยงไป-กลับ HTTP โดยการแคชค่าจากเอกสาร Discovery ส่วนหัวการแคช HTTP มาตรฐานถือเป็นการใช้งานที่มีความเคารพต่อผู้ใช้
ไลบรารีของไคลเอ็นต์
ไลบรารีของไคลเอ็นต์ต่อไปนี้ช่วยให้ใช้งาน OAuth 2.0 ได้ง่ายขึ้นด้วยการผสานรวมกับเฟรมเวิร์กยอดนิยม
- ไลบรารีของไคลเอ็นต์ 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)