![](https://developers.google.cn/static/gdata/articles/support/oauth_gdata/oauthLogo.png?authuser=7&hl=th)
กันยายน 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
- "การเต้น OAuth"
คําที่ไม่เป็นทางการของฉันเพื่ออธิบายกระบวนการตรวจสอบสิทธิ์/การให้สิทธิ์ OAuth ทั้งหมด
- (OAuth) โทเค็นคําขอ
โทเค็นเริ่มต้นที่ช่วยให้ Google ทราบว่าแอปพลิเคชันของคุณขอเข้าถึง Google Data API อันใดอันหนึ่ง ขั้นตอนที่ 2 ของการเต้น OAuth คือการให้ผู้ใช้ให้สิทธิ์เข้าถึงข้อมูลด้วยตนเอง หากขั้นตอนนี้สําเร็จ โทเค็นคําขอจะได้รับอนุญาต
- (OAuth) โทเค็นเพื่อการเข้าถึง
ขั้นตอนสุดท้ายของการเต้นคือการแลกเปลี่ยนโทเค็นคําขอที่ได้รับอนุญาตกับโทเค็นเพื่อการเข้าถึง เมื่อแอปพลิเคชันมีโทเค็นนี้ ผู้ใช้ไม่จําเป็นต้องดําเนินการเข้าสู่ระบบ OAuth อีกครั้ง เว้นแต่โทเค็นจะถูกเพิกถอน
ความคล้ายคลึงกับ AuthSub:
โทเค็นเพื่อการเข้าถึง OAuth จะเหมือนกับโทเค็นเซสชัน AuthSub ที่ปลอดภัย - ปลายทาง (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
- ผู้ให้บริการ (OAuth)
ในกรณีที่ใช้ Google Data API ผู้ให้บริการนี้คือ Google โดยทั่วไป ผู้ให้บริการจะใช้เพื่ออธิบายเว็บไซต์หรือบริการเว็บที่ใช้ปลายทาง OAuth อีกตัวอย่างหนึ่งของผู้ให้บริการ OAuth คือ MySpace
- (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
การทำงานของตัวเลือกนี้
- แสดงขั้นตอนการตรวจสอบสิทธิ์ OAuth: กําลังดึงข้อมูลโทเค็นคําขอ ให้สิทธิ์โทเค็น และอัปเกรดเป็นโทเค็นเพื่อการเข้าถึง
- แสดงสตริงฐานลายเซ็นที่ถูกต้องสําหรับคําขอแต่ละรายการ
- แสดงส่วนหัว
Authorization
ที่ถูกต้องสําหรับคําขอแต่ละรายการ - สาธิตวิธีใช้
oauth_token
เพื่อโต้ตอบกับฟีดข้อมูล Google ที่ตรวจสอบสิทธิ์แล้ว ข้อมูลGET
/POST
/PUT
/DELETE
ได้ - ดูฟีดที่ตรวจสอบสิทธิ์แล้วได้โดยตรงในเบราว์เซอร์
- ช่วยให้คุณสามารถทดสอบ
oauth_consumer_key
(โดเมนที่จดทะเบียน) ของคุณเองและคีย์ส่วนตัว - ค้นพบบริการฟีดข้อมูล Google ที่พร้อมใช้งานสําหรับ
oauth_token
เรียกใช้การสาธิต
ขั้นตอนที่ 1: เลือกขอบเขตก่อนอื่น ให้เลือก API ที่ต้องการใช้โดยเลือกขอบเขตอย่างน้อย 1 รายการ ในการสาธิตนี้ ฉันขอโทเค็นที่จะใช้กับ Blogger และ Google Contacts ความคล้ายคลึงกับ AuthSub: |
![]() |
ขั้นตอนที่ 2: แก้ไขพารามิเตอร์ OAuth และการตั้งค่าสําหรับตอนนี้ อย่าแก้ไขการตั้งค่าในช่อง "แก้ไขพารามิเตอร์ OAuth" ภายหลัง คุณสามารถทดสอบด้วยคีย์ส่วนตัวของคุณเองได้โดยเปลี่ยน หมายเหตุ: นอกเหนือจาก ความแตกต่างจาก AuthSub: |
![]() |
ขั้นตอนที่ 3-5: รับโทเค็นเพื่อการเข้าถึงการรับโทเค็นเพื่อการเข้าถึง OAuth มีอยู่ 3 ขั้นตอน ขั้นตอนแรกคือเรียกข้อมูลโทเค็นคําขอ วิธีนี้ช่วยให้ Google ทราบว่าแอปพลิเคชันของคุณกําลังเริ่มต้นการเต้น OAuth ขั้นแรก ให้คลิกปุ่ม "ขอโทเค็น" ในช่อง "รับโทเค็น" ช่องบางช่องจะมีข้อมูล
|
![]() ![]() |
จากนั้น ให้คลิกปุ่ม "ให้สิทธิ์" ในช่อง "รับโทเค็น" ในหน้าการให้สิทธิ์นี้ ให้คลิกปุ่ม "ให้สิทธิ์เข้าถึง" เพื่อให้สิทธิ์โทเค็นคําขอ แล้วเปลี่ยนเส้นทางกลับไปยัง OAuth Playground ความคล้ายคลึงกันของ AuthSub: ความแตกต่างจาก AuthSub: เคล็ดลับ: เราขอแนะนําให้ระบุ URL |
![]() |
สุดท้าย ให้คลิกปุ่ม "โทเค็นการเข้าถึง" ในช่อง "รับโทเค็น" การดําเนินการนี้จะอัปเกรดโทเค็นคําขอที่ได้รับอนุญาต (ตามที่ระบุไว้โดยป้ายกํากับ "โทเค็นเพื่อการเข้าถึง") สีแดง หากต้องการดึงข้อมูลโทเค็นใหม่ ให้คลิก "เริ่มใหม่" เพื่อเริ่มการเต้น OAuth อีกครั้ง ตอนนี้เราสามารถทําสิ่งที่น่าสนใจได้แล้ว |
![]() |
การใช้โทเค็นเพื่อการเข้าถึง
ตอนนี้คุณก็พร้อมที่จะค้นหาฟีด แทรก อัปเดต หรือลบข้อมูลแล้ว โปรดใช้ความระมัดระวังเมื่อใช้เมธอด HTTP 3 รายการสุดท้ายเมื่อคุณทํางานกับข้อมูลจริง
เคล็ดลับ: หากต้องการดูฟีดที่พร้อมสําหรับโทเค็นเพื่อการเข้าถึง ให้คลิกปุ่ม "ฟีดที่พร้อมใช้งาน"
ตัวอย่างคําค้นหาคือ GET http://www.blogger.com/feeds/1982051675575479214/posts/default?max-results=3
![](https://developers.google.cn/static/gdata/articles/support/oauth_gdata/blogger_example.png?authuser=7&hl=th)
ตัวอย่างนี้แสดงโพสต์ไม่เกิน 3 โพสต์ในบล็อกใดบล็อกหนึ่ง นอกจากนี้ คุณยังดูฟีด/รายการส่งคืนได้โดยตรงในเบราว์เซอร์โดยคลิกลิงก์ "ดูในเบราว์เซอร์" ใต้บริเวณที่ไฮไลต์ไวยากรณ์
ตัวอย่าง: วิธีอัปเดตโพสต์
- ค้นหาองค์ประกอบ
<link>
ที่มี rel="edit" ในโพสต์ที่ต้องการอัปเดต ซึ่งควรมีลักษณะดังนี้<link rel="edit" href="http://www.blogger.com/feeds/1982051675575479214/posts/default/8138973184593279875"/>
วาง URL href ในอินพุต "ป้อนฟีดข้อมูล Google"
- คัดลอก XML ของรายการที่มีอยู่โดยคลิก "ดูข้อความธรรมดา" ที่ด้านบนของแผงที่ไฮไลต์ไวยากรณ์ คัดลอกเฉพาะเนื้อหาการตอบกลับ แต่ไม่คัดลอกส่วนหัว
- เปลี่ยนเมนูแบบเลื่อนลงของวิธี HTTP เป็น
PUT
- คลิก "ป้อนข้อมูลโพสต์" ด้านล่างแบบเลื่อนลงแล้ววาง
<entry>
XML ลงในป๊อปอัป - คลิกปุ่ม "เรียกใช้"
เซิร์ฟเวอร์จะตอบกลับด้วย 200 OK
เคล็ดลับ: ให้ยกเลิกการเลือกช่องทําเครื่องหมาย "ไฮไลต์ไวยากรณ์ใช่ไหม" แทนการคัดลอกลิงก์ edit
ด้วยตนเอง หลังข้อความค้นหา คุณจะสามารถคลิกลิงก์ภายในเนื้อหาการตอบกลับ XML ได้
บทสรุป
เทคโนโลยีอย่าง AtomPub/Atom Publishing Protocol (โปรโตคอลพื้นฐานของ Google Data API) และ OAuth ช่วยขับเคลื่อนเว็บให้ก้าวไปข้างหน้า เมื่อมีเว็บไซต์เริ่มใช้มาตรฐานเหล่านี้มากขึ้นเรื่อยๆ เราจึงเป็นผู้ชนะ การสร้างแอปแบบฆาตกรรมก็แทบจะไม่น่ากังวลอีกต่อไป
หากมีข้อสงสัยหรือความคิดเห็นเกี่ยวกับ OAuth Playground หรือใช้ OAuth กับ Google API โปรดไปที่ฟอรัมการสนับสนุนของ G Suite API และ Marketplace API