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

Eric Bidelman จากทีม Google Data API
กันยายน 2008

บทนำ

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

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

ผู้ชม

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

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

คําศัพท์เล็กน้อย

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

  1. "การเต้น OAuth"

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

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

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

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

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

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

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

    นี่คือ URI ที่จําเป็นในการตรวจสอบสิทธิ์แอปพลิเคชันและรับโทเค็นเพื่อการเข้าถึง กระบวนการ OAuth มีทั้งหมด 3 รายการ ได้แก่ 1 ขั้นตอนสําหรับกระบวนการ 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 API เนื่องจากคําขอ OAuth ทั้งหมดต้องมีลายเซ็นดิจิทัล คุณจึงต้องจดทะเบียนโดเมนแล้วอัปโหลดใบรับรองสาธารณะไปยัง Google ก่อน ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีดําเนินการดังกล่าวได้ที่การลงทะเบียนสําหรับแอปพลิเคชันบนเว็บและการสร้างคีย์และใบรับรองเพื่อใช้กับโหมดที่ลงทะเบียน

คําขอลงนาม

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

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

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

รูปแบบสตริงฐาน base_string = http-method&base-http-request-url&normalized-string-of-oauth_parameters
ตัวอย่างสตริงฐาน GET&http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2Fdefault%2Fallcalendars%2Ffull&oauth_consumer_key%3Dexample.com%26oauth_nonce%3D4572616e48616d6d%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D137131200%26oauth_token%3D1%252Fab3cd9j4ks73hf7g%26oauth_version%3D1.0%26orderby%3Dstarttime
ตัวอย่างคําขอ HTTP 
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 คู่

หมายเหตุในส่วนหัว Authorization

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

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

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

รูปแบบสตริงฐาน base_string = http-method http-request-URL timestamp nonce
ตัวอย่างสตริงฐาน 
GET http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2Fdefault%2Fallcalendars%2Ffull%3Forderby%3Dstarttime 137131200 4572616e48616d6d
ตัวอย่างคําขอ HTTP 
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 OAuthground

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

ผู้ใช้บางรายได้แนะนําว่า 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 เป็นโดเมนที่ลงทะเบียน แล้วป้อนคีย์ส่วนตัวของคุณโดยคลิก "ใช้คีย์ส่วนตัวของคุณเอง" โปรดใช้คีย์ส่วนตัว TEST เท่านั้น

หมายเหตุ: oauth_signature_method และ oauth_consumer_key เป็นช่องเดียวที่แก้ไขได้ที่นี่ ระบบจะสร้าง oauth_timestamp, oauth_nonce และ oauth_token ให้คุณโดยอัตโนมัติ

นอกเหนือจาก RSA-SHA1 คุณอาจเลือกใช้ HMAC-SHA1 สําหรับ oauth_signature_method ในกรณีนี้ Playground จะแสดงกล่องเพิ่มเติมที่คุณจะต้องป้อน oauth_consumer_key และข้อมูลลับของผู้บริโภคของคุณเอง ค่าเหล่านี้จะอยู่ในส่วนหน้า 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 สามารถดําเนินการแบบไม่พร้อมกัน

เคล็ดลับ: เราขอแนะนําให้ระบุ URL oauth_callback หากคุณเขียนเว็บแอปพลิเคชันเพราะมอบประสบการณ์การใช้งานที่ดีขึ้นแก่ผู้ใช้

สุดท้าย ให้คลิกปุ่ม "โทเค็นการเข้าถึง" ในช่อง "รับโทเค็น"

การดําเนินการนี้จะอัปเกรดโทเค็นคําขอที่ได้รับอนุญาต (ตามที่ระบุไว้โดยป้ายกํากับ "โทเค็นเพื่อการเข้าถึง") สีแดง

หากต้องการดึงข้อมูลโทเค็นใหม่ ให้คลิก "เริ่มใหม่" เพื่อเริ่มการเต้น 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"/>

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

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

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

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

บทสรุป

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

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

ทรัพยากร