แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

บล็อก · 30 กันยายน 2566 · Steve Simpson · ตัวตน

ทำความเข้าใจความปลอดภัยและตัวตนของ Salesforce: เมื่อไรควรใช้ Single Sign-On และ OAuth บทนำ

ในบล็อกนี้ เราตั้งใจให้ความชัดเจนเรื่องความปลอดภัยและตัวตนของ Salesforce โดยเน้นว่าเมื่อไรควรใช้ Single Sign-On (SSO) และ OAuth ความรู้นี้สำคัญมากในการไล่ดูสถานการณ์ต่างๆ ของการเข้าถึง Salesforce ไม่ว่าจะผ่านการล็อกอินตรง SSO หรือ OAuth

เมื่อไรควรใช้การล็อกอินมาตรฐาน Single Sign-On หรือ OAuth

การล็อกอินตรง:

สถานการณ์: ผู้ใช้ผ่านเบราว์เซอร์ตั้งใจจะเข้าถึง Salesforce เพื่อดูหน้าเพจของมัน

วิธีการเข้าถึง: ล็อกอินตรงเข้า Salesforce หรือ Single Sign-On ผ่านผู้ให้บริการตัวตนบุคคลที่สาม ทำให้เข้าถึงได้อย่างราบรื่นโดยไม่ต้องยืนยันตัวตนซ้ำ

สรุป SSO และ OAuth สำหรับคน: คนที่ใช้เบราว์เซอร์ (ล็อกอินตรงหรือ single sign-on) คนที่ใช้แอปไคลเอนต์ (OAuth web server flow พร้อม PKCE) และคนที่ใช้เว็บเซิร์ฟเวอร์ของบุคคลที่สาม (web server flow พร้อม PKCE)

OAuth กับแอปมือถือ:

สถานการณ์: ผู้ใช้ใช้แอปมือถือเพื่อเข้าถึงข้อมูล Salesforce ผ่าน API ไม่ใช่ด้วยการแสดงหน้าเพจ Salesforce แบบเนทีฟ

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

สรุป SSO และ OAuth สำหรับกระบวนการไคลเอนต์: ผู้ใช้การผสานรวม (client credentials) ผู้ใช้ที่เป็นบุคคลที่ได้รับมอบหมาย (JWT หรือ SAML bearer assertion) อุปกรณ์ที่มีคนอนุมัติควบคู่กัน (device flow) และอุปกรณ์สินทรัพย์ (asset flow)

OAuth กับเซิร์ฟเวอร์ของบุคคลที่สาม:

สถานการณ์: ผู้ใช้ใช้เบราว์เซอร์สื่อสารกับเซิร์ฟเวอร์ของบุคคลที่สามที่ต้องเข้าถึงข้อมูล Salesforce แทนผู้ใช้ ตัวอย่างเช่นปลั๊กอินอีเมลหรือระบบอื่นที่ผสานรวมกับ Salesforce

วิธีการเข้าถึง: ใช้ OAuth กับโปรโตคอลเฉพาะที่เรียกว่า “Web Server with PKCE” (Proof Key for Code Exchange) เพื่อการเข้าถึงอย่างปลอดภัย

OAuth Flow สำหรับสถานการณ์ต่างๆ

Client Credentials Flow: ออกแบบสำหรับกระบวนการไคลเอนต์ (เช่น เซิร์ฟเวอร์ภายนอกที่ทำ batch load หรือ export) ที่เข้าถึง Salesforce ด้วยบัญชีผู้ใช้การผสานรวมที่กำหนดไว้

JWT, SAML Bearer Assertion และ SAML Assertion Flow: flow เหล่านี้สำหรับสถานการณ์ที่กระบวนการไคลเอนต์ต้องทำงานแทนผู้ใช้เฉพาะ โดยผู้ใช้ไม่ได้เกี่ยวข้องโดยตรง ตรงนี้กระบวนการสวมบทบาทเป็นผู้ใช้ที่กำหนด โดยรักษาบริบทความปลอดภัยของไฟล์ของผู้ใช้นั้น

Device Flow: flow นี้เริ่มโดยอุปกรณ์ที่ต้องการให้คนเข้ามาอนุมัติ ตัวอย่างเช่น แอปพลิเคชันบนสมาร์ททีวีที่ให้ผู้ใช้ป้อนรหัสเพื่ออนุมัติการเข้าถึง

Asset Flow: มีประโยชน์สำหรับอุปกรณ์ Internet of Things (IoT) ที่ต้องเชื่อมต่อกับ Salesforce เพื่ออ่านหรือเขียนข้อมูล

ทบทวนและสรุป

โดยแก่นแท้ วิธีการเข้าถึงของคุณขึ้นอยู่กับสถานการณ์เป็นหลัก:

สำหรับการเข้าถึง Salesforce โดยตรงผ่านเบราว์เซอร์ ใช้การล็อกอินตรง หรือ Single Sign-On ถ้าคุณมีบริการตัวตน

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

ในบทความต่อๆ ไป เราจะลงลึกในแต่ละสถานการณ์และกรณีการใช้งานเพื่อให้ความเข้าใจที่ครอบคลุม

ติดตามต่อ

เริ่มต้นเส้นทาง Salesforce Identity ของคุณอย่างมั่นใจ! สำหรับมุมมองและเคล็ดลับเพิ่มเติม ติดตามได้ที่ www.SteveTechArc.com และช่อง YouTube @SteveTechArc (opens in a new tab) กดติดตามและเพิ่มความเข้าใจเรื่อง Salesforce Identity ของคุณ

ช่วยเปลี่ยนโลกด้วยการแบ่งปันความรู้ด้านการผสานรวมกับเพื่อนสถาปนิกและผู้ที่อยู่บนเส้นทางสู่การเป็นสถาปนิก!

บทถอดความได้รับความช่วยเหลือจาก AI

STA 3.9