# เว็บออเทนทิเคชัน
เว็บออเทนทิเคชัน  หรือ เว็บออเทน  เป็นมาตรฐานเว็บที่เผยแพร่โดยเวิลด์ไวด์เว็บคอนซอร์เทียม (W3C)
เป็นส่วนประกอบหลักของโปรเจ็กต์ไฟโด 2 (FIDO2 Project) ซึ่งสมาคมไฟโดอัลไลแอนซ์ (FIDO Alliance) เป็นผู้ดูแล
เป้าหมายของโปรเจ็กต์ก็คือสร้างมาตรฐานส่วนประสาน (interface) ที่ใช้พิสูจน์ตัวผู้ใช้แอปหรือผู้ใช้บริการเว็บด้วยการเข้ารหัสแบบกุญแจอสมมาตร (public-key cryptography)

ในระบบรับบริการ (client) มาตรฐานสามารถทำให้เกิดผลได้ด้วยวิธีหลายอย่าง
ซึ่งการเข้ารหัสจะทำโดยหน่วย ออเทนทิเคเทอร์  อันเป็นโมเดลปฏิการแบบนามธรรมที่โดยมากไม่ว่าตัวกุญแจรหัสจะต้องจัดการอย่างไร
จึงทำให้สามารถสนับสนุนเว็บออเทนได้ด้วยซอฟต์แวร์ล้วน ๆ โดยยังสามารถใช้หน่วย trusted execution environment (TEE) และ Trusted Platform Module (TPM) ของหน่วยประมวลผลกลางช่วยได้
ปฏิบัตการเข้ารหัสลับและถอดรหัสลับที่ต้องเก็บความลับไว้ให้ได้ อาจใช้แบบฮาร์ดแวร์และเคลื่อนที่ได้ (roaming hardware authenticator) ต่างหาก ๆ โดยต่อกับระบบผ่านยูเอสบี บลูทูธ หรือการสื่อสารสนามใกล้ (NFC)
ออเทนทิเคเทอร์แบบฮาร์ดแวร์จะต้องสนับสนุน CTAP (Client to Authenticator Protocol) ที่เป็นส่วนของมาตรฐานไฟโด
จึงทำให้ใช้กับมาตรฐาน U2F (Universal 2nd Factor) ดั้งเดิมของไฟโดได้

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

W3C ได้เผยแพร่เว็บออเทนรุ่นที่1 และ 2 (level 1 and 2) ในวันที่4 มีนาคม 2019 และ 8 เมษายน 2021 ตามลำดับ
ส่วนรุ่นที่3 ยังอยู่ในสถานะ First Public Working Draft (FPWD)

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

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

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

 คำอธิบายทั่วไป 
เหมือนกับมาตรฐานไฟโดดั้งเดิมคือ U2F การยืนยันผู้ใช้ด้วยระบบเว็บออเทนทิเคชัน (เว็บออเทน) จะมีฝ่ายต่าง ๆ คือ เว็บไซต์, เว็บเบราว์เซอร์/ระบบรับบริการ (client) และออเทนทิเคเทอร์
 เว็บไซต์เป็นฝ่ายที่เรียกว่า WebAuthn Relying Party
 เว็บเบราว์เซอร์/ระบบรับบริการเรียกว่า WebAuthn Client
 ออเทนทิเคเทอร์จะเป็นแบบ FIDO2 ซึ่งทำงานร่วมกับระบบรับบริการได้

มาตรฐานเว็บออเทนระบุว่า ผู้อ้างว่าคือผู้ใช้ควรยืนยันแก่ผู้ตรวจสอบผู้ใช้คือ WebAuthn Relying Party อย่างไรว่าตนมีออเทนทิเคเทอร์แบบ FIDO2 ในการควบคุม
ส่วนผู้อำนวยกระบวนการพิสูจน์ผู้ใช้ก็คือ WebAuthn Client ซึ่งปกติก็คือเว็บเบราว์เซอร์

 การพิสูจน์ตัวจริง (authentication) 
thumb|right|กระบวนการพิสูจน์ผู้ใช้ด้วยมาตรฐานเว็บออเทน
เพื่อแสดงเป็นตัวอย่าง ออเทนทิเคเทอร์จะสมมุติว่าเป็นแบบฮาร์ดแวร์และเคลื่อนที่ได้ (เช่น ยูบิคีย์)
เป็นแบบหลายปัจจัยที่ใช้การเข้ารหัสแบบกุญแจอสมมาตรเพื่อเซ็นการยืนยันว่าได้พิสูจน์บุคคล (authentication assertion) แล้วสำหรับ WebAuthn Relying Party
ถ้าออเทนทิเคเทอร์ใช้รหัส PIN เพื่อพิสูจน์ผู้ใช้ ตัวออเทนทิเคเทอร์เองจะเป็น "สิ่งที่ผู้ใช้มี" และรหัส PIN จะเป็น "สิ่งที่ผู้ใช้รู้"

เพื่อเริ่มกระบวนการพิสูจน์ผู้ใช้ของเว็บออเทน
WebAuthn Relying Party จะระบุความต้องการกับระบบรับบริการเว็บออเทน (คือ เว็บบราวเซอร์) ผ่านจาวาสคริปต์ แล้วระบบรับบริการเว็บออเทนก็จะสื่อสารกับออเทนทิเคเทอร์ด้วยเอพีไอจาวาสคริปต์ที่เว็บบราวเซอร์ทำให้เกิดผล โดยตัวออเทนทิเคเทอร์จะใช้โพรโทคอล Client to Authenticator Protocol ของไฟโด

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

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

 การลงทะเบียน 
เมื่อ WebAuthn Relying Party ได้รับการยืนยันพิสูจน์ตัวตนที่ได้เซ็นด้วยรหัสลับ (signed authentication assertion) แล้วจากเว็บบราวเซอร์ ก็จะตรวจสอบการยืนยันนั้นด้วยกุญแจสาธารณะที่เชื่อถือได้ของผู้ใช้ คำถามก็คือ แล้วจะได้กุญแจนั้นมาจากไหนในเบื้องต้น

ในเบื้องต้น เพื่อจะได้กุญแจสาธารณะจากผู้ใช้ WebAuthn Relying Party จะลงทะเบียนผู้ใช้
ซึ่งคล้ายกับกระบวนการพิสูจน์ผู้ใช้ดังที่กล่าวไปแล้ว
แต่แทนที่จะเซ็นรองรับการยืนยันพิสูจน์ตัวตน (assertation) ออเทนทิเคเทอร์จะเซ็นรายงานที่เรียกว่า attestation statement ด้วยกุญแจส่วนตัวของเองที่ใช้ในกิจนี้ โดยรายงาน attestation ที่เซ็นนี้แล้วส่งไปให้แก่ WebAuthn Relying Party ก็จะแนบเอารหัสสาธารณะของผู้ใช้ที่ WebAuthn Relying Party จะใช้ตรวจสอบการยืนยันพิสูจน์ตัวตนของผู้ใช้ (assertion) ต่อ ๆ ไป

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

ชนิดของ attestation ที่ระบุไว้ในจาวาสคริปต์จะเป็นตัวกำหนดโมเดลความเชื่อใจ (trust model)
เช่น สำหรับชนิดที่เรียกว่า self-attestation โมเดลความเชื่อใจก็คือ เชื่อใจเมื่อใช้เป็นครั้งแรก (trust on first use)

 การรองรับ 
เวิลด์ไวด์เว็บคอนซอร์เทียมได้แนะนำให้กลุ่ม Web Authentication Working Group ตีพิมพ์เว็บออเทนรุ่นที่1 เมื่อวันที่4 มีนาคม 2019
เว็บบราวเซอร์ต่าง ๆ รวมทั้งกูเกิล โครม, มอซิลลา ไฟร์ฟอกซ์, ไมโครซอฟท์ เอดจ์, ซาฟารี และโอเปร่า ล้วนสนับสนุนมาตรฐานนี้

โครมรุ่นบนคอมได้สนับสนุนมาตรฐานนี้ตั้งแต่รุ่นที่67
ส่วนไฟร์ฟอกซ์ที่ไม่เคยสนับสนุนมาตรฐาน U2F ของไฟโดอย่างเต็มรูปแบบ ก็ได้สนับสนุนมาตรฐานนี้มาตั้งแต่รุ่นที่60 ซึ่งเผยแพร่เมื่อวันที่9 พฤษภาคม 2018
ส่วนเอดจ์สนับสนุนมาตรฐานนี้ให้ใช้ได้ทั้งด้วยวินโดวส์ฮัลโหลและกุญแจความปลอดภัยต่างหาก (external security key) ตั้งแต่ Build 17682

กุญแจความปลอดภัยแบบ U2F ของไฟโดที่มีมาก่อนสามารถเข้ากับมาตรฐานนี้ได้ แต่เว็บออเทนจริง ๆ จะสามารถใช้ข้อมูล "user handle" ที่เป็นเอกลักษณ์สำหรับบัญชีหนึ่ง ๆ ที่ออเทนทิเคเทอร์แบบ U2F จะไม่เก็บ
ออเทนทิเคเทอร์อันแรกๆ ที่สนับสนุนไฟโด 2 ก็คือ ยูบิคีย์ของยูบิโกะ ซึ่งประกาศขายในวันที่10 เมษายน 2518
ส่วนออเทนทิเคเทอร์ไฟโด 2 ที่มีหน้าจออันแรกก็คือ Trezor Model T ของซาโตชิแหล็บส์ ซึ่งประกาศขายในวันที่6 พฤศจิกายน 2019
โดยยังเป็นออเทนทิเคเทอร์รุ่นแรกที่ให้ผู้ใช้เลือก resident credential ที่อุปกรณ์ควรจะใช้โดยตรง

บริการเก็บไฟล์ในกลุ่มเมฆ (cloud) คือ Dropbox ได้ประกาศให้ใช้เว็บออเทนเป็นปัจจัยที่2 เพื่อลงชื่อเข้าบัญชีตั้งแต่วันที่8 พฤษภาคม 2018

ส่วนแอปเปิลได้ประกาศว่า Face ID และ Touch ID จะใช้เป็นออเทนทิเคเทอร์ของเว็บออเทนได้เริ่มตั้งแต่ซาฟารีรุ่น 14 ในวันที่24 มิถุนายน 2020

 เอพีไอ 
มาตรฐานนี้เป็นการขยายเอพีไอ Credential Management ของ W3C ซึ่งเป็นเอพีไอที่ระบุปฏิสัมพันธ์ระหว่างเว็บไซต์กับเว็บบราวเซอร์เมื่อแลกเปลี่ยนข้อมูลยืนยันผู้ใช้
คือ เอพีไอของเว็บออเทนทิเคชัน
จะขยายเมทอดจาวาสคริปต์ คือ  และ  ให้รับพารามิเตอร์เพิ่มคือ publicKey
โดยเมทอด create จะเอาไว้ลงบันทึกออเทนทิเคเทอร์ให้สัมพันธ์กับบัญชีผู้ใช้ โดยอาจทำเมื่อสร้างบัญชีใหม่ก็ได้ แต่มักทำเมื่อเพิ่มอุปกรณ์ความปลอดภัยใหม่ในบัญชี 
และเมทอด get เอาไว้ยืนยันการพิสูจน์ผู้ใช้ (เช่นเมื่อลงชื่อเข้าบัญชี)

สามารถตรวจสอบว่าเว็บบราวเซอร์รับรองเว็บออเทนได้หรือไม่โดยตรวจดูว่าส่วนประสาน window.PublicKeyCredential นั้นมีกำหนดไว้หรือไม่
มาตรฐานยังกำหนดส่วนประสานอื่นๆ อีกรวมทั้ง AuthenticatorResponse, AuthenticatorAttestationResponse และ AuthenticatorAssertionResponse

เอพีไอไม่อนุญาตให้เข้าถึงหรือจัดการกุญแจส่วนตัวได้โดยตรงนอกเหนือไปจากการสร้างกุญแจขึ้นใหม่ในเบื้องต้น

 การตอบรับ 
ในเดือนสิงหาคม 2018 บริษัทที่ชำนาญด้านความปลอดภัยของเว็บ คือ Paragon Initiative Enterprises ได้ตรวจสอบความปลอดภัย (security audit) ของมาตรฐานนี้
แม้จะไม่พบวิธีการแฮ็กระบบอย่างใดอย่างหนึ่งโดยเฉพาะ แต่ก็พบความบกพร่องของวิธีการเข้ารหัสที่มาตรฐานระบุ

ปัญหาหลักมีอยู่ 2อย่างซึ่งเคยเป็นปัญหากับระบบการเข้ารหัสที่ใช้มาแล้วในอดีต ดังนั้น จริง ๆ จึงไม่ควรใช้เพื่อไม่ให้ตกเป็นเหยื่อของวิธีการแฮ็กเช่นเดียวกันอีก
 เพราะการกำหนดให้ใช้มาตรฐาน COSE (RFC 8152) เว็บออเทนจึงสนับสนุน RSA ในรูปแบบ PKCS1v1.5 padding ซึ่งรู้แล้วเป็นอย่างน้อย 20ปีว่าอ่อนแอต่อวิธีการทำลายล้ายบางอย่าง โดยระบบอื่น ๆ ที่สนับสนุน RSA ก็เคยถูกแฮ็กมาแล้ว จริงอยู่ว่า จุดอ่อนแอนี้ทำได้ไม่ได้ง่ายในบริบทของเว็บออเทน แต่เพราะมีวิธีทางวิทยาการรหัสลับอื่น ๆ ที่ปลอดภัยกว่า จึงถือเป็นทางเลือกที่แย่ และไม่เป็นวิธีปฏิบัติดีที่สุดทางวิทยาการเข้ารหัสลับ
 ไฟโดอัลไลอานซ์ใช้วิธีการเข้ารหัสแบบกุญแจอสมมาตรชนิด ECDAA เป็นมาตรฐาน นี่เป็นรูปแบบหนึ่งของ direct anonymous attestation ที่อาศัย elliptic curve ซึ่งเว็บออเทนเอาไว้ใช้พิสูจน์บูรณภาพของออเทนทิเคเทอร์เอง โดยรักษาความเป็นส่วนตัวของผู้ใช้ไว้ได้เพราะไม่สามารถเทียบสัมพันธ์ handle ได้ทั่วไป แต่ ECDAA ไม่ได้ใช้บทเรียนที่ได้ทางงานวิจัยในทศวรรษที่ผ่าน ๆ มาในเรื่องการเข้ารหัสลับด้วย elliptic curve เพราะที่เลือกใช้ก็มีข้อบกพร่องด้านความปลอดภัย จึงเท่ากับลดระดับความปลอดภัยอย่างสำคัญ อนึ่ง มาตรฐาน ECDAA ยังใช้ลายเซ็นแบบสุ่มและกำหนดไม่ได้ (non-deterministic) ซึ่งพบในอดีตแล้วว่าเป็นปัญหา

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

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