การใช้ OAuth กับ Google Data APIs

บทนำ

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

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

ผู้ชม

บทความนี้ถือว่าคุณคุ้นเคยกับ Google Data APIs อย่างน้อย 1 รายการ แต่ไม่จำเป็นต้องเข้าใจแนวคิดเบื้องหลัง OAuth หากคุณเพิ่งเริ่มต้นหรือแค่อยากรู้เกี่ยวกับ OAuth ก็ไม่ต้องไปหาที่ไหนไกล บทความนี้จะให้พื้นฐานแนวคิดเบื้องต้นแก่คุณ นอกจากนี้ ฉันจะพูดถึงรายละเอียดการติดตั้งใช้งาน OAuth ของ Google ด้วย

เอกสารนี้ยังจัดทำขึ้นสำหรับนักพัฒนาแอปที่คุ้นเคยกับการใช้ AuthSub โดยเฉพาะในโหมดลงทะเบียนด้วยการรักษาความปลอดภัยที่ดียิ่งขึ้น เมื่อเราดำเนินการต่อไป ฉันจะพยายามไฮไลต์ความคล้ายคลึงและความแตกต่างระหว่างโปรโตคอลทั้ง 2 หากมีแอปพลิเคชันที่ใช้ AuthSub คุณสามารถใช้ข้อมูลนี้เพื่อย้ายข้อมูลไปยัง OAuth ซึ่งเป็นโปรโตคอลที่เปิดกว้างและทันสมัยกว่า

คำศัพท์เล็กๆ น้อยๆ

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

1. "OAuth dance"

   คำที่ไม่เป็นทางการที่ฉันใช้เพื่ออธิบายกระบวนการตรวจสอบสิทธิ์/การให้สิทธิ์ OAuth ทั้งหมด

2. (OAuth) โทเค็นคำขอ

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

3. โทเค็นเพื่อการเข้าถึง (OAuth)

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

   ความคล้ายคลึงกับ AuthSub:
   โทเค็นเพื่อการเข้าถึง OAuth คือสิ่งเดียวกันกับโทเค็นเซสชัน AuthSub ที่ปลอดภัย

4. (OAuth) ปลายทาง

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

   รับโทเค็นคำขอ	https://www.google.com/accounts/OAuthGetRequestToken
   ให้สิทธิ์โทเค็นคำขอ	https://www.google.com/accounts/OAuthAuthorizeToken
   อัปเกรดเป็นโทเค็นเพื่อการเข้าถึง	https://www.google.com/accounts/OAuthGetAccessToken

   ความคล้ายคลึงกับ AuthSub:
   การแลกเปลี่ยนโทเค็นคำขอที่ได้รับอนุญาตเป็นโทเค็นเพื่อการเข้าถึง คล้ายกับการอัปเกรดโทเค็น AuthSub แบบใช้ครั้งเดียวเป็นโทเค็นเซสชันที่มีอายุยาวที่ https://www.google.com/accounts/AuthSubRequestToken และ https://www.google.com/accounts/AuthSubSessionToken ตามลำดับ ความแตกต่างคือ AuthSub ไม่มีแนวคิดของโทเค็นคำขอเริ่มต้น แต่ผู้ใช้จะเริ่มกระบวนการโทเค็นจากAuthSubRequestTokenหน้าการให้สิทธิ์

5. ผู้ให้บริการ (OAuth)

   ในกรณีของ Google Data API ผู้ให้บริการนี้คือ Google โดยทั่วไป ผู้ให้บริการจะใช้เพื่ออธิบายเว็บไซต์หรือบริการเว็บที่ให้ปลายทาง OAuth อีกตัวอย่างหนึ่งของผู้ให้บริการ OAuth คือ MySpace

6. (OAuth) ผู้บริโภค

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

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

เริ่มต้นใช้งาน

การลงทะเบียน

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

คำขอลงนาม

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

ตัวอย่างคำขอ

GET รายการ Google ปฏิทินของผู้ใช้ที่ http://www.google.com/calendar/feeds/default/allcalendars/full?orderby=starttime

GET http://www.google.com/calendar/feeds/default/allcalendars/full?orderby=starttime HTTP/1.1
Host:  http://www.google.com
Content-Type: application/atom+xml
Authorization: OAuth oauth_token="1%2Fab3cd9j4ks73hf7g", oauth_signature_method="RSA-SHA1", oauth_signature="wOJIO9AvZbTSMK%2FPY%3D...", oauth_consumer_key="example.com", oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d", oauth_version="1.0"

หมายเหตุ: นี่เป็นเพียงการแสดงภาพเท่านั้น oauth_signature ของคุณจะยาวขึ้นมาก

หมายเหตุเกี่ยวกับสตริงฐาน

• ระบบจะจัดเรียงพารามิเตอร์การค้นหา orderby=starttime พร้อมกับพารามิเตอร์ oauth_* ที่เหลือตามลำดับค่าไบต์แบบพจนานุกรม
• สตริงนี้ไม่มีอักขระ "?" ด้วย
• ส่วน base-http-request-url มีเฉพาะ URL ฐานที่เข้ารหัส URL: http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2Fdefault%2Fallcalendars%2Ffull
• oauth_token มีการเข้ารหัส URL 2 ครั้ง

หมายเหตุเกี่ยวกับส่วนหัว Authorization

• ลำดับของพารามิเตอร์ oauth_* ไม่มีความสำคัญในส่วนหัว Authorization
• ส่วนหัวไม่มี orderby=starttime เหมือนสตริงฐาน ระบบจะเก็บพารามิเตอร์การค้นหานั้นไว้เป็นส่วนหนึ่งของ URL คำขอ

ดูข้อมูลเพิ่มเติมเกี่ยวกับการลงนามคำขอโดยใช้ OAuth ได้ที่การลงนามคำขอ OAuth

ความแตกต่างจาก AuthSub:
เพื่อเป็นการเปรียบเทียบ นี่คือตัวอย่างเดียวกันโดยใช้ AuthSub ที่ปลอดภัย

GET http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2Fdefault%2Fallcalendars%2Ffull%3Forderby%3Dstarttime 137131200 4572616e48616d6d

GET http://www.google.com/calendar/feeds/default/allcalendars/full?orderby=starttime HTTP/1.1
Host:  http://www.google.com
Content-Type: application/atom+xml
Authorization: AuthSub token="GD32CMCL25aZ-v____8B" data="GET http://www.google.com/calendar/feeds/default/allcalendars/full?orderby=starttime 137131200 4572616e48616d6d" sig="MCwCFrV93K4agg==..." sigalg="rsa-sha1"

ดูข้อมูลเพิ่มเติมเกี่ยวกับการลงนามคำขอโดยใช้ AuthSub ได้ที่การลงนามคำขอ AuthSub

เครื่องมือ OAuth Playground

ลองใช้เลย

วัตถุประสงค์

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

OAuth Playground เป็นเครื่องมือที่ฉันสร้างขึ้นเพื่อช่วยให้นักพัฒนาแอปแก้ปัญหาเกี่ยวกับ OAuth คุณสามารถใช้ Playground เพื่อช่วยแก้ไขปัญหา ตรวจสอบการติดตั้งใช้งานของคุณเอง หรือทดลองใช้ Google Data API

การทำงานของตัวเลือกนี้

1. แสดงขั้นตอนการตรวจสอบสิทธิ์ OAuth: การดึงโทเค็นคำขอ การให้สิทธิ์โทเค็น และการอัปเกรดเป็นโทเค็นเพื่อการเข้าถึง
2. แสดงสตริงฐานลายเซ็นที่ถูกต้องสำหรับคำขอแต่ละรายการ
3. แสดงส่วนหัว Authorization ที่ถูกต้องสำหรับคำขอแต่ละรายการ
4. แสดงวิธีใช้ oauth_token เพื่อโต้ตอบกับฟีดข้อมูล Google ที่ได้รับการตรวจสอบสิทธิ์ คุณสามารถGET/POST/PUT/DELETEข้อมูลได้
5. ดูฟีดที่ตรวจสอบสิทธิ์แล้วได้โดยตรงในเบราว์เซอร์
6. ช่วยให้คุณทดสอบ oauth_consumer_key (โดเมนที่จดทะเบียน) และคีย์ส่วนตัวของคุณเองได้
7. ดูว่าบริการฟีดข้อมูลของ Google ใดบ้างที่พร้อมให้บริการแก่ oauth_token

การเรียกใช้เดโม

ขั้นตอนที่ 1: เลือกขอบเขต ก่อนอื่นให้เลือก API ที่ต้องการใช้โดยเลือกขอบเขตอย่างน้อย 1 รายการ ในการสาธิตนี้ ฉันจะขอโทเค็นที่ใช้ได้กับ Blogger และ Google Contacts ความคล้ายคลึงกับ AuthSub: AuthSub ยังกำหนดให้ใช้พารามิเตอร์ scope เพื่อควบคุมช่วงของข้อมูลที่โทเค็นเข้าถึงได้ Google ได้ใช้พารามิเตอร์ นี้ตามที่แนะนำไว้ในข้อกำหนด OAuth
ขั้นตอนที่ 2: แก้ไขพารามิเตอร์และการตั้งค่า OAuth ตอนนี้อย่าแก้ไขการตั้งค่าใดๆ ในช่อง "แก้ไขพารามิเตอร์ OAuth" ในภายหลัง คุณสามารถทดสอบด้วยคีย์ส่วนตัวของคุณเองได้โดยเปลี่ยน oauth_consumer_key เป็นโดเมนที่ลงทะเบียนไว้ แล้วป้อนคีย์ส่วนตัวโดยคลิก "ใช้คีย์ส่วนตัวของคุณเอง" โปรดใช้คีย์ส่วนตัวทดสอบเท่านั้น หมายเหตุ: oauth_signature_method และ oauth_consumer_key เป็นฟิลด์เดียวที่แก้ไขได้ที่นี่ ระบบจะสร้าง oauth_timestamp, oauth_nonce และ oauth_token ให้คุณโดยอัตโนมัติ นอกจาก RSA-SHA1 แล้ว คุณอาจเลือกใช้ HMAC-SHA1 สำหรับ oauth_signature_method ก็ได้ ในกรณีดังกล่าว Playground จะแสดงช่องเพิ่มเติมที่คุณจะต้องป้อน oauth_consumer_key และ Consumer Secret ของคุณเอง คุณดูค่าเหล่านี้ได้ในหน้า https://www.google.com/accounts/ManageDomains สำหรับโดเมนที่ลงทะเบียน ความแตกต่างจาก AuthSub: ใน AuthSub ที่ปลอดภัย ไม่มีพารามิเตอร์ที่จะตั้งชื่อโดเมนอย่างชัดเจน โดเมนจะรวมเป็นส่วนหนึ่งของพารามิเตอร์ URL next OAuth มีพารามิเตอร์ดังกล่าว: oauth_consumer_key ตั้งค่าเป็นโดเมนที่ลงทะเบียน
ขั้นตอนที่ 3-5: รับโทเค็นเพื่อการเข้าถึง การรับโทเค็นเพื่อการเข้าถึง OAuth มี 3 ขั้นตอน ขั้นตอนแรกคือการดึงโทเค็นคำขอ ซึ่งจะช่วยให้ Google ทราบว่าแอปพลิเคชันของคุณกำลังเริ่มการดำเนินการ OAuth ก่อนอื่น ให้คลิกปุ่ม "ขอโทเค็น" ในช่อง "รับโทเค็น" ระบบจะป้อนข้อมูลในบางช่อง "สตริงฐานลายเซ็น" จะแสดงรูปแบบที่ถูกต้องของสตริงฐานที่ใช้สร้างพารามิเตอร์ oauth_signature "ส่วนหัวการให้สิทธิ์" จะแสดงส่วนหัว Authorization ที่เกี่ยวข้องสำหรับคำขอ ช่อง "แก้ไขพารามิเตอร์ OAuth" ที่กรอกค่า oauth_nonce และ oauth_timestamp ที่ส่งในคำขอ ระบบจะป้อนค่าที่สอดคล้องกันซึ่งแสดงผลในเนื้อหาการตอบกลับลงในoauth_token นอกจากนี้ Playground ยังแสดงประเภทของ oauth_token ที่เรามีในปัจจุบันด้วย ปัจจุบันคือโทเค็นคำขอ
จากนั้นคลิกปุ่ม "ให้สิทธิ์" ในช่อง "รับโทเค็น" ในหน้าการให้สิทธิ์นี้ ให้คลิกปุ่ม "ให้สิทธิ์เข้าถึง" เพื่อให้สิทธิ์โทเค็นคำขอ และระบบจะนำคุณกลับไปที่ OAuth Playground ความคล้ายคลึงกับ AuthSub: หน้านี้สำหรับการให้สิทธิ์จะเหมือนกับ AuthSub ความแตกต่างจาก AuthSub: พารามิเตอร์ URL next ของ AuthSub มีลักษณะคล้ายกับพารามิเตอร์ oauth_callback ความแตกต่างคือใน OAuth oauth_callback เป็นค่าที่ไม่บังคับ หลังจากที่ผู้ใช้คลิกปุ่ม "ให้สิทธิ์เข้าถึง" โทเค็นคำขอจะได้รับอนุญาตและสามารถอัปเกรดโทเค็นเป็น https://www.google.com/accounts/OAuthGetAccessToken แบบไม่พร้อมกันได้ เคล็ดลับ: ขอแนะนำให้ระบุ oauth_callback URL หากคุณกำลังเขียนเว็บแอปพลิเคชัน เนื่องจากจะช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดียิ่งขึ้น
สุดท้าย ให้คลิกปุ่ม "โทเค็นเพื่อการเข้าถึง" ในช่อง "รับโทเค็น" การดำเนินการนี้จะอัปเกรดโทเค็นคำขอที่ได้รับอนุญาต (ตามที่ระบุโดยป้ายกำกับ "โทเค็นเพื่อเข้าถึง" สีแดง) หากต้องการรับโทเค็นใหม่ ให้คลิก "เริ่มใหม่" เพื่อเริ่มการแลกเปลี่ยน OAuth อีกครั้ง ตอนนี้เราก็ทำอะไรที่น่าสนใจได้แล้ว

การใช้โทเค็นเพื่อการเข้าถึง

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

เคล็ดลับ: หากต้องการดูฟีดที่โทเค็นเพื่อการเข้าถึงของคุณใช้ได้ ให้คลิกปุ่ม "ฟีดที่ใช้ได้"

ตัวอย่างคำค้นหา GET http://www.blogger.com/feeds/1982051675575479214/posts/default?max-results=3

ตัวอย่างนี้จะแสดงโพสต์ในบล็อกหนึ่งๆ ไม่เกิน 3 รายการ นอกจากนี้ คุณยังดูฟีด/รายการที่ส่งคืนในเบราว์เซอร์ได้โดยตรงโดยคลิกลิงก์ "ดูในเบราว์เซอร์" ใต้พื้นที่ที่ไฮไลต์ไวยากรณ์

ตัวอย่าง: วิธีอัปเดตโพสต์

1. ค้นหาองค์ประกอบ <link> ที่มี rel="edit" ในโพสต์ที่ต้องการอัปเดต ซึ่งควรมีลักษณะดังนี้

   <link rel="edit" href="http://www.blogger.com/feeds/1982051675575479214/posts/default/8138973184593279875"/>

   วาง href URL ในอินพุต "ป้อนฟีดข้อมูล Google"

2. คัดลอก XML ของรายการที่มีอยู่โดยคลิก "ดูข้อความธรรมดา" ที่ด้านบนของแผงที่ไฮไลต์ไวยากรณ์ คัดลอกเฉพาะเนื้อหาการตอบกลับ ไม่ใช่ส่วนหัว
3. เปลี่ยนเมธอด HTTP ในเมนูแบบเลื่อนลงเป็น PUT
4. คลิก "ป้อนข้อมูลโพสต์" ใต้เมนูแบบเลื่อนลงนั้น แล้ววาง <entry> XML ลงในป๊อปอัป
5. คลิกปุ่ม "เรียกใช้"

เซิร์ฟเวอร์จะตอบกลับด้วย 200 OK

เคล็ดลับ: ยกเลิกการเลือกช่องทำเครื่องหมาย "ไฮไลต์ไวยากรณ์ไหม" แทนการคัดลอกลิงก์ edit ด้วยตนเอง หลังจากทำการค้นหาแล้ว คุณจะคลิกลิงก์ภายในเนื้อหาการตอบกลับ XML ได้

บทสรุป

เทคโนโลยีต่างๆ เช่น AtomPub/Atom Publishing Protocol (โปรโตคอลพื้นฐานของ Google Data APIs) และ OAuth ช่วยขับเคลื่อนเว็บไปข้างหน้า เมื่อเว็บไซต์จำนวนมากขึ้นเริ่มใช้มาตรฐานเหล่านี้ นักพัฒนาแอปอย่างเราก็จะเป็นผู้ชนะ การสร้างแอปที่โดดเด่นจึงกลายเป็นเรื่องง่ายขึ้น

หากมีคำถามหรือความคิดเห็นเกี่ยวกับ OAuth Playground หรือการใช้ OAuth กับ Google APIs โปรดไปที่ฟอรัมสนับสนุนสำหรับ G Suite APIs และ Marketplace APIs

แหล่งข้อมูล

• การตรวจสอบสิทธิ์ OAuth สำหรับเว็บแอปพลิเคชัน
• รายการ Google Data API
• ฟอรัมสนทนาเกี่ยวกับ Google Accounts API
• ข้อกำหนดหลักของ OAuth 1.0