SSO ו-MFA ארגוני: SAML מול OIDC ואינטגרציית ניהול זהויות

מאת צוות מדיה דיל · 25.07.2026 · אינטגרציות · 7 דק׳ קריאה

SSO, SAML, OIDC, MFA, SCIM, ניהול זהויות ארגוני, provisioning

לקוח ארגוני חדש חותם על חוזה, ואז שולח דרישה שלא הייתה בשיחת המכירה: "המערכת שלכם חייבת לתמוך ב-SSO דרך Azure AD שלנו, אחרת אנחנו לא יכולים להשתמש בה." זו לא גחמה - זו דרישת אבטחה ארגונית סטנדרטית, וארגונים רבים פשוט לא מאשרים כלי שדורש סיסמה נפרדת מכל עובד. הבנת SSO ו-MFA ברמה הטכנית הפכה לדרישת סף למכירה לשוק הארגוני.

SAML מול OIDC: שתי דרכים לאותה מטרה

SAML הוא הפרוטוקול הוותיק והנפוץ יותר בארגונים גדולים ומגזר ציבורי, מבוסס XML וחתימות דיגיטליות. OIDC, שנבנה מעל OAuth 2.0, מודרני יותר, קל למימוש, ונפוץ יותר בחברות טכנולוגיה וב-SaaS. הרבה ספקי זהות (Identity Provider) תומכים בשניהם, ולכן כדאי לתמוך גם ב-SAML - גם אם OIDC נוח יותר לפתח - כדי לא להחמיץ לקוחות עם תשתית ותיקה יותר.

Identity Provider: מי מנהל את הזהות בפועל

ב-SSO ארגוני, המערכת שלכם היא "Service Provider" שסומך על ספק זהות חיצוני - Azure AD, Okta, Google Workspace - לאימות המשתמש. המשתמש מתחבר פעם אחת לספק הזהות, ומקבל גישה לכל האפליקציות המחוברות בלי סיסמה נוספת. זה מעביר את האחריות לניהול סיסמאות ומדיניות אבטחה לצוות ה-IT של הלקוח, מה שהופך את זה לדרישה שכיחה כל כך.

SCIM: לא רק התחברות, גם ניהול חיים שלם

SSO פותר את שאלת ההתחברות, אבל לא את מה שקורה כשעובד מצטרף או עוזב את הארגון. SCIM (System for Cross-domain Identity Management) הוא הפרוטוקול שמאפשר לספק הזהות ליצור, לעדכן ולבטל חשבונות אוטומטית במערכת שלכם - כך שכשעובד עוזב חברה, הגישה שלו נחסמת אוטומטית בכל המערכות המחוברות תוך דקות, לא רק כשמישהו נזכר לבטל אותה ידנית.

MFA: איזה שיטה מתאימה למי

קוד SMS הוא הפתרון הפשוט ביותר אבל גם החלש ביותר לתקיפה; אפליקציית אימות (TOTP) חזקה יותר; ומפתחות גישה (passkeys) מציעים את השילוב הטוב ביותר של אבטחה ונוחות. ארגונים דורשים לעיתים MFA כתנאי סף, ולכן תמיכה בלפחות TOTP, מעבר לסיסמה בלבד, כמעט הכרחית למוצר שמכוון לשוק B2B.

מה קורה כשספק הזהות "נופל"

תלות מלאה בספק זהות חיצוני יוצרת נקודת כשל יחידה - אם Azure AD חווה תקלה, אף משתמש לא יכול להתחבר, גם אם המערכת שלכם עצמה תקינה לגמרי. תכנון נכון כולל מסלול חירום מוגבל (break-glass account) לצוות תפעול פנימי, כדי שלא נשארים לגמרי חסומים ממערכת הייצור שלכם בזמן תקלה חיצונית.

לקוח ארגוני דורש מכם SSO ולא יודעים מאיפה להתחיל? נשמח לעזור לתכנן את זה נכון בוואטסאפ.

העלות העסקית של אי-תמיכה ב-SSO

מוצר B2B שלא תומך ב-SSO לא רק "פחות נוח" ללקוחות ארגוניים - הוא לרוב פשוט לא עובר את תהליך אישור הספקים (vendor approval) של מחלקת האבטחה, ונופל מחוץ למשא ומתן עוד לפני שמישהו בכלל שקל את המחיר. הרבה חברות SaaS מתמחרות תמיכה ב-SSO כפיצ'ר בתוכנית ה-Enterprise, בדיוק כי מדובר בדרישת סף שרק חלק מהלקוחות זקוקים לה - אבל אלה שכן זקוקים לה, לרוב לא יחתמו בלעדיה.

בפועל, זה הופך את תמיכה ב-SSO לא לפיצ'ר שיווקי אלא לתנאי כניסה לשוק שלם. חברה שמוכרת רק ללקוחות קטנים יכולה לדחות את הפיתוח, אבל ברגע שהיא רוצה למכור לארגונים בינוניים וגדולים, השאלה כבר לא "האם כדאי" אלא "כמה מהר אפשר לספק את זה" - ולכן שווה לתכנן את הארכיטקטורה מראש כך שהוספת SSO בעתיד לא תדרוש שינוי יסודי במודל המשתמשים וההרשאות הקיים.

Just-in-Time Provisioning כתחליף קליל ל-SCIM מלא

מימוש SCIM מלא דורש עבודת פיתוח לא מבוטלת, ולא כל ספק זהות תומך בו באותה רמה. חלופה קלה יותר להתחלה היא Just-in-Time (JIT) Provisioning: כשמשתמש מתחבר בפעם הראשונה דרך SSO, המערכת יוצרת לו חשבון אוטומטית על בסיס הנתונים שמגיעים מספק הזהות, בלי תהליך הקצאה נפרד מראש. זה פותר את חלק מהבעיה - כניסה אוטומטית - אבל לא את הביטול האוטומטי כשעובד עוזב, ולכן מתאים בעיקר כפתרון ביניים עד שיש משאבים למימוש SCIM מלא.

בפועל, זו נקודת התחלה טובה למוצרים שרוצים להציע SSO מהר: אפשר להשיק תמיכה ב-JIT תוך פרק זמן קצר יחסית, ולתעדף את SCIM המלא רק כשלקוחות ספציפיים דורשים אותו במפורש כתנאי לחתימה. חשוב רק לוודא שגם בלי SCIM יש תהליך ידני ברור וזמין לביטול גישה מיידי, כדי שלא להישען אך ורק על ההנחה שמשתמש שאיבד גישה ל-IdP ממילא לא יוכל להתחבר.

איך בודקים אינטגרציית SSO לפני שהלקוח מנסה בעצמו

הפעם הראשונה שלקוח ארגוני מנסה להתחבר דרך ה-IdP שלו לא צריכה להיות גם הפעם הראשונה שהאינטגרציה נבדקת. ספקי זהות מרכזיים מציעים סביבות בדיקה (sandbox tenants) שמאפשרים לדמות זרימת SAML או OIDC מלאה כולל תרחישי כשל - תעודה שפגה, תשובה חתומה שגויה, משתמש בלי המאפיינים (attributes) הנדרשים - לפני שהאינטגרציה יוצאת ללקוח האמיתי הראשון.

שווה גם לתכנן מראש רשימת תרחישי קצה נפוצים ולבדוק כל אחד מהם בנפרד: מה קורה כשהמייל שמגיע מספק הזהות שונה מהמייל שכבר קיים במערכת אצל אותו משתמש, מה קורה כשמשתמש שייך לכמה ארגונים עם תצורות SSO שונות, ומה קורה כשההגדרות משתנות באמצע - למשל הלקוח עובר מ-Okta ל-Azure AD. תרחישים כאלה נדירים בבדיקה שטחית אבל שכיחים למדי בפועל אצל ארגונים גדולים עם מבנה IT מורכב.

מיפוי הרשאות: מקבוצות בספק הזהות לתפקידים במערכת

SSO פותר את שאלת הזהות - מי המשתמש - אבל לא את שאלת ההרשאה - מה מותר לו לעשות. ארגונים גדולים כבר מנהלים קבוצות מוגדרות היטב בספק הזהות שלהם - "כספים", "מנהלים", "IT" - וציפייה סבירה מהם היא שהקבוצות האלה ימופו אוטומטית לתפקידים המקבילים במערכת, במקום שמישהו יצטרך להגדיר ידנית הרשאה לכל משתמש חדש בנפרד אחרי שהוא כבר התחבר בהצלחה.

מיפוי כזה, שמגיע בדרך כלל כחלק ממאפייני (attributes) התשובה שמגיעה מספק הזהות בזמן ההתחברות או דרך SCIM, חוסך תהליך הרשאות ידני נפרד לכל עובד, ומוודא גם שכשעובד עובר תפקיד או מחלקה בארגון הלקוח, ההרשאה שלו במערכת מתעדכנת בהתאם בלי שצריך לזכור לעדכן אותה ידנית בנפרד ממערכת הזהויות הארגונית.

תמיכה במספר ספקי זהות במקביל, ללקוחות שונים

מוצר B2B שמשרת לקוחות ארגוניים שונים לרוב לא יכול להסתפק בחיבור לספק זהות יחיד - לקוח אחד עובד עם Azure AD, אחר עם Okta, שלישי עם Google Workspace. הארכיטקטורה צריכה לתמוך במבנה שבו כל לקוח (tenant) מוגדר מול ספק הזהות שלו באופן עצמאי, כך שהגדרות SSO של לקוח אחד לא משפיעות ולא מתערבבות עם הגדרות של לקוח אחר באותה מערכת.

זה דורש גם מנגנון ברור שמזהה, בזמן ניסיון ההתחברות, לאיזה לקוח וארגון המשתמש שייך, לפני שהוא בכלל מנותב לספק הזהות הנכון - בדרך כלל דרך תת-דומיין ייעודי לכל לקוח או דרך שלב ביניים שבו המשתמש מזין את כתובת הארגון שלו. תכנון נכון של שלב הזיהוי הזה מראש חוסך שינוי ארכיטקטוני כואב כשמצטרף הלקוח הארגוני השני שדורש ספק זהות שונה מהראשון.

מעבר לזיהוי הארגון הנכון, כדאי גם לתכנן מראש איך נראית מסך ההתחברות עצמו כשיש כמה אפשרויות - כניסה רגילה עם סיסמה, וגם SSO לארגונים שמוגדרים לכך. חוויית משתמש טובה מזהה מראש, על סמך כתובת המייל או תת-הדומיין, איזה מסלול להציג, במקום להשאיר את המשתמש לבחור בעצמו מתוך רשימת אפשרויות שרובן לא רלוונטיות עבורו.

שאלות נפוצות

מה ההבדל המעשי בין SAML ל-OIDC מבחינת זמן פיתוח?

OIDC בדרך כלל מהיר יותר למימוש כי הוא מבוסס JSON ו-REST, בעוד SAML דורש עבודה עם XML וחתימות דיגיטליות שמורכבות יותר לדבג. עם זאת, ארגונים גדולים ומגזר ציבורי רבים עדיין דורשים דווקא SAML, כך שתמיכה מלאה בשוק הארגוני כמעט תמיד דורשת את שני הפרוטוקולים בסופו של דבר, גם אם ההשקעה הראשונית מתחילה רק באחד מהם.

האם אפשר לתמוך ב-SSO רק לחלק מהלקוחות?

כן, זו הגישה הנפוצה בפועל - SSO מוצע כפיצ'ר בתוכנית Enterprise, ולקוחות בתוכניות אחרות ממשיכים להתחבר עם סיסמה רגילה (ולרוב MFA). חשוב לוודא שהמערכת תומכת בשני מסלולי ההתחברות במקביל בלי להתנגש, ושמעבר לקוח מהמסלול הרגיל ל-SSO לא דורש איפוס חשבון מלא.

מה קורה אם ספק הזהות של הלקוח נופל באמצע יום עבודה?

אם אין מסלול חירום, אף משתמש אצל אותו לקוח לא יכול להתחבר עד שהתקלה אצל ספק הזהות נפתרת - גם אם המערכת שלכם תקינה לחלוטין. לכן מומלץ לתכנן מסלול break-glass מוגבל לצוות התפעול הפנימי, שמאפשר גישה חירום למערכת בלי לעקוף לגמרי את מדיניות האבטחה, ולתעד כל שימוש בו בנפרד.

האם MFA נדרש גם כשיש כבר SSO?

לרוב האכיפה של MFA עוברת לספק הזהות עצמו - כלומר המשתמש מבצע MFA מול Azure AD או Okta, לא מול המערכת שלכם ישירות. חשוב לוודא בהגדרות שאתם אכן דורשים שהתשובה שמגיעה מספק הזהות כוללת אישור MFA, ולא רק אימות סיסמה בסיסי, כדי לא ליצור פער אבטחה בלי לשים לב.

כמה זמן לוקח להוסיף תמיכה ב-SSO למוצר קיים?

זה תלוי בכמה מבנה המשתמשים וההרשאות הקיים מוכן מראש לזהות חיצונית - מוצר עם מודל הרשאות פשוט יחסית ייקח פחות זמן מאשר מערכת עם היררכיית הרשאות מורכבת שצריכה למפות תפקידים מספק הזהות למערכת ההרשאות הפנימית, ולעיתים לשנות את מבנה הנתונים הקיים של המשתמשים.

תגיות: SSO · SAML · OIDC · MFA · SCIM · ניהול זהויות

← חזרה לבלוג · צור קשר