OAuth 2.0 สำหรับแอปบนอุปกรณ์เคลื่อนที่และเดสก์ท็อป

เอกสารนี้อธิบายวิธีที่แอปพลิเคชันซึ่งติดตั้งในอุปกรณ์ต่างๆ เช่น โทรศัพท์ แท็บเล็ต และ คอมพิวเตอร์ ใช้ปลายทาง OAuth 2.0 ของ Google เพื่อให้สิทธิ์เข้าถึง YouTube Analytics API หรือ YouTube Reporting API

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

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

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

ไลบรารีและตัวอย่าง

สำหรับแอป iOS เราขอแนะนำให้ใช้ Sign In With Google iOS SDK เวอร์ชันล่าสุด SDK จะจัดการการให้สิทธิ์ผู้ใช้และติดตั้งใช้งานได้ง่ายกว่า โปรโตคอลระดับล่างที่อธิบายไว้ในคู่มือนี้

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

ข้อกำหนดเบื้องต้น

เปิดใช้ API สำหรับโปรเจ็กต์

แอปพลิเคชันใดก็ตามที่เรียกใช้ Google APIs จะต้องเปิดใช้ API เหล่านั้นใน API Console

วิธีเปิดใช้ API สำหรับโปรเจ็กต์

1. Open the API Library ใน Google API Console
2. If prompted, select a project, or create a new one.
3. ใช้หน้าคลังเพื่อค้นหาและเปิดใช้ API ของข้อมูลวิเคราะห์ YouTube และ Reporting API ของ YouTube แอปพลิเคชันจำนวนมากที่ดึงข้อมูลวิเคราะห์ YouTube ยังเชื่อมต่อกับ YouTube Data API ด้วย ค้นหา API อื่นๆ ที่แอปพลิเคชันของคุณจะใช้และเปิดใช้ API เหล่านั้นด้วย

สร้างข้อมูลเข้าสู่ระบบการให้สิทธิ์

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

1. Go to the Clients page.
2. คลิกสร้างไคลเอ็นต์
3. ส่วนต่อไปนี้จะอธิบายประเภทไคลเอ็นต์ที่เซิร์ฟเวอร์การให้สิทธิ์ของ Google รองรับ เลือกประเภทไคลเอ็นต์ที่แนะนําสําหรับ แอปพลิเคชัน ตั้งชื่อไคลเอ็นต์ OAuth และตั้งค่าช่องอื่นๆ ในแบบฟอร์มตาม ความเหมาะสม

ms-app://YOUR_APP_PACKAGE_SID

ระบุขอบเขตการเข้าถึง

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

ก่อนที่คุณจะเริ่มใช้งานการอนุญาต OAuth 2.0 เราขอแนะนำให้คุณระบุขอบเขตที่แอปของคุณจำเป็นต้องได้รับอนุญาตให้เข้าถึงก่อน

API ของ YouTube Analytics ใช้ขอบเขตต่อไปนี้:

API การรายงานของ YouTube ใช้ขอบเขตต่อไปนี้:

เอกสาร OAuth 2.0 API Scopes มีรายการขอบเขตทั้งหมดที่คุณอาจใช้เพื่อเข้าถึง Google API

การขอรับโทเค็นการเข้าถึง OAuth 2.0

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

ขั้นตอนที่ 1: สร้างตัวตรวจสอบรหัสและคำท้า

Google รองรับโปรโตคอล Proof Key for Code Exchange (PKCE) เพื่อเพิ่มความปลอดภัยในการติดตั้งแอป สำหรับคำขออนุญาตแต่ละครั้ง จะมีการสร้างตัวตรวจสอบรหัสที่ไม่ซ้ำกัน และค่าที่แปลงแล้วของตัวตรวจสอบรหัสนี้ ซึ่งเรียกว่า "code_challenge" จะถูกส่งไปยังเซิร์ฟเวอร์อนุญาตเพื่อรับรหัสอนุญาต

สร้างตัวตรวจสอบรหัส

code_verifier คือสตริงสุ่มเข้ารหัสที่มีเอนโทรปีสูง โดยใช้ตัวอักขระที่ไม่ได้สงวนไว้ [AZ] / [az] / [0-9] / "-" / "." / "_" / "~" โดยมีความยาวขั้นต่ำ 43 ตัวอักขระ และความยาวสูงสุด 128 ตัวอักขระ

ตัวตรวจสอบรหัสควรมีเอนโทรปีมากพอที่จะทำให้การเดาค่าเป็นไปไม่ได้ในทางปฏิบัติ

สร้างความท้าทายด้านการเขียนโค้ด

รองรับวิธีการสร้างโจทย์ท้าทายการเขียนโค้ดสองวิธี

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

ขั้นตอนที่ 2: ส่งคำขอไปยังเซิร์ฟเวอร์ OAuth 2.0 ของ Google

หากต้องการขอการให้สิทธิ์จากผู้ใช้ ให้ส่งคำขอไปยังเซิร์ฟเวอร์การให้สิทธิ์ของ Google ที่ https://accounts.google.com/o/oauth2/v2/auth ปลายทางนี้จะจัดการการค้นหาเซสชันที่ใช้งานอยู่ ตรวจสอบสิทธิ์ผู้ใช้ และขอรับความยินยอมจากผู้ใช้ ปลายทางจะเข้าถึงได้ผ่าน SSL เท่านั้น และจะปฏิเสธการเชื่อมต่อ HTTP (ที่ไม่ใช่ SSL)

เซิร์ฟเวอร์การให้สิทธิ์รองรับพารามิเตอร์สตริงคำค้นหาต่อไปนี้สำหรับแอปพลิเคชันที่ติดตั้ง

ตัวอย่าง URL การให้สิทธิ์

แท็บด้านล่างแสดงตัวอย่าง URL การให้สิทธิ์สำหรับตัวเลือก URI การเปลี่ยนเส้นทางต่างๆ

URL จะเหมือนกันทุกประการ ยกเว้นค่าของพารามิเตอร์ redirect_uri นอกจากนี้ URL ยังมีพารามิเตอร์ response_type และ client_id ที่จำเป็น รวมถึงพารามิเตอร์ state ที่ไม่บังคับด้วย URL แต่ละรายการมีการขึ้นบรรทัดใหม่และเว้นวรรคเพื่อให้ อ่านง่าย

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

ขั้นตอนที่ 3: Google ขอความยินยอมจากผู้ใช้

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

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

ขั้นตอนที่ 4: จัดการการตอบกลับของเซิร์ฟเวอร์ OAuth 2.0

ลักษณะที่แอปพลิเคชันของคุณได้รับการตอบกลับการให้สิทธิ์จะขึ้นอยู่กับรูปแบบ URI การเปลี่ยนเส้นทางที่ใช้ ไม่ว่าจะเป็นรูปแบบใด การตอบกลับ จะมีรหัสการให้สิทธิ์ (code) หรือข้อผิดพลาด (error) เช่น error=access_denied แสดงว่าผู้ใช้ ปฏิเสธคำขอ

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

ขั้นตอนที่ 5: แลกเปลี่ยนรหัสการให้สิทธิ์สำหรับโทเค็นการรีเฟรชและการเข้าถึง

หากต้องการแลกรหัสการให้สิทธิ์เป็นโทเค็นเพื่อการเข้าถึง ให้เรียกใช้ https://oauth2.googleapis.com/token ปลายทางและตั้งค่าพารามิเตอร์ต่อไปนี้

ตัวอย่างคำขอแสดงอยู่ในส่วนต่อไปนี้:

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&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google ตอบสนองต่อคำขอนี้โดยส่งคืนอ็อบเจ็กต์ JSON ที่ประกอบด้วยโทเค็นการเข้าถึงที่มีอายุสั้นและโทเค็นรีเฟรช

คำตอบประกอบด้วยฟิลด์ต่อไปนี้:

ตัวอย่างข้อความต่อไปนี้แสดงตัวอย่างการตอบกลับ:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

ขั้นตอนที่ 6: ตรวจสอบว่าผู้ใช้ได้รับสิทธิ์การเข้าถึงขอบเขตใดบ้าง

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

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

สำหรับข้อมูลรายละเอียดเพิ่มเติม โปรดดูที่ วิธีจัดการสิทธิ์แบบละเอียด

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

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

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

เรียกใช้ API ของ Google

หลังจากแอปพลิเคชันของคุณได้รับโทเค็นการเข้าถึงแล้ว คุณสามารถใช้โทเค็นนั้นเพื่อเรียกใช้ Google API ในนามของบัญชีผู้ใช้ที่กำหนดได้ หากคุณได้รับอนุญาตสิทธิ์การเข้าถึงที่ API นั้นต้องการแล้ว ในการทำเช่นนี้ ให้รวมโทเค็นการเข้าถึงไว้ในคำขอไปยัง API โดยการรวมพารามิเตอร์การค้นหา access_token หรือค่าส่วนหัว HTTP Authorization Bearer ไว้ด้วย หากเป็นไปได้ ควรใช้ส่วนหัว HTTP เนื่องจากสตริงคำค้นหามักจะปรากฏในบันทึกของเซิร์ฟเวอร์ ในกรณีส่วนใหญ่ คุณสามารถใช้ไลบรารีไคลเอ็นต์เพื่อตั้งค่าการเรียกใช้ API ของ Google ได้ (ตัวอย่างเช่น เมื่อ...)เรียกใช้ API ของ YouTube Analytics )

โปรดทราบว่า YouTube Analytics API ไม่รองรับขั้นตอนการใช้งานบัญชีบริการ API การรายงานของ YouTube รองรับบัญชีบริการเฉพาะสำหรับเจ้าของเนื้อหา YouTube ที่เป็นเจ้าของและจัดการช่อง YouTube หลายช่อง เช่น ค่ายเพลงและสตูดิโอภาพยนตร์

คุณสามารถทดลองใช้ Google API ทั้งหมดและดูขอบเขตการใช้งานได้ที่ OAuth 2.0 Playground

ตัวอย่าง HTTP GET

การเรียกร้องไปยัง reports.query ปลายทาง (YouTube Analytics API) โดยใช้Authorization: Bearer ส่วนหัวของ HTTP อาจมีลักษณะดังต่อไปนี้ โปรดทราบว่าคุณต้องระบุโทเค็นการเข้าถึงของคุณเอง:

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

ต่อไปนี้คือการเรียกใช้ API เดียวกันสำหรับผู้ใช้ที่เข้าสู่ระบบแล้ว โดยใช้พารามิเตอร์สตริงคำค้นหา access_token:

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

ตัวอย่างของ curl

คุณสามารถทดสอบคำสั่งเหล่านี้ได้ด้วยแอปพลิเคชันบรรทัดคำสั่ง curl ต่อไปนี้เป็นตัวอย่างที่ใช้ตัวเลือกส่วนหัว HTTP (ซึ่งเป็นวิธีที่แนะนำ):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

หรืออีกทางเลือกหนึ่งคือ ตัวเลือกพารามิเตอร์สตริงคำค้นหา:

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

รีเฟรชโทเค็นการเข้าถึง

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

ในการรีเฟรชโทเค็นการเข้าถึง แอปพลิเคชันของคุณจะส่งคำขอ HTTPS POST ไปยังเซิร์ฟเวอร์การอนุญาตของ Google (https://oauth2.googleapis.com/token) ซึ่งมีพารามิเตอร์ต่อไปนี้:

ข้อมูลโค้ดต่อไปนี้แสดงคำขอตัวอย่าง

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

การเพิกถอนโทเค็น

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

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

หากต้องการเพิกถอนโทเค็นโดยอัตโนมัติ แอปพลิเคชันของคุณจะส่งคำขอไปยัง https://oauth2.googleapis.com/revoke และรวมโทเค็นเป็นพารามิเตอร์

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

โทเค็นอาจเป็นโทเค็นเพื่อการเข้าถึงหรือโทเค็นการรีเฟรชก็ได้ หากโทเค็นเป็นโทเค็นเพื่อการเข้าถึงและมี โทเค็นการรีเฟรชที่เกี่ยวข้อง ระบบจะเพิกถอนโทเค็นการรีเฟรชด้วย

หากการเพิกถอนดำเนินการสำเร็จ รหัสสถานะ HTTP ของการตอบกลับจะเป็น 200 สำหรับเงื่อนไขข้อผิดพลาด ระบบจะแสดงรหัสสถานะ HTTP 400 พร้อมกับรหัสข้อผิดพลาด

วิธีการเปลี่ยนเส้นทางแอป

ปกป้องแอปของคุณ

การเข้าถึงตามเวลา

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

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

อ่านเพิ่มเติม

แนวทางปฏิบัติแนะนำปัจจุบันของ IETF OAuth 2.0 สำหรับ แอปเนทีฟกำหนดแนวทางปฏิบัติแนะนำหลายอย่างที่บันทึกไว้ที่นี่