ตั้งค่า Google Cloud และ OAuth

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

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

สร้างโปรเจ็กต์และไคลเอ็นต์ OAuth

ใช้ปุ่มเปิดใช้ API และรับรหัสไคลเอ็นต์ OAuth 2.0 เพื่อเปิดใช้ Google Health API และรับรหัสไคลเอ็นต์ OAuth 2.0 โดยทำดังนี้

1. หากคุณมีโปรเจ็กต์ Google Cloud อยู่แล้วที่ต้องการใช้กับ Google Health API ให้ตรวจสอบว่าคุณได้เข้าสู่ระบบบัญชีผู้ดูแลระบบของโปรเจ็กต์นั้นแล้ว จากนั้นเลือกโปรเจ็กต์ที่มีอยู่จากรายการโปรเจ็กต์ที่พร้อมใช้งานหลังจากคลิกปุ่ม หรือสร้างโปรเจ็กต์ใหม่
2. เลือก Web Server เมื่อระบบถามว่า "คุณเรียกใช้จากที่ใด"
3. ป้อน https://www.google.com เป็นค่าสำหรับ URI เปลี่ยนเส้นทางที่ได้รับอนุญาต คุณต้องระบุ URI เปลี่ยนเส้นทางเพื่อรับรหัสการให้สิทธิ์โดยใช้ OAuth 2.0
4. เมื่อตั้งค่าเสร็จแล้ว ให้คัดลอกค่ารหัสไคลเอ็นต์ OAuth 2.0 และ Client Secret แล้วดาวน์โหลดข้อมูลเข้าสู่ระบบ JSON ลงในเครื่องของคุณ

เปิดใช้ API และรับรหัสไคลเอ็นต์ OAuth 2.0

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

1. เปิดใช้ Google Health API ในหน้า การเปิดใช้ API
2. รับรหัสไคลเอ็นต์ OAuth 2.0 ในหน้า ข้อมูลเข้าสู่ระบบ

ดูข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่า OAuth 2.0 โดยใช้คอนโซล Google ได้ที่ หัวข้อการใช้ OAuth 2.0 เพื่อเข้าถึง Google API

เพิ่มผู้ใช้ทดสอบ

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

อัปเดตรายชื่อผู้ใช้ทดสอบในหน้า กลุ่มเป้าหมาย โดยทำดังนี้

1. ในหน้านี้ คุณควรเห็น "สถานะการเผยแพร่" ตั้งค่าเป็น การทดสอบ และ "ประเภทผู้ใช้" ตั้งค่าเป็น ภายนอก
2. ในส่วน "ผู้ใช้ทดสอบ" ให้คลิก + เพิ่มผู้ใช้ ป้อนอีเมลของผู้ใช้ทดสอบที่ควรได้รับอนุญาตให้ให้สิทธิ์แอปในการเข้าถึงข้อมูลสุขภาพ
3. คลิกบันทึก

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

เพิ่มขอบเขต

คุณต้องระบุขอบเขตที่ไคลเอ็นต์ได้รับอนุญาตให้เรียกใช้ในหน้า การเข้าถึงข้อมูล โดยทำดังนี้

1. คลิกเพิ่มหรือนำขอบเขตออก ในหน้านี้
2. ค้นหา "Google Health API" ในคอลัมน์ API เลือกขอบเขตที่ต้องการสำหรับแอปพลิเคชัน
3. หลังจากเลือกขอบเขตที่ต้องการทั้งหมดแล้ว ให้คลิกอัปเดต เพื่อกลับไปที่หน้าการเข้าถึงข้อมูล
4. คลิกบันทึก

โปรดอ่านการใช้งานขอบเขต ขอบเขตก่อนเลือกขอบเขต

คุณตั้งค่ารหัสไคลเอ็นต์เสร็จแล้ว และตอนนี้ควรจะเรียกใช้ Google Health API ได้

อัปเดตขอบเขต

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

หากต้องการเพิ่มหรือเปลี่ยนขอบเขตโดยใช้พารามิเตอร์ prompt=consent ให้ทำตามขั้นตอนต่อไปนี้

1. ระบุรายการ ขอบเขตทั้งหมดที่แอปพลิเคชัน ต้องการ ซึ่งควรรวมทั้งขอบเขตที่มีอยู่และขอบเขตใหม่ที่ต้องเพิ่ม

2. แก้ไขพารามิเตอร์ `scope` ใน URL การให้สิทธิ์เพื่อรวมรายการค่าขอบเขตที่อัปเดตแล้วซึ่งคั่นด้วยช่องว่าง

3. เพิ่ม prompt=consent ลงในพารามิเตอร์ URI การตรวจสอบสิทธิ์ ซึ่งจะบังคับให้เซิร์ฟเวอร์การให้สิทธิ์แจ้งให้ผู้ใช้ให้ความยินยอมก่อนที่จะแสดงข้อมูลแก่ไคลเอ็นต์

   ตัวอย่างต่อไปนี้แสดงคำขอ HTTPS GET ไปยังปลายทางการให้สิทธิ์ OAuth 2.0 ของ Google เพื่อขอขอบเขตหลายรายการโดยเพิ่ม prompt=consent ไว้

   https://accounts.google.com/o/oauth2/v2/auth?client_id=client-id&redirect_uri=redirect-uri&response_type=code&access_type=offline&scope=https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly%20https://www.googleapis.com/auth/googlehealth.sleep.readonly&prompt=consent

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

   รวม prompt=consent เฉพาะเมื่อจำเป็นเท่านั้น เช่น เมื่อคุณต้องการรับโทเค็นการรีเฟรชใหม่หรือเมื่อขอบเขตที่ขอมีการเปลี่ยนแปลง

ไลบรารีไคลเอ็นต์ OAuth2

ดูรายการไลบรารีไคลเอ็นต์ OAuth2 ที่พร้อมใช้งานซึ่งใช้เพื่อผสานรวมกับเฟรมเวิร์กยอดนิยม ได้ที่ การใช้ OAuth 2.0 เพื่อเข้าถึง Google API

โทเค็นการรีเฟรช

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

หากต้องการแลกโทเค็นการรีเฟรชเป็นโทเค็นเพื่อการเข้าถึง ให้เรียกใช้ HTTPS POST ไปยังปลายทางโทเค็น OAuth 2.0 ของ Google ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่างคำขอและการตอบกลับ

ส่งคำขอ

curl -L -X POST 'https://oauth2.googleapis.com/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'

คำตอบ

{
  "access_token": "access-token",
  "expires_in": 3599,
  "scope": "scope-list",
  "token_type": "Bearer",
  "refresh_token": "refresh-token",
  "refresh_token_expires_in": 112154
}

เวลาที่ควรจะรีเฟรชโทเค็น

รีเฟรชโทเค็นตามความต้องการซึ่งเป็นส่วนหนึ่งของความคืบหน้าตามปกติของเซสชันที่ใช้งานอยู่ของผู้ใช้เมื่อโทเค็นเพื่อการเข้าถึงหมดอายุหรือใกล้หมดอายุ หลีกเลี่ยงการรีเฟรชโทเค็นเป็นชุด (เช่น ใช้ cron job หรือบริการที่กำหนดเวลาไว้เพื่อรีเฟรชโทเค็นสำหรับผู้ใช้ทั้งหมดในเวลาที่กำหนด)

เราไม่แนะนำให้รีเฟรชโทเค็นเป็นชุดด้วยเหตุผลต่อไปนี้

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

ลักษณะการทำงานของโทเค็นระหว่างการทดสอบ

โปรดทราบลักษณะการทำงานของโทเค็นการรีเฟรชซึ่งขึ้นอยู่กับสถานะการเผยแพร่ของโปรเจ็กต์ Google Cloud โดยมีรายละเอียดดังนี้

• โหมดการทดสอบ: หากหน้าจอขอความยินยอม OAuth ได้รับการกำหนดค่าด้วยสถานะการเผยแพร่ "การทดสอบ" โทเค็นการรีเฟรชที่ออกให้จะเป็นแบบอิงตามเวลาและหมดอายุหลังจากผ่านไป 7 วัน ในช่วงนี้ คุณจะได้รับโทเค็นการรีเฟรชรายการเดียวที่ยังคงใช้ได้และใช้เพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ได้จนกว่าจะถึงวันที่หมดอายุ
• โหมดเผยแพร่: เมื่อย้ายแอปไปอยู่ในสถานะ "ใช้งานจริง" โดยทั่วไปแล้วโทเค็นการรีเฟรชจะไม่หมดอายุ เว้นแต่จะถูกเพิกถอนหรือไม่ได้ใช้งานเป็นระยะเวลานาน (โดยปกติคือ 6 เดือน)

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

การป้องกันแบบครอบคลุมหลายบริการ (RISC API)

เปิดใช้ Risk and Incident Sharing and Coordination (RISC) หากต้องการรับการแจ้งเตือนเกี่ยวกับการเปลี่ยนแปลงโทเค็นเหตุการณ์หรือการลิงก์บัญชี เช่น บัญชีที่ยกเลิกการเชื่อมต่อหรือโทเค็นที่เพิกถอน เพื่อล้างโทเค็นที่จัดเก็บไว้และอัปเดตสถานะการเชื่อมต่อ UI การเปิดใช้ RISC API เป็นตัวเลือก

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

1. เปิดหน้า RISC API ในคอนโซล Google Cloud ตรวจสอบว่าได้เลือกโปรเจ็กต์ที่ใช้สำหรับ Google Health API แล้ว
2. อ่านข้อกำหนดของ RISC และ ตรวจสอบว่าคุณเข้าใจข้อกำหนด
3. คลิกเปิดใช้ หากคุณยินยอมตามข้อกำหนด

หลังจากเปิดใช้ API แล้ว คุณต้องสร้างและลงทะเบียนปลายทาง HTTPS เพื่อรับและตรวจสอบโทเค็นเหตุการณ์ที่ Google ส่ง

ดูข้อมูลเพิ่มเติมเกี่ยวกับการป้องกันแบบครอบคลุมหลายบริการและ RISC ได้ที่ หัวข้อปกป้องบัญชีผู้ใช้ด้วยการป้องกันแบบครอบคลุมหลายบริการ