การใช้งาน Single Sign-on บริษัทต่างๆ มักจะประสบกับความยากลำบากในขณะที่ดำเนินการไปสู่การใช้งานการลงชื่อเพียงครั้งเดียว (SSO) หลายคนติดอยู่ที่ขั้นตอนที่หนึ่ง พยายามค้นหาประโยชน์ของ SSO แนวทางปฏิบัติที่ดีที่สุดในการใช้งาน ประเภท โปรโตคอล และสิ่งพื้นฐานอื่นๆ ฉันตัดสินใจที่จะอธิบายความหมายของการลงชื่อเพียงครั้งเดียว แบ่งปันประสบการณ์ของ MobiDev และแม้กระทั่งสร้างวงล้อใหม่สำหรับการใช้ SSO ระหว่างแอปพลิเคชันมือถือด้วยวิธีที่สะดวกที่สุด
การลงชื่อเพียงครั้งเดียว (SSO)เป็นวิธีการทางเทคนิคในการรับรองความถูกต้องที่ช่วยให้ผู้ใช้สามารถเข้าสู่ระบบด้วยข้อมูลรับรองชุดเดียวสำหรับแอปพลิเคชันและเว็บไซต์ต่างๆ เทคโนโลยีนี้ขึ้นอยู่กับการตั้งค่าความสัมพันธ์ที่เชื่อถือได้ระหว่างแอปพลิเคชันหรือที่เรียกว่าผู้ให้บริการ และระบบการจัดการการเข้าถึง ผู้ให้บริการและระบบการจัดการการเข้าถึงใช้ใบรับรองร่วมกับข้อมูลระบุตัวตน ซึ่งในกรณีของ SSO จะใช้รูปแบบของโทเค็นที่มีอีเมล ชื่อผู้ใช้ หรือข้อมูลอื่นๆ
พูดง่ายๆ ด้วย SSO ผู้ใช้ไม่จำเป็นต้องพิมพ์ชื่อและรหัสผ่านซ้ำเมื่อสลับระหว่างแอปพลิเคชัน
สปส.มีกี่ประเภท?
SSO เป็นส่วนหนึ่งของ สถาปัตยกรรม Federated Identity Management (FIM)
โปรโตคอลที่ใช้สำหรับ SSO คืออะไร
โปรโตคอลที่ใช้สำหรับการติดตั้ง SSO ได้แก่ Security Assertion Markup Language (SAML), Web Services Federation (WS-Fed), OpenID Connect (OIDC), Lightweight Directory Access Protocol (LDAP) และ Kerberos
สิทธิประโยชน์ สปส
จากการวิจัยและการตลาด ตลาดการลงชื่อเพียงครั้งเดียวทั่วโลกคาดว่าจะสูงถึง 2.2 พันล้านดอลลาร์ภายในปี 2570 อย่างไรก็ตาม บริษัทต่าง ๆ มีความกังวลเกี่ยวกับภัยคุกคามด้านความปลอดภัยที่อาจเกิดขึ้นซึ่งเกี่ยวข้องกับการเข้าถึงด้วยคลิกเดียว และพวกเขาพิจารณาการใช้งาน SSO เป็นวิธีการลดความซับซ้อนในการเข้าถึง แอปพลิเคชันและปรับปรุงประสบการณ์ผู้ใช้
สิทธิประโยชน์ของ SSO ไม่ได้สิ้นสุดที่นี่และรวมถึงประเด็นต่อไปนี้:
- ลดความเหนื่อยล้าของรหัสผ่าน – ผู้ใช้ต้องต่อสู้กับการจำรหัสผ่านเดียวเท่านั้น
- การทำงานร่วมกันแบบ B2B ที่มีประสิทธิภาพ – การเป็นหุ้นส่วนแบบ B2B ประสบความสำเร็จด้วยFederated SSOเนื่องจากผู้ใช้เข้าถึงบริการที่จัดหาโดยบริษัทต่างๆ ได้อย่างง่ายดาย
- เพิ่มประสิทธิภาพการทำงานที่เกิดจากการเข้าสู่ระบบที่เร็วขึ้น
- อัตราการยอมรับสูง – SSO เพิ่มโอกาสที่ผู้ใช้จะเปิดแอปบ่อยขึ้น
ข้อเสียเปรียบหลักคือหาก SSO ล้มเหลว ผู้ใช้จะไม่สามารถเข้าถึงระบบที่เกี่ยวข้องใดๆ ได้ สำหรับความซับซ้อนนั้นถือเป็นข้อเสียตามเงื่อนไข
ความปลอดภัยสามารถแยกรายการได้
ในแง่หนึ่ง SSO ที่มีข้อมูลประจำตัวชุดเดียวหมายความว่าในกรณีที่มีการละเมิดความปลอดภัย ผู้โจมตีจะสามารถเข้าถึงบัญชีและระบบที่เชื่อมโยง แอปพลิเคชัน และข้อมูลได้ และรอยเท้าของผู้โจมตีภายในบริษัทจะเพิ่มขึ้น
ในทางกลับกัน SSO จะลดจำนวนของพื้นผิวการโจมตี เนื่องจากผู้ใช้เข้าสู่ระบบวันละครั้งและใช้ข้อมูลรับรองเพียงชุดเดียว การรักษาความปลอดภัยในระดับที่สูงขึ้นอาจเกิดขึ้นได้หากคุณรวม SSO กับการรับรองความถูกต้องตามความเสี่ยง (RBA) ระบุพฤติกรรมที่ผิดปกติ และกำหนดให้ผู้ใช้ต้องผ่านการยืนยันเพิ่มเติม
แนวทางปฏิบัติที่ดีที่สุดในการนำ SSO ไปใช้งานสำหรับแอปพลิเคชันระดับองค์กร
SSO ดำเนินการยากหรือไม่ ภาพรวมของปัญหาคือ: การปรับใช้ SSO เป็นงานที่ซับซ้อนและใช้เวลานานสำหรับโซลูชันเดิม แต่ SSO บนคลาวด์นั้นแตกต่างออกไป ให้ฉันแบ่งปันประสบการณ์ของเราซึ่งจะให้ความกระจ่างเกี่ยวกับ SSO ในแอปพลิเคชันระดับองค์กร
จนกระทั่งเมื่อไม่นานมานี้ การตั้งค่า SSO แบบรวมศูนย์สำหรับแอปพลิเคชันแบบเนทีฟเป็นความท้าทายที่ซับซ้อน มีสองตัวเลือกสำหรับนักพัฒนาในการแสดงเนื้อหาในแอปด้วย SSO: เปลี่ยนผู้ใช้จากแอปเป็นเบราว์เซอร์ระบบ จากนั้นย้อนกลับหรือแสดงเว็บวิวในแอปเพื่อแสดงเนื้อหา html โดยตรงในแอป ตัวเลือกเหล่านี้ไม่สะดวกสำหรับผู้ใช้หรือมีปัญหาด้านความปลอดภัยและความเป็นส่วนตัว
การเกิดขึ้นของตัวเลือกที่สาม – SFSafariViewController (iOS9+) และ Chrome Custom Tabs (Android) เพิ่มตัวควบคุมเว็บเพื่อให้ข้อดีทั้งหมดของเบราว์เซอร์ระบบดั้งเดิม – สิ่งนี้เป็นประโยชน์ต่อนักพัฒนา
ประสบการณ์ของเราเกี่ยวข้องกับการใช้งาน SSO ระหว่างแอปพลิเคชันมือถือสองแอปพลิเคชันที่สร้างด้วย NativeScript เวอร์ชันต่างๆ – แอป1และแอป 2 แต่ในความเป็นจริง วิธีการที่อธิบายไว้สำหรับ SSO นั้นเหมือนกันสำหรับทั้งแอปพลิเคชันเนทีฟและข้ามแพลตฟอร์ม
App1เป็นอุปกรณ์เคลื่อนที่ ในขณะที่app2หมายถึงการรวมกันของอุปกรณ์เคลื่อนที่และเว็บ ซึ่งคาดว่าจะเกิดปัญหาเกี่ยวกับการเปลี่ยนไปใช้เวอร์ชันใหม่ ผู้ให้บริการข้อมูลประจำตัวสำหรับการให้สิทธิ์ผ่านไคลเอนต์ OpenID Connect (OIDC) มีอยู่ทั่วไปภายในแอปพลิเคชัน ซึ่งอำนวยความสะดวกในการเริ่มต้น เรามีสามตัวเลือกให้เลือก: WebView, เบราว์เซอร์ระบบ และ InAppBrowser
1. แนวทางการดำเนินการ SSO: WEBVIEW พร้อมการแบ่งปันคุกกี้
การลงชื่อเข้าใช้แอปพลิเคชันแรกจะอิงตามWebViewในขณะที่การลงชื่อเข้าใช้แอปที่สองใช้แอปพลิเคชันที่รู้จักกันดีในโลกของแอปพลิเคชันแบบไฮบริด – InAppBrowserโดยมี Chrome Custom Tabs สำหรับ Android และ SafariServices/AuthenticationServices สำหรับ iOS ภายใต้ประทุน
การวิจัยเปิดเผยตัวเลือกที่สามารถเข้าถึงได้ 3 แบบเพื่อใช้ SSO ภายในเงื่อนไขที่กำหนด แม้ว่าจะมีการระบุถึงสิ่งเดียวกันสำหรับการบันทึก – WebView (ควรมองเห็นคุกกี้ที่ใช้ร่วมกัน) การใช้งาน Single Sign-on
WebView ฝังอยู่ในหน้าจอเนทีฟของแอปพลิเคชัน (เหมือนเป็น iFrame ในเว็บ) ซึ่งสามารถรับรู้ได้ว่าเป็นข้อดีของวิธีนี้ เนื่องจากการนำทางระหว่างการบันทึกดูเป็นธรรมชาติสำหรับผู้ใช้ ภาพเคลื่อนไหวและสไตล์ไม่โดดเด่นจากภาพรวม
ปัญหาหลักของการใช้ WebView สำหรับการบันทึกคือความล่าช้าในการเรียกกลับที่เกี่ยวข้องกับการโหลดหน้าเว็บ เพื่อแก้ไขปัญหานั้น นักพัฒนาได้คิดแนวคิดของตัวเองว่าจะเข้าใจอย่างไรเมื่อโหลดแบบฟอร์มการเข้าสู่ระบบ (หน้าเว็บ) และพวกเขาอาจซ่อนตัวบ่งชี้ มิฉะนั้นจะแสดงบนหน้าจอเข้าสู่ระบบที่โหลดไว้แล้วหรือถูกซ่อนก่อนที่หน้าจอจะโหลด ความผิดพลาดนี้อาจนำไปสู่ปัญหาในการตรวจสอบแอปที่ส่งไปยัง App Store นอกจากนี้ยังมีปัญหาในการเข้าถึงคุกกี้บน Android และเป็นการยากที่จะตั้งค่าการเข้าสู่ระบบทั่วไปโดยไม่เปิดลิงก์ภายนอกที่ใช้ SSO
2. แนวทางการดำเนินการ SSO: เบราว์เซอร์ระบบ
การใช้เบราว์เซอร์ระบบอาจเป็นวิธีแก้ปัญหาที่เชื่อถือได้ แต่ก็หมายถึงการออกจากแอปพลิเคชันและเปิดเบราว์เซอร์เพื่อกรอกแบบฟอร์มเข้าสู่ระบบ แท็บที่มีการเข้าสู่ระบบจะยังคงไม่ถูกปิดในเบราว์เซอร์และสะสม อย่างไรก็ตาม แนวทางดังกล่าวนำไปปฏิบัติได้ง่าย เพราะทุกอย่างทำงานในลักษณะเดียวกับบนเว็บ และทั้งสองแอปพลิเคชันจะเปิดแบบฟอร์มการเข้าสู่ระบบในสภาพแวดล้อมเดียวกันด้วยคุกกี้เดียวกันกับที่ไคลเอนต์ OIDC ใช้เพื่อตรวจสอบผู้ใช้ และด้วยความถูกต้อง การตั้งค่าเอกลักษณ์ของเซิร์ฟเวอร์สำหรับทั้งสองแอปพลิเคชัน ในกรณีของเบราว์เซอร์ระบบ ทุกอย่างทำงานได้อย่างราบรื่นและไม่ล่าช้า แต่ผู้ใช้ไม่สะดวก
Microsoft Authenticator ไม่ถือว่าเป็นโซลูชันการใช้งาน SSO เนื่องจากในการเข้าสู่ระบบ ผู้ใช้ควรออกจากแอปพลิเคชัน ให้สิทธิ์ในแอปพลิเคชันที่สอง จากนั้นยืนยันการให้สิทธิ์ในแอปพลิเคชันแรก และอื่นๆ พูดง่ายๆ ก็คือไม่สะดวกสำหรับผู้ใช้ และแย่กว่าเบราว์เซอร์ระบบเสียอีก
3. แนวทางการดำเนินการ SSO: INAPPBROWSER
แท็บใน Android และบริการใน iOS สามารถปรับแต่งในระบบเป็นป๊อปอัปแบบเนทีฟพร้อมภาพเคลื่อนไหวและรูปลักษณ์ของแพลตฟอร์ม พวกเขาติดตามการเปลี่ยนเส้นทางและจะถูกปิดหากป้อนการเข้าสู่ระบบอย่างถูกต้อง ไม่มีปัญหาเหมือนในกรณีของ WebView แม้ว่าแบบฟอร์มการเข้าสู่ระบบจะดูแยกออกจากแอปพลิเคชันหากการออกแบบแตกต่างจากส่วนประกอบของแพลตฟอร์มดั้งเดิม นี่เป็นแนวทางที่แนะนำและปลอดภัยในการติดตั้ง SSO ในแอปพลิเคชันมือถือ
หลังจากลองผิดลองถูก เราตัดสินใจเลือกใช้ InAppBrowser มีแซนด์บ็อกซ์ทั่วไปที่มีคุกกี้อยู่ในแอปพลิเคชันเดียว ดังนั้นหากคุณใช้แอปพลิเคชันนี้แล้วเปิดลิงก์เว็บอื่นๆ ในนั้น ซึ่งควรเข้าสู่ระบบของผู้ใช้ผ่าน SSO ซึ่งหมายความว่าปัญหาจะไม่เกิดขึ้นเลย แต่ใน 2 แอปพลิเคชันที่แตกต่างกัน แซนด์บ็อกซ์เหล่านี้จะแตกต่างกัน และคุณจำเป็นต้องนำข้อมูลจากแอปพลิเคชันหนึ่งไปใส่ในอีกแอปพลิเคชันหนึ่งเพื่อใช้ SSO ระหว่างแอปพลิเคชัน
สำหรับกระบวนการแบ่งปันดังกล่าว เราใช้ที่เก็บข้อมูลพวงกุญแจใน iOS และที่เก็บข้อมูลที่ปลอดภัยใน Android เนื่องจากทั้งคู่จัดเก็บข้อมูลบนอุปกรณ์อย่างปลอดภัย พวกเขาสามารถแยกร้านค้าสำหรับหนึ่งแอปพลิเคชันหรือหลายแอปพลิเคชันที่เชื่อถือได้ แต่สิ่งนี้ต้องมีขั้นตอนการกำหนดค่าเพิ่มเติมในแต่ละแอปพลิเคชันมือถือ การใช้งาน Single Sign-on
Summing Up
กล่าวโดยสรุป บริษัทต่าง ๆ กำลังลงทุนอย่างเข้มข้นในการจัดตั้ง SSO ในขณะที่แนวทางการดำเนินงานขับเคลื่อนโดยความต้องการของพวกเขา ที่ MobiDev เรามีความเชี่ยวชาญที่เกี่ยวข้องและมองเห็นโอกาสที่ดีสำหรับการลงชื่อเพียงครั้งเดียว เนื่องจากแม้แต่Google ก็ มี SSO ที่ผสานรวมไว้ล่วงหน้าพร้อมแอปพลิเคชันระบบคลาวด์ยอดนิยมกว่า 200 รายการ เรายังใช้เวลาไปกับแนวทางของเราเองในการใช้ SSO ระหว่างแอปพลิเคชันบนมือถือ
หากคุณมีคำถามเฉพาะใดๆ เกี่ยวกับการใช้งาน SSO ในโครงการของคุณเอง โปรดอย่าลังเลที่จะถาม
Face-sso (By K&O) หากท่านสนใจ เครื่องสแกนใบหน้ารุ่นต่างๆ หลากหลายรุ่น หรือ ติดตั้งระบบสแกนใบหน้า สามารถติดต่อสอบถามได้โดยตรง เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA เครื่องสแกนใบหน้า สามารถ ขอราคาพิเศษได้ ตามงบประมาณที่เหมาะสม สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ มั่นใจเพราะเป็นราคาที่สุด คุ้มค่าที่สุด
หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699
