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