OpenIDเป็นมาตรฐานเปิดและโปรโตคอลการตรวจสอบสิทธิ์แบบกระจายศูนย์ ที่ได้รับการส่งเสริมโดย มูลนิธิ OpenID ซึ่ง เป็นองค์กร ไม่แสวงหาผลกำไร OpenID อนุญาตให้ผู้ใช้ได้รับการตรวจสอบสิทธิ์โดยเว็บไซต์ที่ให้ความร่วมมือ (เรียกว่าฝ่ายที่พึ่งพาหรือ RP) โดยใช้บริการผู้ให้บริการข้อมูลประจำตัวบุคคลที่สาม (IDP) ซึ่งช่วยลดความจำเป็นที่ผู้ดูแลเว็บ จะต้องจัดหาระบบล็อกอิน เฉพาะกิจของตนเองและอนุญาตให้ผู้ใช้ล็อกอินเข้าสู่เว็บไซต์ที่ไม่เกี่ยวข้องกันหลายแห่งโดยไม่ต้องมีข้อมูลประจำตัวและรหัสผ่านแยกต่างหากสำหรับแต่ละเว็บไซต์^{[ 1 ]}ผู้ใช้สร้างบัญชีโดยเลือกผู้ให้บริการข้อมูลประจำตัว OpenID ^{[ 1 ]}จากนั้นใช้บัญชีเหล่านั้นเพื่อลงชื่อเข้าใช้เว็บไซต์ใดๆ ที่ยอมรับการตรวจสอบสิทธิ์ OpenID องค์กรขนาดใหญ่หลายแห่งออกหรือยอมรับ OpenID บนเว็บไซต์ของตน^{[ 2 ]}

มาตรฐาน OpenID ให้กรอบการทำงานสำหรับการสื่อสารที่ต้องเกิดขึ้นระหว่างผู้ให้บริการข้อมูลประจำตัวและผู้รับ OpenID (“ ฝ่ายที่พึ่งพา ”) ^{[ 3 ]}ส่วนขยายของมาตรฐาน (OpenID Attribute Exchange) ช่วยอำนวยความสะดวกในการถ่ายโอนคุณลักษณะของผู้ใช้ เช่น ชื่อและเพศ จากผู้ให้บริการข้อมูลประจำตัว OpenID ไปยังฝ่ายที่พึ่งพา (ฝ่ายที่พึ่งพาแต่ละฝ่ายอาจร้องขอชุดคุณลักษณะที่แตกต่างกัน ขึ้นอยู่กับความต้องการของตน) ^{[ 4 ]}โปรโตคอล OpenID ไม่ได้พึ่งพาหน่วยงานกลางในการตรวจสอบความถูกต้องของข้อมูลประจำตัวของผู้ใช้ ยิ่งไปกว่านั้น ทั้งบริการและมาตรฐาน OpenID ไม่สามารถกำหนดวิธีการเฉพาะในการตรวจสอบความถูกต้องของผู้ใช้ได้ ทำให้สามารถใช้วิธีการต่างๆ ได้ตั้งแต่แบบทั่วไป (เช่น รหัสผ่าน) ไปจนถึงแบบใหม่ (เช่นสมาร์ทการ์ดหรือไบโอเมตริก)

OpenID เวอร์ชันสุดท้ายคือ OpenID 2.0 ซึ่งได้รับการสรุปและเผยแพร่ในเดือนธันวาคม พ.ศ. 2550 ^{[ 5 ]}คำว่าOpenIDอาจหมายถึงตัวระบุตามที่ระบุไว้ในมาตรฐาน OpenID ตัวระบุเหล่านี้มีรูปแบบเป็นตัวระบุทรัพยากรสากล ที่ไม่ซ้ำกัน (URI) และได้รับการจัดการโดย "ผู้ให้บริการ OpenID" บางรายที่จัดการการตรวจสอบสิทธิ์^{[ 1 ]}

ณ เดือนมีนาคม พ.ศ. 2559 มีบัญชีที่เปิดใช้งาน OpenID มากกว่า 1 พันล้านบัญชีบนอินเทอร์เน็ต (ดูด้านล่าง) และมีเว็บไซต์ประมาณ 1,100,934 แห่งที่รวมการสนับสนุนผู้บริโภค OpenID ไว้ด้วย: ^{[ 6 ]} AOL , Flickr , Google , Amazon.com , Canonical (ชื่อผู้ให้บริการUbuntu One ), LiveJournal , Microsoft (ชื่อผู้ให้บริการบัญชี Microsoft ), Mixi , Myspace , Novell , OpenStreetMap , Orange , Sears , Sun , Telecom Italia , Universal Music Group , VeriSign , WordPress , Yahoo!, BBC , ^{[ 7 ]} IBM , ^{[ 8 ]} PayPal , ^{[ 9 ]}และSteam , ^{[ 10 ]} แม้ว่าบางองค์กรเหล่านั้น จะมีระบบการจัดการการตรวจสอบสิทธิ์ของตนเองด้วยก็ตาม

เฟซบุ๊กเคยใช้ OpenID ในอดีต แต่ได้เปลี่ยนไปใช้Facebook Connect [ ^{11 ] บล็อก}เกอร์ก็เคยใช้ OpenID เช่นกัน แต่ตั้งแต่เดือนพฤษภาคม 2018 ก็ไม่รองรับอีกต่อไป^{[ 12 ]}

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

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

OpenID สร้างขึ้นบนพื้นฐานของมาตรฐานที่มีอยู่หลายอย่าง รวมถึง HTTP, HTML และ XML OpenID อาศัยเทคโนโลยีหลายอย่าง รวมถึงกลไกการค้นหาที่ช่วยให้เว็บไซต์สามารถค้นหา IdP ที่เกี่ยวข้องกับ OpenID เฉพาะเจาะจง ตลอดจนกลไกการรักษาความปลอดภัยเพื่อป้องกันการฟิชชิ่งและการโจมตีอื่นๆ^{[ 13 ]}

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

OpenID ได้รับการใช้งานอย่างแพร่หลายโดยเว็บไซต์และผู้ให้บริการรายใหญ่หลายแห่ง รวมถึง Google, Yahoo! และ PayPal นอกจากนี้ โปรโตคอลนี้ยังถูกใช้โดยโครงการและเฟรมเวิร์กโอเพนซอร์สหลายแห่ง เช่น Ruby on Rails และ Django

ผู้ใช้ปลายทางโต้ตอบกับฝ่ายที่พึ่งพา (เช่น เว็บไซต์) ซึ่งมีตัวเลือกให้ระบุ OpenID เพื่อวัตถุประสงค์ในการตรวจสอบสิทธิ์ โดยทั่วไปผู้ใช้ปลายทางจะต้องลงทะเบียน OpenID (เช่นalice.openid.example.org) กับผู้ให้บริการ OpenID (เช่นopenid.example.org) ไว้ก่อนหน้านี้ ^{[ 1 ]}

โดยทั่วไปแล้ว ฝ่ายที่พึ่งพาจะแปลง OpenID ให้เป็นรูปแบบ URL มาตรฐาน (เช่นhttp://alice.openid.example.org/)

• ใน OpenID 1.0 ฝ่ายที่พึ่งพาจะร้องขอทรัพยากร HTML ที่ระบุโดย URL และอ่านแท็กลิงก์ HTML เพื่อค้นหา URL ของผู้ให้บริการ OpenID (เช่นhttp://openid.example.org/openid-auth.php) ฝ่ายที่พึ่งพายังค้นหาได้ว่าจะใช้ข้อมูลประจำตัวที่ได้รับมอบหมาย หรือไม่ (ดูด้านล่าง)
• ใน OpenID 2.0 ฝ่ายที่พึ่งพาจะค้นหา URL ของผู้ให้บริการ OpenID โดยการร้องขอเอกสารXRDS (หรือที่เรียกว่าเอกสารYadis ) ด้วยประเภทเนื้อหาapplication/xrds+xmlเอกสารนี้อาจมีอยู่ใน URL เป้าหมายและพร้อมใช้งานสำหรับXRIเป้าหมาย เสมอ

ผู้ใช้งานสามารถติดต่อสื่อสารกับผู้ให้บริการ OpenID ได้สองวิธี:

• checkid_immediateซึ่งในกรณีนี้ ฝ่ายที่พึ่งพาจะร้องขอให้ผู้ให้บริการ OpenID ไม่ต้องโต้ตอบกับผู้ใช้ปลายทาง การสื่อสารทั้งหมดจะถูกส่งผ่านตัวแทนผู้ใช้ของผู้ใช้ปลายทางโดยไม่ต้องแจ้งให้ผู้ใช้ปลายทางทราบโดยตรง
• checkid_setupซึ่งผู้ใช้ปลายทางจะสื่อสารกับผู้ให้บริการ OpenID ผ่านทาง user-agent เดียวกันกับที่ใช้ในการเข้าถึงฝ่ายที่พึ่งพา

โหมดcheckid_immediateการทำงานจะเปลี่ยนกลับไปใช้checkid_setupโหมดเดิมหากไม่สามารถดำเนินการแบบอัตโนมัติได้

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

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

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

หากผู้ใช้ปลายทางยอมรับคำขอของผู้ให้บริการ OpenID เพื่อเชื่อถือฝ่ายที่พึ่งพา ระบบจะเปลี่ยนเส้นทางตัวแทนผู้ใช้กลับไปยังฝ่ายที่พึ่งพาพร้อมกับข้อมูลประจำตัวของผู้ใช้ปลายทาง จากนั้นฝ่ายที่พึ่งพาจะต้องยืนยันว่าข้อมูลประจำตัวนั้นมาจากผู้ให้บริการ OpenID จริงๆ หากฝ่ายที่พึ่งพาและผู้ให้บริการ OpenID ได้สร้างรหัสลับร่วมกันไว้ก่อนหน้านี้ ฝ่ายที่พึ่งพาสามารถตรวจสอบตัวตนของผู้ให้บริการ OpenID ได้โดยการเปรียบเทียบสำเนารหัสลับร่วมกันของตนกับรหัสลับที่ได้รับพร้อมกับข้อมูลประจำตัวของผู้ใช้ปลายทาง ฝ่ายที่พึ่งพาประเภทนี้เรียกว่ามีสถานะ (stateful)เนื่องจากจะเก็บรหัสลับร่วมกันไว้ระหว่างเซสชัน ในทางตรงกันข้าม ฝ่ายที่พึ่งพา แบบไม่มีสถานะ (stateless ) หรือ แบบโง่ ( dumb)จะต้องทำการร้องขอเบื้องหลังอีกครั้งหนึ่ง ( check_authentication) เพื่อให้แน่ใจว่าข้อมูลนั้นมาจากผู้ให้บริการ OpenID จริงๆ

หลังจากตรวจสอบ OpenID เรียบร้อยแล้ว การตรวจสอบสิทธิ์จะถือว่าสำเร็จ และผู้ใช้ปลายทางจะถือว่าได้เข้าสู่ระบบในระบบของผู้ให้บริการภายใต้ข้อมูลประจำตัวที่ระบุโดย OpenID ที่กำหนด (เช่นalice.openid.example.org) โดยทั่วไปแล้ว ระบบของผู้ให้บริการจะจัดเก็บ OpenID ของผู้ใช้ปลายทางพร้อมกับข้อมูลเซสชันอื่นๆ ของผู้ใช้ปลายทาง

เพื่อให้ได้ URLที่เปิดใช้งาน OpenID ซึ่งสามารถใช้เข้าสู่ระบบเว็บไซต์ที่เปิดใช้งาน OpenID ได้ ผู้ใช้จะต้องลงทะเบียนตัวระบุ OpenID กับผู้ให้บริการยืนยันตัวตน ผู้ให้บริการยืนยันตัวตนจะให้ความสามารถในการลงทะเบียน URL (โดยทั่วไปจะเป็นโดเมนระดับที่สาม เช่น username.example.com) ซึ่งจะได้รับการกำหนดค่าด้วยบริการตรวจสอบสิทธิ์ OpenID โดยอัตโนมัติ

เมื่อลงทะเบียน OpenID แล้ว ผู้ใช้ยังสามารถใช้ URL ที่มีอยู่ซึ่งอยู่ภายใต้การควบคุมของตนเอง (เช่น บล็อกหรือหน้าแรก) เป็นนามแฝงหรือ "ข้อมูลประจำตัวที่ได้รับมอบหมาย" ได้ พวกเขาเพียงแค่แทรกแท็ก OpenID ที่เหมาะสมลงในHTML ^{[ 14 ]}หรือให้บริการเอกสารYadis ^{[ 15 ]}

ตั้งแต่ OpenID Authentication เวอร์ชัน 2.0 (และบางเวอร์ชัน 1.1) เป็นต้นไป มีตัวระบุสองประเภทที่สามารถใช้กับ OpenID ได้ ได้แก่ URL และ XRI

XRIsเป็นรูปแบบใหม่ของตัวระบุอินเทอร์เน็ต ที่ออกแบบมาโดยเฉพาะสำหรับข้อมูลประจำตัวดิจิทัลข้ามโดเมน ตัวอย่างเช่น XRIs มีสองรูปแบบ ได้แก่i-namesและi-numbersซึ่งโดยปกติจะลงทะเบียนพร้อมกันในฐานะคำพ้องความหมาย i-names สามารถกำหนดใหม่ได้ (เช่นเดียวกับชื่อโดเมน) ในขณะที่ i-numbers ไม่สามารถกำหนดใหม่ได้ เมื่อใช้ XRI i-name เป็นตัวระบุ OpenID ระบบจะแปลงเป็น i-number ที่มีความหมายเหมือนกันทันที (องค์ประกอบ CanonicalID ของเอกสาร XRDS) i-number นี้คือตัวระบุ OpenID ที่จัดเก็บโดยฝ่ายที่พึ่งพา ด้วยวิธีนี้ ทั้งผู้ใช้และฝ่ายที่พึ่งพาจะได้รับการปกป้องจากการที่ข้อมูลประจำตัว OpenID ของผู้ใช้ปลายทางถูกบุคคลอื่นเข้าครอบครอง ซึ่งอาจเกิดขึ้นได้กับ URL ที่อิงตามชื่อ DNS ที่สามารถกำหนดใหม่ได้

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

คณะกรรมการบริหารของมูลนิธิ OpenID ประกอบด้วยสมาชิกคณะกรรมการจากชุมชน 6 คน และสมาชิกคณะกรรมการบริษัท 8 คน: ^{[ 16 ]}

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

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

เครื่องหมายการค้า OpenID ในสหรัฐอเมริกาถูกโอนให้กับมูลนิธิ OpenID ในเดือนมีนาคม พ.ศ. 2551 ^{[ 17 ]}ก่อนหน้านี้ NetMesh Inc. ได้จดทะเบียนเครื่องหมายการค้านี้ไว้ก่อนที่มูลนิธิ OpenID จะเริ่มดำเนินการ^{[ 18 ] [ 19 ]}ในยุโรป ณ วันที่ 31 สิงหาคม พ.ศ. 2550 เครื่องหมายการค้า OpenID ได้รับการจดทะเบียนให้กับมูลนิธิ OpenID Europe ^{[ 20 ]}

โลโก้ OpenID ออกแบบโดย Randy "ydnar" Reddig ซึ่งในปี 2548 ได้แสดงแผนการที่จะโอนสิทธิ์ให้กับองค์กร OpenID ^{[ 21 ]}

นับตั้งแต่มีการประกาศ OpenID ครั้งแรก เว็บไซต์อย่างเป็นทางการได้ระบุไว้ว่า: ^{[ 22 ]}

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

Sun Microsystems , VeriSignและบริษัทขนาดเล็กจำนวนหนึ่งที่เกี่ยวข้องกับ OpenID ได้ออกข้อตกลงไม่ฟ้องร้อง สิทธิบัตร ที่ครอบคลุมข้อกำหนด OpenID 1.1 ข้อตกลงดังกล่าวระบุว่าบริษัทจะไม่ฟ้องร้องสิทธิบัตรใด ๆ ของตนต่อการใช้งาน OpenID และจะเพิกถอนคำมั่นสัญญาจากผู้ใดก็ตามที่ข่มขู่หรือฟ้องร้องสิทธิบัตรต่อผู้ใช้งาน OpenID ^{[ 23 ] [ 24 ]}

ในเดือนมีนาคม พ.ศ. 2555 เอกสารวิจัย^{[ 25 ]}รายงานปัญหาด้านความปลอดภัยทั่วไปสองประการใน OpenID ปัญหาทั้งสองประการนี้ทำให้ผู้โจมตีสามารถลงชื่อเข้าใช้บัญชีฝ่ายที่พึ่งพาของเหยื่อได้ สำหรับปัญหาแรก OpenID และ Google (ผู้ให้บริการข้อมูลประจำตัวของ OpenID) ต่างก็เผยแพร่คำแนะนำด้านความปลอดภัยเพื่อแก้ไขปัญหานี้^{[ 26 ] [ 27 ]}คำแนะนำของ Google ระบุว่า "ผู้โจมตีสามารถปลอมแปลงคำขอ OpenID ที่ไม่ได้ขอที่อยู่อีเมลของผู้ใช้ จากนั้นแทรกที่อยู่อีเมลที่ไม่ได้ลงนามลงในคำตอบของ IDP หากผู้โจมตีส่งต่อคำตอบนี้ไปยังเว็บไซต์ที่ไม่สังเกตเห็นว่าคุณลักษณะนี้ไม่ได้ลงนาม เว็บไซต์อาจถูกหลอกให้ล็อกอินผู้โจมตีเข้าสู่บัญชีท้องถิ่นใดๆ ก็ได้" เอกสารวิจัยอ้างว่าเว็บไซต์ยอดนิยมหลายแห่งได้รับการยืนยันว่ามีช่องโหว่ รวมถึงYahoo! Mail , smartsheet.com , Zoho , manymoon.com , diigo.comนักวิจัยได้แจ้งให้ฝ่ายที่ได้รับผลกระทบทราบแล้ว และได้แก้ไขโค้ดที่มีช่องโหว่แล้ว

สำหรับปัญหาที่สอง เอกสารดังกล่าวเรียกว่า "ข้อบกพร่องทางตรรกะการสับสนประเภทข้อมูล" ซึ่งอนุญาตให้ผู้โจมตีสามารถลงชื่อเข้าใช้บัญชี RP ของเหยื่อได้GoogleและPayPalได้รับการยืนยันว่ามีช่องโหว่ในเบื้องต้น OpenID ได้เผยแพร่รายงานช่องโหว่^{[ 28 ]}เกี่ยวกับข้อบกพร่องดังกล่าว รายงานระบุว่า Google และ PayPal ได้ทำการแก้ไขแล้ว และแนะนำให้ผู้จำหน่าย OpenID รายอื่นๆ ตรวจสอบการใช้งานของตน

ผู้สังเกตการณ์บางรายแนะนำว่า OpenID มีจุดอ่อนด้านความปลอดภัยและอาจเสี่ยงต่อการโจมตีแบบฟิชชิ่ง^{[ 29 ] [ 30 ] [ 31 ]}ตัวอย่างเช่น ฝ่ายผู้ส่งต่อที่เป็นอันตรายอาจส่งต่อผู้ใช้ปลายทางไปยังหน้าการตรวจสอบสิทธิ์ของผู้ให้บริการข้อมูลประจำตัวปลอม โดยขอให้ผู้ใช้ปลายทางป้อนข้อมูลประจำตัว เมื่อเสร็จสิ้นขั้นตอนนี้ ฝ่ายที่เป็นอันตราย (ซึ่งในกรณีนี้ควบคุมหน้าการตรวจสอบสิทธิ์ปลอมด้วย) ก็สามารถเข้าถึงบัญชีของผู้ใช้ปลายทางกับผู้ให้บริการข้อมูลประจำตัวได้ จากนั้นใช้ OpenID ของผู้ใช้ปลายทางเพื่อเข้าสู่ระบบบริการอื่นๆ

เพื่อพยายามต่อสู้กับการโจมตีแบบฟิชชิ่งที่อาจเกิดขึ้น ผู้ให้บริการ OpenID บางรายกำหนดให้ผู้ใช้ปลายทางต้องได้รับการตรวจสอบสิทธิ์กับพวกเขาก่อนที่จะพยายามตรวจสอบสิทธิ์กับฝ่ายที่พึ่งพา^{[ 32 ]}ซึ่งขึ้นอยู่กับว่าผู้ใช้ปลายทางรู้ถึงนโยบายของผู้ให้บริการข้อมูลประจำตัวหรือไม่ ในเดือนธันวาคม พ.ศ. 2551 มูลนิธิ OpenID ได้อนุมัติเวอร์ชัน 1.0 ของส่วนขยายนโยบายการตรวจสอบสิทธิ์ของผู้ให้บริการ (PAPE) ซึ่ง "ช่วยให้ฝ่ายที่พึ่งพาสามารถร้องขอให้ผู้ให้บริการ OpenID ใช้นโยบายการตรวจสอบสิทธิ์ที่ระบุไว้เมื่อตรวจสอบสิทธิ์ผู้ใช้ และให้ผู้ให้บริการ OpenID แจ้งให้ฝ่ายที่พึ่งพาทราบว่านโยบายใดถูกนำมาใช้จริง" ^{[ 33 ]}

ปัญหาด้านความปลอดภัยอื่นๆ ที่ระบุเกี่ยวกับ OpenID เกี่ยวข้องกับการขาดความเป็นส่วนตัวและความล้มเหลวในการแก้ไขปัญหาความไว้วางใจ^{[ 34 ]} อย่างไรก็ตาม ปัญหานี้ไม่ได้เกิดขึ้นเฉพาะกับ OpenID เท่านั้นแต่เป็นเพียงสถานะของอินเทอร์เน็ตที่ใช้กันทั่วไป

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

ช่องโหว่สำคัญอีกประการหนึ่งอยู่ที่ขั้นตอนสุดท้ายในระบบการตรวจสอบสิทธิ์เมื่อไม่ได้ใช้ TLS/SSL นั่นคือ URL การเปลี่ยนเส้นทางจากผู้ให้บริการข้อมูลประจำตัวไปยังฝ่ายที่พึ่งพา ปัญหาของการเปลี่ยนเส้นทางนี้คือความจริงที่ว่าใครก็ตามที่สามารถรับ URL นี้ได้ (เช่น โดยการดักฟังการสื่อสาร) สามารถเล่นซ้ำและเข้าสู่ระบบเว็บไซต์ในฐานะผู้ใช้ที่เป็นเหยื่อได้ ผู้ให้บริการข้อมูลประจำตัวบางรายใช้nonce (หมายเลขที่ใช้เพียงครั้งเดียว) เพื่ออนุญาตให้ผู้ใช้เข้าสู่ระบบเว็บไซต์ได้เพียงครั้งเดียวและล้มเหลวในการพยายามครั้งต่อๆ ไป วิธีแก้ปัญหาด้วย nonce จะได้ผลหากผู้ใช้เป็นคนแรกที่ใช้ URL อย่างไรก็ตาม ผู้โจมตีที่รวดเร็วซึ่งดักฟังการสื่อสารสามารถรับ URL และรีเซ็ตการเชื่อมต่อ TCP ของผู้ใช้ได้ทันที (เนื่องจากผู้โจมตีกำลังดักฟังการสื่อสารและรู้หมายเลขลำดับ TCP ที่จำเป็น) จากนั้นดำเนินการโจมตีแบบเล่นซ้ำตามที่อธิบายไว้ข้างต้น ดังนั้น nonce จึงป้องกันเฉพาะผู้โจมตีแบบพาสซีฟเท่านั้น แต่ไม่สามารถป้องกันผู้โจมตีแบบแอคทีฟจากการดำเนินการโจมตีแบบเล่นซ้ำได้^{[ 35 ]}การใช้ TLS/SSL ในกระบวนการตรวจสอบสิทธิ์สามารถลดความเสี่ยงนี้ได้อย่างมาก

เมื่อวันที่ 1 พฤษภาคม 2557 ได้มีการเปิดเผยข้อบกพร่องที่เรียกว่า "การเปลี่ยนเส้นทางลับที่เกี่ยวข้องกับOAuth 2.0 และ OpenID" ^{[ 36 ] [ 37 ]}ซึ่งถูกค้นพบโดย Wang Jing นักศึกษาปริญญาเอกสาขาคณิตศาสตร์จาก School of Physical and Mathematical Sciences, Nanyang Technological Universityประเทศสิงคโปร์^{[ 38 ] [ 39 ] [ 40 ]}

ประกาศของ OpenID คือ: "'การเปลี่ยนเส้นทางแบบลับๆ' ซึ่งเผยแพร่ในเดือนพฤษภาคม 2014 เป็นตัวอย่างหนึ่งของผู้โจมตีที่ใช้ตัวเปลี่ยนเส้นทางแบบเปิด ซึ่งเป็นภัยคุกคามที่รู้จักกันดี และมีวิธีการป้องกันที่รู้จักกันดี โปรโตคอล OpenID Connect กำหนดมาตรการที่เข้มงวดเพื่อป้องกันตัวเปลี่ยนเส้นทางแบบเปิดเพื่อป้องกันช่องโหว่นี้" ^{[ 41 ]}

"โดยทั่วไปแล้ว ความเห็นส่วนใหญ่ก็คือ Covert Redirect ไม่ร้ายแรงเท่าไหร่ แต่ก็ยังเป็นภัยคุกคามอยู่ การทำความเข้าใจว่าอะไรทำให้มันอันตราย จำเป็นต้องมีความเข้าใจพื้นฐานเกี่ยวกับ Open Redirect และวิธีการใช้ประโยชน์จากมัน" ^{[ 42 ]}

แพทช์ยังไม่พร้อมใช้งานในทันที Ori Eisen ผู้ก่อตั้ง ประธาน และหัวหน้าเจ้าหน้าที่ฝ่ายนวัตกรรมของ 41st Parameter กล่าวกับ Sue Marquette Poremba ว่า "ในระบบกระจายใดๆ เราคาดหวังว่าผู้เข้าร่วมจะมีน้ำใจที่จะทำสิ่งที่ถูกต้อง ในกรณีเช่น OAuth และ OpenID การกระจายตัวนั้นกว้างขวางมากจนไม่สมเหตุสมผลที่จะคาดหวังว่าเว็บไซต์ทุกแห่งจะแก้ไขแพทช์ในอนาคตอันใกล้นี้" ^{[ 43 ]}

โปรโตคอลการตรวจสอบสิทธิ์ OpenID ดั้งเดิมได้รับการพัฒนาในเดือนพฤษภาคม พ.ศ. 2548 ^{[ 44 ]}โดยBrad Fitzpatrickผู้สร้างเว็บไซต์ชุมชนยอดนิยมLiveJournalขณะทำงานที่Six Apart [ ^{45 ] ใน}ตอนแรกเรียกว่า Yadis (ตัวย่อของ "Yet another distributed identity system") ^{[ 46 ]} ต่อมาได้เปลี่ยนชื่อเป็น OpenID หลังจากที่ Six Apart ได้รับ ชื่อโดเมน openid.net เพื่อใช้สำหรับโครงการนี้^{[ 47 ]}ในไม่ช้าก็มีการนำการสนับสนุน OpenID มาใช้ในLiveJournalและDeadJournal ซึ่งเป็น ชุมชนเครื่องมือ LiveJournal เดียวกัน สำหรับความคิดเห็นในบล็อกโพสต์ และได้รับความสนใจอย่างรวดเร็วในชุมชนข้อมูลประจำตัวดิจิทัล^{[ 48 ] [ 49 ]}นักพัฒนาเว็บJanRainเป็นผู้สนับสนุน OpenID ในช่วงแรก โดยจัดหาไลบรารีซอฟต์แวร์ OpenID และขยายธุรกิจเกี่ยวกับบริการที่ใช้ OpenID

ในช่วงปลายเดือนมิถุนายน การสนทนาระหว่างผู้ใช้ OpenID และนักพัฒนาจาก บริษัท ซอฟต์แวร์องค์กร NetMesh ได้เริ่มต้นขึ้น นำไปสู่ความร่วมมือในการทำงานร่วมกันระหว่าง OpenID และ โปรโตคอล Light-weight Identity (LID) ที่คล้ายคลึงกันของ NetMesh ผลโดยตรงจากความร่วมมือนี้คือ โปรโตคอลการค้นหา Yadisซึ่งใช้ชื่อเดิมที่ใช้สำหรับ OpenID โปรโตคอล Yadis ใหม่นี้ได้รับการประกาศเมื่อวันที่ 24 ตุลาคม พ.ศ. 2548 ^{[ 50 ]}หลังจากการอภิปรายในการประชุมเชิงปฏิบัติการ Internet Identity Workshop ปี พ.ศ. 2548 ไม่กี่วันต่อมา นักพัฒนา XRI / i-namesได้เข้าร่วมโครงการ Yadis ^{[ 51 ]}โดยมีส่วนร่วมในรูปแบบ Extensible Resource Descriptor Sequence ( XRDS ) เพื่อใช้ในโปรโตคอล^{[ 52 ]}

ในเดือนธันวาคม นักพัฒนาที่ Sxip Identity เริ่มหารือกับชุมชน OpenID/Yadis ^{[ 53 ]}หลังจากประกาศการเปลี่ยนแปลงในการพัฒนา Simple Extensible Identity Protocol (SXIP) เวอร์ชัน 2.0 ไปสู่ข้อมูลประจำตัวแบบ URL เช่น LID และ OpenID ^{[ 54 ]}ในเดือนมีนาคม พ.ศ. 2549 JanRain ได้พัฒนาส่วนขยาย Simple Registration (SREG) สำหรับ OpenID ซึ่งช่วยให้สามารถแลกเปลี่ยนโปรไฟล์เบื้องต้นได้^{[ 55 ]}และในเดือนเมษายนได้ยื่นข้อเสนอเพื่อกำหนดส่วนขยายของ OpenID อย่างเป็นทางการ ในเดือนเดียวกันนั้น งานก็ได้เริ่มต้นขึ้นในการรวม การสนับสนุน XRI อย่างเต็มรูปแบบ เข้ากับ OpenID ^{[ 56 ]} ประมาณต้นเดือนพฤษภาคม David Recordonนักพัฒนา OpenID คนสำคัญได้ออกจาก Six Apart และเข้าร่วม VeriSign เพื่อมุ่งเน้นไปที่ข้อมูลประจำตัวดิจิทัลและคำแนะนำสำหรับข้อกำหนด OpenID มากขึ้น^{[ 49 ] [ 57 ]}ในช่วงต้นเดือนมิถุนายน ความแตกต่างที่สำคัญระหว่างโครงการ SXIP 2.0 และ OpenID ได้รับการแก้ไขด้วยข้อตกลงที่จะสนับสนุนบุคคลหลายคนใน OpenID โดยการส่ง URL ของผู้ให้บริการข้อมูลประจำตัวแทนที่จะเป็น URL ข้อมูลประจำตัวแบบเต็ม ด้วยเหตุนี้ รวมถึงการเพิ่มส่วนขยายและการสนับสนุน XRI ที่กำลังดำเนินการอยู่ OpenID จึงกำลังพัฒนาไปสู่กรอบงานข้อมูลประจำตัวดิจิทัลที่สมบูรณ์แบบ โดย Recordon ประกาศว่า: "เรามองว่า OpenID เป็นร่มสำหรับกรอบงานที่ครอบคลุมเลเยอร์สำหรับตัวระบุ การค้นหา การตรวจสอบสิทธิ์ และเลเยอร์บริการส่งข้อความที่อยู่ด้านบน และทั้งหมดนี้ได้รับการขนานนามว่า 'OpenID 2.0'" ^{[ 58 ]} "ในช่วงปลายเดือนกรกฎาคม Sxip เริ่มรวมโปรโตคอล Digital Identity Exchange (DIX) เข้ากับ OpenID โดยส่งร่างแรกของส่วนขยาย OpenID Attribute Exchange (AX) ในเดือนสิงหาคม ปลายปี 2549 บทความแสดงความคิดเห็น ของ ZDNetได้นำเสนอเหตุผลสนับสนุน OpenID ให้กับผู้ใช้ ผู้ให้บริการเว็บไซต์ และผู้ประกอบการ^{[ 59 ]}

เมื่อวันที่ 31 มกราคม 2550 Symantecประกาศสนับสนุน OpenID ในผลิตภัณฑ์และบริการ Identity Initiative ของตน^{[ 60 ]}หนึ่งสัปดาห์ต่อมา ในวันที่ 6 กุมภาพันธ์Microsoftได้ประกาศร่วมกับ JanRain, Sxip และ VeriSign เพื่อร่วมมือกันในการทำงานร่วมกันระหว่าง OpenID และ แพลตฟอร์มข้อมูลประจำตัวดิจิทัล Windows CardSpace ของ Microsoft โดยมุ่งเน้นเป็นพิเศษในการพัฒนาโซลูชันการตรวจสอบสิทธิ์ที่ป้องกันการฟิชชิ่งสำหรับ OpenID ในฐานะส่วนหนึ่งของความร่วมมือ Microsoft สัญญาว่าจะสนับสนุน OpenID ในผลิตภัณฑ์เซิร์ฟเวอร์ข้อมูลประจำตัวในอนาคต และ JanRain, Sxip และ VeriSign สัญญาว่าจะเพิ่มการสนับสนุน โปรไฟล์ Information Card ของ Microsoft ในโซลูชันข้อมูลประจำตัวในอนาคตของพวกเขา^{[ 61 ]}ในช่วงกลางเดือนกุมภาพันธ์AOLประกาศว่าบริการผู้ให้บริการ OpenID ทดลองใช้งานได้สำหรับบัญชี AOL และAOL Instant Messenger (AIM) ทั้งหมด ^{[ 62 ]}

ในเดือนพฤษภาคมSun Microsystemsเริ่มทำงานร่วมกับชุมชน OpenID โดยประกาศโครงการ OpenID ^{[ 63 ]}รวมถึงทำข้อตกลงไม่ฟ้องร้องกับชุมชน OpenID โดยให้คำมั่นว่าจะไม่ใช้สิทธิบัตรใดๆ ของตนกับการใช้งาน OpenID ^{[ 23 ]}ในเดือนมิถุนายน ผู้นำ OpenID ได้ก่อตั้งมูลนิธิ OpenID ซึ่งเป็นองค์กรสาธารณประโยชน์ ในรัฐโอเรกอน เพื่อจัดการแบรนด์และทรัพย์สินของ OpenID ^{[ 64 ]}ในเดือนเดียวกันนั้น มูลนิธิ OpenID Europe ที่เป็นอิสระได้ก่อตั้งขึ้นในเบลเยียม^{[ 65 ]}โดย Snorri Giorgetti ในช่วงต้นเดือนธันวาคม ข้อตกลงไม่ฟ้องร้องได้รับการรวบรวมโดยผู้มีส่วนร่วมหลักในโปรโตคอล และข้อกำหนด OpenID Authentication 2.0 และ OpenID Attribute Exchange 1.0 ฉบับสุดท้ายได้รับการอนุมัติในวันที่ 5 ธันวาคม^{[ 66 ]}

ในช่วงกลางเดือนมกราคม พ.ศ. 2551 Yahoo!ประกาศการสนับสนุน OpenID 2.0 เบื้องต้น ทั้งในฐานะผู้ให้บริการและผู้รับบริการ โดยเปิดตัวบริการผู้ให้บริการภายในสิ้นเดือน^{[ 67 ]}ในช่วงต้นเดือนกุมภาพันธ์ Google, IBM, Microsoft, VeriSign และ Yahoo! เข้าร่วมมูลนิธิ OpenID ในฐานะสมาชิกคณะกรรมการบริษัท^{[ 68 ]}ประมาณต้นเดือนพฤษภาคมSourceForge , Inc.ได้แนะนำการสนับสนุนผู้ให้บริการ OpenID และผู้รับบริการให้กับเว็บไซต์พัฒนาซอฟต์แวร์โอเพนซอร์สชั้นนำSourceForge.net ^{[ 69 ]}ในช่วงปลายเดือนกรกฎาคมบริการเครือข่ายสังคมออนไลน์ ยอดนิยม MySpaceประกาศการสนับสนุน OpenID ในฐานะผู้ให้บริการ^{[ 70 ]}ในช่วงปลายเดือนตุลาคม Google เปิดตัวการสนับสนุนในฐานะผู้ให้บริการ OpenID และ Microsoft ประกาศว่าWindows Live IDจะสนับสนุน OpenID ^{[ 71 ]}ในเดือนพฤศจิกายน JanRain ประกาศบริการโฮสต์ฟรี RPX Basic ซึ่งช่วยให้เว็บไซต์สามารถเริ่มยอมรับ OpenID สำหรับการลงทะเบียนและการเข้าสู่ระบบโดยไม่ต้องติดตั้ง ผสานรวม และกำหนดค่าไลบรารีโอเพนซอร์ส OpenID ^{[ 72 ]}

ในเดือนมกราคม พ.ศ. 2552 PayPal เข้าร่วมมูลนิธิ OpenID ในฐานะสมาชิกองค์กร ตามมาด้วย Facebook ในเดือนกุมภาพันธ์ มูลนิธิ OpenID ได้จัดตั้งคณะกรรมการบริหารและแต่งตั้ง Don Thibeau เป็นผู้อำนวยการบริหาร ในเดือนมีนาคม MySpace เปิดตัวบริการผู้ให้บริการ OpenID ตามที่ได้ประกาศไว้ก่อนหน้านี้ ทำให้ผู้ใช้ MySpace ทุกคนสามารถใช้ URL ของ MySpace เป็น OpenID ได้ ในเดือนพฤษภาคม Facebook เปิดตัวฟังก์ชันฝ่ายที่พึ่งพา^{[ 73 ] [ 74 ]}ทำให้ผู้ใช้สามารถใช้บัญชี OpenID ที่เปิดใช้งานการเข้าสู่ระบบอัตโนมัติ (เช่น Google) เพื่อเข้าสู่ระบบ Facebook ได้^{[ 75 ]}

ในเดือนกันยายน พ.ศ. 2556 Janrainประกาศว่า MyOpenID.com จะปิดตัวลงในวันที่ 1 กุมภาพันธ์ พ.ศ. 2557 แผนภูมิวงกลมแสดงให้เห็นว่า Facebook และ Google ครองตลาดการเข้าสู่ระบบโซเชียลในไตรมาสที่ 2 พ.ศ. 2556 ^{[ 76 ]}ตั้งแต่นั้นมา Facebook ก็ได้ถอนตัวออกจาก OpenID แล้ว โดยไม่ได้เป็นผู้สนับสนุน เป็นตัวแทนในคณะกรรมการ หรืออนุญาตให้เข้าสู่ระบบด้วย OpenID อีกต่อไป^{[ 16 ] [ 77 ]}

ในเดือนพฤษภาคม พ.ศ. 2559 Symantec ประกาศว่าจะยุติการให้บริการพอร์ทัลข้อมูลประจำตัวส่วนบุคคล pip.verisignlabs.com OpenID ^{[ 78 ] [ 79 ]}

ในเดือนมีนาคม พ.ศ. 2561 Stack Overflow ประกาศยุติการสนับสนุน OpenID โดยอ้างว่ามีการใช้งานไม่เพียงพอที่จะคุ้มค่ากับค่าใช้จ่าย ในประกาศดังกล่าวระบุว่า จากกิจกรรม ผู้ใช้ส่วนใหญ่นิยมใช้ Facebook, Google และการตรวจสอบสิทธิ์บัญชีโดยใช้อีเมล/รหัสผ่านมากกว่า^{[ 80 ]}

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

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

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

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

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

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

จดหมายฉบับนี้สามารถใช้การเข้ารหัสแบบกุญแจสาธารณะเพื่อยืนยันความถูกต้องได้

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

OpenID Connect (OIDC) ซึ่งเผยแพร่ในเดือนกุมภาพันธ์ พ.ศ. 2557 ^{[ 83 ]}โดยมูลนิธิ OpenID เป็นเทคโนโลยี OpenID รุ่นที่สาม เป็นเลเยอร์การตรวจสอบสิทธิ์บนกรอบงานการอนุญาตOAuth 2.0 ^{[ 84 ]}ช่วยให้ไคลเอนต์คอมพิวเตอร์สามารถตรวจสอบตัวตนของผู้ใช้ปลายทางโดยอิงจากการตรวจสอบสิทธิ์ที่ดำเนินการโดยเซิร์ฟเวอร์การอนุญาต รวมถึงรับข้อมูลโปรไฟล์พื้นฐานเกี่ยวกับผู้ใช้ปลายทางในลักษณะที่ทำงานร่วมกันได้และคล้ายกับ REST ในทางเทคนิค OpenID Connect กำหนด API HTTP แบบ RESTful โดยใช้JSONเป็นรูปแบบข้อมูล

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

• เว็บไซต์อย่างเป็นทางการ