OpenID และ OAuth ต่างกันอย่างไร

ฉันพยายามเข้าใจถึงความแตกต่างระหว่าง OpenID และ OAuth จริงหรือ บางทีมันเป็นสองสิ่งที่แยกจากกันโดยสิ้นเชิง?

OpenIDเป็นเรื่องของการรับรองความถูกต้อง (เช่นการพิสูจน์ว่าคุณเป็นใคร) OAuthเป็นเรื่องของการอนุญาต (เช่นเพื่อให้สามารถเข้าถึงฟังก์ชันการทำงาน / ข้อมูล / ฯลฯ โดยไม่ต้องจัดการกับการรับรองความถูกต้องดั้งเดิม)

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

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

มีสามวิธีในการเปรียบเทียบ OAuth และ OpenID:

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

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

OAuth ถูกสร้างขึ้นเพื่อลบความจำเป็นสำหรับผู้ใช้สามารถแบ่งปันรหัสผ่านของตนกับการใช้งานของบุคคลที่สาม จริงๆแล้วมันเริ่มต้นเป็นวิธีการแก้ปัญหา OpenID: ถ้าคุณสนับสนุน OpenID บนเว็บไซต์ของคุณคุณไม่สามารถใช้ข้อมูลประจำตัว HTTP พื้นฐาน (ชื่อผู้ใช้และรหัสผ่าน) เพื่อให้ API เพราะผู้ใช้ไม่มีรหัสผ่านในเว็บไซต์ของคุณ

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

2. คุณสมบัติ

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

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

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

3. การใช้งานทางเทคนิค

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

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

OpenID เป็น (ส่วนใหญ่) สำหรับการระบุตัวตน / การตรวจสอบเพื่อให้stackoverflow.comรู้ว่าฉันเป็นเจ้าของchris.boyle.name(หรือที่ใดก็ได้) และดังนั้นฉันจึงอาจเป็นคนคนเดียวกันที่เป็นเจ้าของchris.boyle.nameเมื่อวานนี้และได้รับคะแนนชื่อเสียงบางส่วน

OAuth ได้รับการออกแบบมาเพื่อให้สิทธิ์ในการดำเนินการในนามของคุณเพื่อให้stackoverflow.com(หรือที่ใดก็ได้) สามารถขออนุญาตพูด Tweet ในนามของคุณโดยอัตโนมัติโดยไม่ต้องรู้รหัสผ่าน Twitter ของคุณ

หลายคนยังคงเยี่ยมชมสิ่งนี้ดังนั้นนี่เป็นแผนภาพง่าย ๆ เพื่ออธิบาย

วิกิพีเดียมารยาท

OAuth

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

เช่น Flickr ใช้ OAuth เพื่อให้บริการของบุคคลที่สามในการโพสต์และแก้ไขภาพบุคคลในนามของพวกเขาโดยไม่ต้องให้ชื่อผู้ใช้และรหัสผ่านที่สั่นไหวของพวกเขา

OpenID

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

คือหนึ่งแสดงหนังสือเดินทางของพวกเขาที่สนามบินเพื่อรับรองความถูกต้อง (หรือพิสูจน์) บุคคลที่มีชื่ออยู่ในตั๋วที่พวกเขากำลังใช้อยู่

ใช้ OAuth หากผู้ใช้ของคุณอาจต้องการลงชื่อเข้าใช้ด้วย Facebook หรือ Twitter ใช้ OpenID หากผู้ใช้ของคุณเป็นคอที่เรียกใช้ผู้ให้บริการ OpenID ของตนเองเพราะพวกเขา "ไม่ต้องการให้ใครเป็นเจ้าของข้อมูลประจำตัว"

• OpenIDเป็นโปรโตคอลการรับรองความถูกต้องแบบเปิดมาตรฐานและการกระจายอำนาจควบคุมโดย OpenID Foundation
• OAuthเป็นมาตรฐานเปิดสำหรับการมอบหมายการเข้าถึง
• OpenID Connect (OIDC) รวมคุณสมบัติของ OpenID และ OAuth เช่นทำการรับรองความถูกต้องและการอนุญาต

OpenIDอยู่ในรูปแบบของURI ที่ไม่ซ้ำใครที่จัดการโดย "ผู้ให้บริการ OpenID" บางตัวเช่นผู้ให้บริการข้อมูลประจำตัว (idP)

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

OIDCใช้ง่าย JSON เว็บโทเคน (JWT) ซึ่งคุณสามารถได้รับใช้ไหลไปตามOAuth 2.0รายละเอียด OAuthจะเกี่ยวข้องโดยตรงกับOIDCตั้งแต่OIDCเป็นชั้นการตรวจสอบสร้างขึ้นบนOAuth 2.0

ตัวอย่างเช่นถ้าคุณเลือกที่จะลงชื่อเข้าใช้Auth0โดยใช้บัญชี Google ของคุณแล้วคุณใช้OIDC เมื่อคุณตรวจสอบสิทธิ์กับ Google สำเร็จแล้วและอนุญาตAuth0ให้เข้าถึงข้อมูลของคุณ Google จะส่งกลับไปที่ข้อมูลAuth0เกี่ยวกับผู้ใช้และการตรวจสอบสิทธิ์ที่ดำเนินการ ข้อมูลนี้ถูกส่งคืนในJSON Web Token (JWT) คุณจะได้รับโทเค็นการเข้าถึงและหากมีการร้องขอจะเป็นโทเค็น ID ประเภท Token : ที่มา: OpenID Connect

คล้ายคลึง :
ใช้ที่องค์กรหมายเลขบัตรประจำตัวประชาชนเพื่อวัตถุประสงค์และจะมีชิปจะเก็บรายละเอียดเกี่ยวกับพนักงานพร้อมกับการอนุญาตเช่น / ประตู / เข้าถึงวิทยาเขต ODC IDกระทำบัตรเป็นOIDCและชิปทำหน้าที่เป็นOAuth ตัวอย่างเพิ่มเติมและวิกิแบบฟอร์ม

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

OpenID มีไว้สำหรับการตรวจสอบความถูกต้องภายนอก ลูกค้ายอมรับการยืนยันตัวตนจากผู้ให้บริการใด ๆ (แม้ว่าลูกค้าจะมีอิสระในการขึ้นบัญชีขาวหรือบัญชีดำ)

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

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

ฉันเชื่อว่ามันสมเหตุสมผลแล้วที่จะทบทวนคำถามนี้ตามที่ระบุไว้ในความคิดเห็นการแนะนำของ OpenID Connect อาจทำให้เกิดความสับสนมากขึ้น

OpenID Connect เป็นโปรโตคอลการตรวจสอบความถูกต้องเช่น OpenID 1.0 / 2.0 แต่จริงๆแล้วมันถูกสร้างขึ้นบน OAuth 2.0 ดังนั้นคุณจะได้รับคุณสมบัติการอนุญาตพร้อมกับคุณสมบัติการตรวจสอบสิทธิ์ ความแตกต่างระหว่างคนทั้งสองนั้นได้รับการอธิบายอย่างละเอียดในบทความนี้ (ค่อนข้างใหม่ แต่สำคัญ): http://oauth.net/articles/authentication/

คำอธิบายความแตกต่างระหว่าง OpenID, OAuth, OpenID Connect:

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

ใน OpenID การรับรองความถูกต้องได้รับมอบหมาย: เซิร์ฟเวอร์ A ต้องการรับรองความถูกต้องของผู้ใช้ U แต่ข้อมูลประจำตัวของ U (เช่นชื่อและรหัสผ่านของ U) จะถูกส่งไปยังเซิร์ฟเวอร์อื่น B ​​ซึ่ง A ไว้วางใจ (อย่างน้อย แน่นอนเซิร์ฟเวอร์ B ทำให้แน่ใจว่า U เป็น U จริง ๆ แล้วบอกกับ A: "ตกลงนั่นคือ U ของแท้"

ใน OAuth การมอบอำนาจจะมอบหมาย: entity A ได้รับจากเอนทิตี B "สิทธิ์การเข้าถึง" ซึ่ง A สามารถแสดงต่อเซิร์ฟเวอร์ S เพื่อรับสิทธิ์การเข้าถึง B จึงสามารถส่งมอบคีย์การเข้าถึงชั่วคราวที่เฉพาะเจาะจงไปยัง A โดยไม่ให้พลังมากเกินไป คุณสามารถจินตนาการเซิร์ฟเวอร์ OAuth ในฐานะผู้เชี่ยวชาญหลักในโรงแรมขนาดใหญ่ เขามอบกุญแจให้พนักงานซึ่งเปิดประตูห้องที่พวกเขาควรจะเข้าไป แต่แต่ละคีย์นั้นมี จำกัด (มันไม่ได้ให้สิทธิ์การเข้าถึงทุกห้อง) นอกจากนี้กุญแจทำลายตัวเองหลังจากไม่กี่ชั่วโมง

ในระดับหนึ่งการให้สิทธิ์สามารถใช้ในการตรวจสอบสิทธิ์แบบหลอกบางอย่างบนพื้นฐานที่ว่าถ้าเอนทิตี A ได้รับจาก B รหัสการเข้าถึงผ่าน OAuth และแสดงให้เซิร์ฟเวอร์เห็นแล้วเซิร์ฟเวอร์ S อาจเป็นเซิร์ฟเวอร์ S อาจอนุมานว่า B รับรองความถูกต้องแล้ว สำคัญ. ดังนั้นบางคนใช้ OAuth ที่ควรใช้ OpenID สคีมานี้อาจจะใช่หรือไม่ก็ได้ แต่ฉันคิดว่าการรับรองความถูกต้องหลอกนี้สร้างความสับสนมากกว่าสิ่งใด OpenID Connect ทำเช่นนั้น: จะละเมิด OAuth ในโปรโตคอลการตรวจสอบสิทธิ์ ในการเปรียบเทียบโรงแรม: ถ้าฉันพบพนักงานที่ถูกอ้างว่าและบุคคลนั้นแสดงให้ฉันเห็นว่าเขามีกุญแจที่เปิดห้องของฉันฉันคิดว่านี่เป็นพนักงานที่แท้จริงบนพื้นฐานที่เจ้านายหลักไม่ได้ให้กุญแจแก่เขา ซึ่งเปิดห้องของฉันถ้าเขาไม่

(ที่มา)

OpenID Connect แตกต่างจาก OpenID 2.0 อย่างไร

OpenID Connect ทำงานหลายอย่างเช่นเดียวกับ OpenID 2.0 แต่ทำงานในลักษณะที่เป็นมิตรกับ API และสามารถใช้งานได้โดยแอปพลิเคชันดั้งเดิมและมือถือ OpenID Connect กำหนดกลไกที่เป็นทางเลือกสำหรับการลงชื่อและการเข้ารหัสที่มีประสิทธิภาพ ในขณะที่การรวมกันของ OAuth 1.0a และ OpenID 2.0 นั้นจำเป็นต้องมีส่วนเสริมในการเชื่อมต่อ OpenID ความสามารถของ OAuth 2.0 จะรวมเข้ากับโปรโตคอลเอง

(ที่มา)

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

นอกจากนี้การเชื่อมต่อ OpenID ยังทำให้ได้มาตรฐานสองสามอย่างที่ oauth2 เป็นตัวเลือก เช่นขอบเขตการค้นหาจุดสิ้นสุดและการลงทะเบียนแบบไดนามิกของลูกค้า

สิ่งนี้ทำให้ง่ายต่อการเขียนโค้ดที่ให้ผู้ใช้เลือกระหว่างผู้ให้บริการเอกลักษณ์หลายคน

(ที่มา)

OAuth 2.0 ของ Google

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

(ที่มา)

ส่วนขยายของคำถามมากกว่าคำตอบ แต่อาจเพิ่มมุมมองให้กับคำตอบทางเทคนิคที่ดีด้านบน ฉันเป็นโปรแกรมเมอร์ที่มีประสบการณ์ในหลาย ๆ ด้าน แต่เป็น noob ทั้งหมดในการเขียนโปรแกรมสำหรับเว็บ ตอนนี้พยายามสร้างแอปพลิเคชันบนเว็บโดยใช้ Zend Framework

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

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

ในความเป็นจริงเมื่อฉันไปโพสต์ "คำตอบ" นี้ไม่ได้เป็นสมาชิกในเวลานั้นฉันดูยาวและหนักที่ด้านล่างของหน้านี้ที่ตัวเลือกสำหรับการระบุตัวเอง ตัวเลือกสำหรับการใช้การเข้าสู่ระบบ OpenID หรือการได้รับถ้าฉันไม่มี แต่ไม่มีอะไรเกี่ยวกับ Twitter หรือ Facebook ดูเหมือนจะแนะนำว่า OAuth ไม่เพียงพอสำหรับงาน แต่จากนั้นฉันเปิดอีกหน้าต่างหนึ่งและค้นหาขั้นตอนการสมัครทั่วไปสำหรับ stackoverflow - และแท้จริงแล้วมีตัวเลือกการรับรองความถูกต้องของบุคคลที่สามซึ่งรวมถึง Facebook และ Twitter ในที่สุดฉันตัดสินใจใช้ google id ของฉัน (ซึ่งเป็น OpenID) ด้วยเหตุผลที่ว่าฉันไม่ต้องการให้สิทธิ์การเข้าถึงสแต็คโอเวอร์โฟลว์ในรายชื่อเพื่อนของฉันและสิ่งอื่นใดที่ Facebook ชอบแบ่งปันเกี่ยวกับผู้ใช้ - แต่อย่างน้อย

มันจะดีจริงๆถ้ามีคนสามารถโพสต์ข้อมูลหรือพอยน์เตอร์ให้กับข้อมูลเกี่ยวกับการสนับสนุนการตั้งค่าการอนุญาต 3 ส่วนหลายแบบนี้และวิธีที่คุณจัดการกับผู้ใช้ที่เพิกถอนการอนุญาตหรือสูญเสียสิทธิ์การเข้าถึงเว็บไซต์บุคคลที่สาม ฉันยังได้รับความประทับใจว่าชื่อผู้ใช้ของฉันที่นี่ระบุบัญชี stackoverflow ที่ไม่ซ้ำซึ่งฉันสามารถเข้าถึงด้วยการรับรองความถูกต้องเบื้องต้นหากฉันต้องการตั้งค่าและเข้าถึงบัญชีเดียวกันนี้ผ่านการรับรองความถูกต้องของบุคคลที่สามอื่น ๆ เข้าสู่ stackoverflow หากฉันลงชื่อเข้าใช้ google, facebook หรือ twitter ... ) เนื่องจากไซต์นี้กำลังทำอยู่บางคนที่นี่อาจมีข้อมูลเชิงลึกที่ดีเกี่ยวกับเรื่องนี้ :-)

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

OpenIDพิสูจน์ว่าคุณคือใคร

OAuthให้สิทธิ์การเข้าถึงคุณลักษณะที่มีให้โดยฝ่ายที่อนุญาต

ฉันกำลังทำงานกับ OAuth 2.0 และข้อกำหนดการเชื่อมต่อ OpenID ดังนั้นนี่คือความเข้าใจของฉัน: ก่อนหน้านี้พวกเขา:

1. OpenID เป็นการใช้งานที่เป็นกรรมสิทธิ์ของ Google ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามเช่นเว็บไซต์หนังสือพิมพ์คุณสามารถเข้าสู่ระบบโดยใช้ google และแสดงความคิดเห็นในบทความและอื่น ๆ เกี่ยวกับ usecases ดังนั้นโดยพื้นฐานแล้วไม่มีการแชร์รหัสผ่านไปยังเว็บไซต์หนังสือพิมพ์ ผมขอนิยามที่นี่วิธีนี้ในแนวทางขององค์กรเรียกว่าสหพันธ์ ในสหพันธรัฐคุณมีเซิร์ฟเวอร์ที่คุณรับรองความถูกต้องและอนุญาต (เรียกว่า IDP, ผู้ให้บริการข้อมูลประจำตัว) และโดยทั่วไปแล้วเป็นผู้ดูแลข้อมูลรับรองผู้ใช้ แอปพลิเคชันไคลเอนต์ที่คุณมีธุรกิจเรียกว่า SP หรือผู้ให้บริการ หากเรากลับไปที่ตัวอย่างเว็บไซต์หนังสือพิมพ์ฉบับเดียวกันเว็บไซต์หนังสือพิมพ์คือ SP ที่นี่และ Google คือ IDP ในองค์กรปัญหานี้ได้รับการแก้ไขก่อนหน้านี้โดยใช้ SAML ครั้งนั้น XML ใช้เพื่อปกครองอุตสาหกรรมซอฟต์แวร์ ดังนั้นจากเว็บเซอร์ไปจนถึงการกำหนดค่าทุกอย่างที่เคยไป XML ดังนั้นเราจึงมี SAML

2. OAuth: OAuth เห็นว่าการเกิดขึ้นนั้นเป็นมาตรฐานในการมองหาแนวทางกรรมสิทธิ์เหล่านี้ดังนั้นเราจึงมี OAuth 1.o เป็นมาตรฐาน แต่ให้การอนุญาตเท่านั้น มีคนไม่มากนักที่สังเกตเห็น แต่มันก็เริ่มยกตัวอย่างเช่น จากนั้นเรามี OAuth 2.0 ในปี 2012 CTOs สถาปนิกเริ่มให้ความสนใจจริง ๆ เนื่องจากโลกกำลังเคลื่อนไปสู่คลาวด์คอมพิวติ้งและด้วยอุปกรณ์คอมพิวเตอร์ที่เคลื่อนไปทางมือถือและอุปกรณ์อื่น ๆ OAuth มองว่าเป็นการแก้ปัญหาที่สำคัญซึ่งลูกค้าซอฟต์แวร์อาจให้บริการ IDP กับ บริษัท หนึ่งและมีบริการมากมายจากผู้ขายที่แตกต่างกันเช่น salesforce, SAP และอื่น ๆ ดังนั้นการรวมกันที่นี่ดูเหมือนเป็นปัญหาใหญ่สำหรับสหพันธ์โดยใช้ SAML ลองสำรวจ OAuth 2.o Ohh พลาดจุดสำคัญที่ช่วงเวลานี้ Google รู้สึกว่า OAuth ไม่จริง '

   OAuth 2.o ไม่ได้พูดอย่างชัดเจนว่าจะมีการลงทะเบียนลูกค้าอย่างไร ไม่ได้พูดถึงสิ่งใดเกี่ยวกับการทำงานร่วมกันระหว่าง SP (เซิร์ฟเวอร์ทรัพยากร) และแอปพลิเคชันไคลเอนต์ (เช่น Analytics Server ที่ให้ข้อมูลคือเซิร์ฟเวอร์ทรัพยากรและแอปพลิเคชันที่แสดงข้อมูลนั้นเป็นลูกค้า)

ในทางเทคนิคมีคำตอบที่ยอดเยี่ยมอยู่แล้วฉันคิดว่าจะให้มุมมองวิวัฒนาการโดยย่อ

OpenId ใช้ OAuth เพื่อจัดการกับการพิสูจน์ตัวตน

โดยการเปรียบเทียบดูเหมือนว่า. NET พึ่งพา Windows API คุณสามารถโทรหา Windows API ได้โดยตรง แต่มีข้อโต้แย้งที่กว้างซับซ้อนและมีวิธีการมากมายคุณสามารถสร้างข้อผิดพลาด / ข้อบกพร่อง / ปัญหาด้านความปลอดภัยได้อย่างง่ายดาย

เหมือนกันกับ OpenId / OAuth OpenId อาศัย OAuth เพื่อจัดการการพิสูจน์ตัวตน แต่กำหนดโทเค็นเฉพาะ (Id_token) ลายเซ็นดิจิทัลและโฟลว์เฉพาะ

ฉันต้องการจะพูดถึงแง่มุมที่เฉพาะเจาะจงของคำถามนี้ตามที่บันทึกไว้ในความคิดเห็นนี้:

OAuth: ก่อนที่จะอนุญาตให้เข้าถึงคุณลักษณะบางอย่างต้องทำการตรวจสอบสิทธิ์ใช่ไหม ดังนั้น OAuth = OpenId + ให้สิทธิ์การเข้าถึงคุณลักษณะบางอย่างอย่างไร - Hassan Makarov 21 มิ.ย. เวลา 1:57 น

ใช่และไม่. คำตอบนั้นบอบบางดังนั้นทนกับฉัน

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

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

อย่าทำผิดพลาด

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

หากต้องการจัดการการตรวจสอบสิทธิ์คุณอาจต้องการค้นหา OpenID Connect ซึ่งเป็นอีกชั้นหนึ่งที่อยู่ด้านบนสุดของรากฐานที่กำหนดโดย OAuth 2.0 นี่คือคำพูดที่รวบรวม (ในความคิดของฉัน) จุดที่สำคัญที่สุดเกี่ยวกับ OpenID Connect (จากhttps://oauth.net/articles/authentication/ ):

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

OpenID Connect นั้นสร้างขึ้นโดยตรงบน OAuth 2.0 และในกรณีส่วนใหญ่จะถูกปรับใช้พร้อมกับ (หรือด้านบน) โครงสร้างพื้นฐาน OAuth OpenID Connect ยังใช้ชุดข้อมูลจำเพาะการเซ็นชื่อและการเข้ารหัส (JOSE) ของ JSON สำหรับการพกพาข้อมูลที่เซ็นชื่อและเข้ารหัสไว้ในที่ต่างๆ ในความเป็นจริงการปรับใช้ OAuth 2.0 พร้อมความสามารถของ JOSE นั้นเป็นวิธีการที่ยาวนานในการกำหนดระบบ OpenID Connect ที่เข้ากันได้อย่างสมบูรณ์และ delta ระหว่างทั้งสองนั้นค่อนข้างเล็ก แต่เดลต้าที่สร้างความแตกต่างใหญ่และ OpenID Connect จัดการเพื่อหลีกเลี่ยงข้อผิดพลาดที่กล่าวถึงข้างต้นโดยการเพิ่มองค์ประกอบที่สำคัญหลายรายการไปยังฐาน OAuth: [... ]

จากนั้นเอกสารจะอธิบายถึงโทเค็น ID (และอื่น ๆ ) และจุดสิ้นสุด UserInfo อดีตให้ชุดของการเรียกร้อง (ที่คุณเป็นเมื่อโทเค็นออก ฯลฯ และอาจเป็นลายเซ็นเพื่อตรวจสอบความถูกต้องของโทเค็นผ่านกุญแจสาธารณะที่เผยแพร่โดยไม่ต้องถามบริการต้นน้ำ) และหลังให้ วิธีการเช่นขอชื่อ / นามสกุลผู้ใช้อีเมลและบิตของข้อมูลที่คล้ายกันทั้งหมดในลักษณะที่เป็นมาตรฐาน (ตรงข้ามกับส่วนขยายโฆษณาเฉพาะกิจไปยัง OAuth ที่ผู้คนใช้ก่อนสิ่งที่เป็นมาตรฐานของ OpenID Connect)

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

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

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

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

OAuth 2.0 เป็นโปรโตคอลความปลอดภัย มันไม่ได้เป็นของแท้รับรองความถูกต้อง NOR โปรโตคอลการอนุญาต

การรับรองความถูกต้องโดยนิยามคำตอบสองคำถาม

1. ใครคือผู้ใช้?
2. ปัจจุบันผู้ใช้อยู่ในระบบหรือไม่?

OAuth 2.0 มีประเภทการให้สิทธิ์ต่อไปนี้

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

ทั้ง 4 มีสิ่งหนึ่งที่เหมือนกันคือ access_token สิ่งประดิษฐ์ที่สามารถใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการป้องกัน

access_token ไม่ได้ให้คำตอบสำหรับคำถาม 2 ข้อที่โปรโตคอล "การรับรองความถูกต้อง" ต้องตอบ

ตัวอย่างเพื่ออธิบาย Oauth 2.0 (เครดิต: OAuth 2 ในการดำเนินการนิงสิ่งพิมพ์)

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

หากคุณต้องการการรับรองความถูกต้องคุณสามารถไปที่ OpenID Connect ซึ่งให้ "id_token" นอกเหนือจาก access_token ซึ่งจะตอบคำถามที่โปรโตคอลการตรวจสอบสิทธิ์ทุกตัวต้องตอบ

OAuth สร้างการรับรองความถูกต้องด้านบนของการให้สิทธิ์: ผู้ใช้มอบสิทธิ์การเข้าถึงข้อมูลประจำตัวของตนให้กับแอปพลิเคชันซึ่งจากนั้นจะกลายเป็น Consumer ของ identity API ซึ่งจะเป็นการค้นหาว่าใครอนุญาตลูกค้าในครั้งแรกhttp://oauth.net/ บทความ / / ตรวจสอบ