מה זה OAuth 2.0 ואיך הוא שומר על החשבונות שלכם

לחצתם פעם על "התחברות עם Google" באתר? חיברתם את חשבון הפייסבוק העסקי לכלי לתזמון פוסטים, או נתתם ל-n8n גישה ל-Google Sheets? בכל המקרים האלה עבדתם עם OAuth 2.0, גם אם לא שמעתם את השם.

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

במדריך הזה נסביר:

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

מה זה OAuth 2.0

OAuth 2.0 (קיצור של Open Authorization) הוא פרוטוקול שמאפשר לאפליקציה אחת לקבל גישה מוגבלת לנתונים שלכם בשירות אחר, בלי לקבל את שם המשתמש והסיסמה. במקום סיסמה האפליקציה מקבלת טוקן, מפתח דיגיטלי זמני שמאפשר לבצע רק את הפעולות שאישרתם.

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

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

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

מי עומד מאחורי הסטנדרט

OAuth 2.0 הוא סטנדרט פתוח של IETF, הארגון שמגדיר את פרוטוקולי האינטרנט. המפרט הבסיסי פורסם ב-2012 במסמך RFC 6749. הגרסה הראשונה של הפרוטוקול דרשה חתימה קריפטוגרפית מסובכת על כל בקשה, ולכן היה קשה לשלב אותה. הגרסה השנייה פשוטה יותר, ונבנתה סביב טוקנים מסוגים שונים.

מאז נוספו לסטנדרט הרחבות והמלצות אבטחה, ובשנים האחרונות הן מרוכזות בטיוטה של OAuth 2.1 ובמסמך ההמלצות הרשמי של IETF לאבטחת OAuth (RFC 9700). אם נתקלתם במדריכים ישנים, חלק מהשיטות שהם מתארים כבר לא מומלצות. נחזור לזה בהמשך.

אימות מול הרשאה: OAuth 2.0 ו-OpenID Connect

שני מונחים מתבלבלים כאן כל הזמן, ולכן כדאי להפריד ביניהם:

• אימות (Authentication) עונה על השאלה "מי אתם?". המערכת בודקת שאתם באמת מי שאתם טוענים שאתם, למשל לפי סיסמה, קוד ב-SMS או טביעת אצבע.
• הרשאה (Authorization) עונה על השאלה "מה מותר לכם לעשות?". המערכת קובעת לאילו נתונים ופעולות יש לכם גישה: רק לקרוא, גם לערוך, או גם למחוק.

OAuth 2.0 הוא פרוטוקול של הרשאה. הוא קובע מה אפליקציה רשאית לעשות עם הנתונים שלכם, אבל במקור הוא לא נועד לספר לאפליקציה מי אתם.

איפה נכנס OpenID Connect

את החלק של האימות פותר OpenID Connect (OIDC), שכבה שנבנתה מעל OAuth 2.0. היא מוסיפה לתהליך את ה-ID token, מסמך חתום דיגיטלית שמכיל פרטים בסיסיים על המשתמש: מזהה ייחודי, שם וכתובת מייל.

כשאתם לוחצים באתר על "התחברות עם Google", בדרך כלל עובדים שני הדברים יחד. OpenID Connect מאמת מי אתם, ו-OAuth 2.0 נותן לאתר גישה לפרטי הפרופיל הבסיסיים שאישרתם. הפרוטוקול הוותיק בשם OpenID, שמופיע לפעמים במדריכים ישנים, כבר לא בשימוש. היום מדברים על OpenID Connect.

בעולם הארגוני תפגשו גם את SAML, תקן ותיק יותר להתחברות אחת (SSO) למערכות של החברה. הוא נפוץ בחברות גדולות, אבל באתרים ובאפליקציות חדשים בוחרים בדרך כלל ב-OpenID Connect.

ארבעת התפקידים ב-OAuth 2.0

בכל תהליך OAuth משתתפים ארבעה גורמים. נשתמש בדוגמה של עורך התמונות ו-Google Drive:

1. בעל המשאב (Resource Owner). זה אתם, המשתמשים שמחליטים לתת גישה לנתונים שלכם.

2. הלקוח (Client). האפליקציה או האתר שמבקשים גישה, במקרה שלנו עורך התמונות. המונח "לקוח" כאן טכני, ולא קשור ללקוחות של העסק.

3. שרת ההרשאה (Authorization Server). המערכת שמאמתת אתכם, מציגה לכם את בקשת ההרשאה ומנפיקה טוקנים. אצלנו זה שרת ההתחברות של Google.

4. שרת המשאבים (Resource Server). המערכת שבה נמצאים הנתונים. היא מקבלת מהאפליקציה טוקן, בודקת אותו ונותנת גישה רק למה שמותר. אצלנו זה ה-API של Google Drive.

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

איך OAuth 2.0 עובד שלב אחר שלב

הזרימה הנפוצה ביותר נקראת Authorization Code. כך היא נראית בפועל:

1. הפניה לשרת ההרשאה. האפליקציה שולחת אתכם לדף ההתחברות של השירות, עם כתובת שמכילה כמה פרמטרים: client_id (מזהה האפליקציה), redirect_uri (לאן לחזור אחרי האישור) ו-scope (אילו הרשאות מבוקשות).

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

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

4. החלפת הקוד בטוקן. השרת של האפליקציה שולח את הקוד לשרת ההרשאה, יחד עם הפרטים המזהים שלו, ומקבל בתמורה access token.

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

למה צריך את השלב של הקוד, ולא לשלוח את הטוקן ישר? כי הקוד עובר דרך הדפדפן, שם קל יותר ליירט אותו. הטוקן עצמו עובר ישירות בין השרתים, בערוץ מוצפן. גם אם מישהו תפס את הקוד, בלי הפרטים של האפליקציה ובלי PKCE (נסביר בהמשך) הוא לא יכול להפוך אותו לטוקן.

טוקנים: access token ו-refresh token

ב-OAuth יש שני סוגים עיקריים של טוקנים:

• Access token הוא המפתח שאיתו האפליקציה ניגשת לנתונים. הוא תקף לזמן קצר, בדרך כלל מכמה דקות עד שעה. אם הוא נגנב, הנזק מוגבל בזמן.
• Refresh token מאפשר לאפליקציה לקבל access token חדש בלי לבקש מכם להתחבר שוב. הוא תקף לזמן ארוך יותר, ולכן שומרים אותו רק בצד השרת ובצורה מאובטחת.

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

זרימות OAuth: מה רלוונטי היום

OAuth 2.0 מגדיר כמה דרכים, שנקראות זרימות (flows או grant types), לקבל טוקן. כל אחת מתאימה לסוג אחר של אפליקציה. חשוב לדעת שההמלצות השתנו מאז 2012, ולכן נחלק אותן לשתי קבוצות.

הזרימות שמשתמשים בהן היום

• Authorization Code עם PKCE. הזרימה הסטנדרטית לכל אפליקציה שמשתמש מתחבר אליה: אתרים, אפליקציות מובייל ואפליקציות דפדפן (SPA). PKCE (Proof Key for Code Exchange) הוא מנגנון שמוסיף "סוד חד-פעמי" לכל בקשה, כך שגם קוד שיורט לא יעבוד אצל מי שיירט אותו. בעבר המליצו עליו רק למובייל, והיום הוא מומלץ לכל אפליקציה.
• Client Credentials. כשאין משתמש בתמונה, ומערכת אחת מדברת עם מערכת אחרת בשם עצמה. למשל, שרת שמושך כל לילה נתוני מכירות ממערכת אחרת. האפליקציה מזדהה עם client_id ו-client_secret ומקבלת טוקן.
• Device Authorization. למכשירים שקשה להקליד בהם, כמו טלוויזיה חכמה או מסוף. המכשיר מציג קוד קצר, אתם נכנסים לכתובת מהטלפון, מקלידים את הקוד ומאשרים.
• Refresh Token. לא זרימה עצמאית, אלא הדרך לחדש access token שפג תוקפו בלי לערב את המשתמש.

זרימות שכבר לא מומלצות

• Implicit. בעבר השתמשו בה באפליקציות דפדפן: הטוקן חזר ישירות בכתובת, בלי שלב הקוד. התברר שכך קל מדי לחשוף אותו, והיום מחליפים אותה ב-Authorization Code עם PKCE.
• Resource Owner Password. המשתמש מקליד את הסיסמה ישירות באפליקציה, והיא מעבירה אותה לשרת ההרשאה. זה סותר את כל הרעיון של OAuth, ולכן ההמלצות העדכניות של IETF פוסלות את הזרימה הזאת, ו-OAuth 2.1 מסיר אותה ואת Implicit.

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

איך רושמים אפליקציה ל-OAuth

כדי שאפליקציה תוכל לבקש הרשאות, צריך קודם לרשום אותה אצל השירות שאליו היא מתחברת. התהליך דומה ב-Google, Microsoft, Meta, GitHub ושירותים אחרים. ניקח את Google Cloud Console כדוגמה.

שלב 1: יוצרים פרויקט

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

שלב 2: מגדירים את מסך ההסכמה

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

שלב 3: יוצרים OAuth Client ומגדירים כתובות

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

שלב 4: בוחרים הרשאות מינימליות

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

שלב 5: שומרים את הסודות בצד השרת

בסוף מקבלים client_id ו-client_secret. המזהה הוא ציבורי, אבל הסוד חייב להישאר בשרת או במנהל סודות. אסור לשים אותו בקוד של האתר שרץ בדפדפן, באפליקציית מובייל או במאגר קוד ציבורי ב-GitHub.

לפני שכותבים קוד אפשר להתנסות בתהליך ב-OAuth 2.0 Playground של Google: בוחרים API, מאשרים הרשאה ורואים איך נראים הקוד והטוקנים בפועל.

איפה עסקים פוגשים OAuth ביום-יום

גם אם אתם לא מפתחים, OAuth נמצא בהרבה מהכלים שהעסק שלכם כבר משתמש בהם.

התחברות לאתר עם Google, Apple או Facebook

התחברות חברתית חוסכת למשתמשים עוד סיסמה, ולכם את הצורך לשמור סיסמאות ולטפל ב"שכחתי סיסמה". באתרי WordPress מוסיפים אותה בתוסף ייעודי, ב-Wix היא חלק מאזור החברים, וב-Webflow משתמשים בדרך כלל בכלים חיצוניים כמו Memberstack. בכל המקרים מאחורי הכפתור עובדים OpenID Connect ו-OAuth.

חיבורים באוטומציות: n8n, Make ו-Zapier

כשאתם מחברים ב-Make או ב-Zapier חשבון Google, Microsoft 365 או HubSpot, נפתח חלון התחברות של השירות עצמו. זה OAuth. ב-n8n בהתקנה עצמית לפעמים צריך ליצור בעצמכם OAuth Client ב-Google Cloud ולהזין את כתובת ה-redirect שה-n8n מציג. פירטנו את זה במדריך אוטומציות עם n8n לעסקים.

טיפ מהשטח: אפליקציה ב-Google שנמצאת במצב בדיקה (Testing) מקבלת refresh token שפג אחרי שבעה ימים. אם אוטומציה "נשברת" פעם בשבוע ודורשת התחברות מחדש, זו בדרך כלל הסיבה.

אינטגרציות בין מערכות

חיבור של האתר ל-CRM, למערכת דיוור, ל-Google Calendar לקביעת פגישות או ל-API של פלטפורמות פרסום מתבסס לרוב על OAuth. אם אתם רק מתחילים להכיר את הנושא, קראו קודם את המדריך שלנו מה זה REST API. שם הסברנו איך מערכות מדברות זו עם זו, ו-OAuth הוא האופן שבו הן מוכיחות שמותר להן.

כלי AI וסוכנים

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

OAuth ופרטיות בישראל

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

אבטחה וטעויות נפוצות ב-OAuth

OAuth בטוח רק כשמיישמים אותו נכון. אלה הכללים החשובים ביותר, והטעויות שאנחנו רואים הכי הרבה.

עקרונות שכדאי לשמור עליהם

• הרשאה מינימלית. כל אפליקציה מבקשת רק את מה שהיא צריכה. אם הטוקן ידלוף, הנזק יהיה מוגבל.
• HTTPS בכל מקום. כל העברה של קודים וטוקנים חייבת לעבור בערוץ מוצפן. אתר בלי HTTPS לא צריך לעבוד עם OAuth בכלל.
• טוקנים קצרים. access token תקף לזמן קצר, ופעולות רגישות, כמו שינוי פרטי חשבון או גישה לנתונים פיננסיים, מקבלות הגנה נוספת.
• PKCE בכל אפליקציה, כולל אתרים עם צד שרת.
• בדיקת כתובות מדויקת. רשימת redirect_uri סגורה ומדויקת, בלי תווים כלליים.
• פרמטר state. ערך אקראי שהאפליקציה שולחת ובודקת כשהמשתמש חוזר, כדי למנוע התקפה שבה מישהו "משתיל" לכם התחברות לחשבון שלו.

טעויות שעולות ביוקר

1. סוד בקוד צד הלקוח. client_secret או טוקנים שנשמרו ב-JavaScript של האתר, באפליקציה או ב-GitHub. כל מי שפותח את הקוד יכול לקחת אותם.

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

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

4. אין ניקיון של הרשאות. כלים ישנים שכבר לא בשימוש עדיין מחזיקים גישה לתיבת המייל או לדרייב. פעם ברבעון כדאי לעבור על "אפליקציות מחוברות" בחשבונות Google, Microsoft ו-Meta ולבטל את מה שמיותר.

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

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

איך RJL Studio עוזרת לחבר מערכות בצורה בטוחה

ב-RJL Studio אנחנו מחברים אתרים ב-Webflow, WordPress ו-Wix ל-CRM, למערכות דיוור, ליומנים, לוואטסאפ ולכלי AI. אנחנו בונים את האינטגרציות דרך API, webhooks ו-n8n, Make ו-Zapier, ומקפידים על הכללים שתיארנו כאן: הרשאות מינימליות, סודות בצד השרת, חשבונות שירות במקום חשבונות אישיים, וחידוש אוטומטי של טוקנים עם התראה כשמשהו נכשל.

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

שאלות נפוצות על OAuth 2.0

האם OAuth 2.0 מעביר את הסיסמה שלי לאפליקציה?

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

מה ההבדל בין OAuth 2.0 ל-OpenID Connect?

OAuth 2.0 עוסק בהרשאה: מה אפליקציה רשאית לעשות עם הנתונים שלכם. OpenID Connect היא שכבה מעליו שעוסקת באימות: מי אתם. כפתור "התחברות עם Google" משתמש בדרך כלל בשניהם יחד.

איך מבטלים גישה שנתתי לאפליקציה?

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

האם OAuth 2.0 מתאים גם לעסק קטן?

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

מה זה OAuth 2.1?

OAuth 2.1 היא גרסה מאוחדת של הסטנדרט, שמרכזת את ההמלצות שהצטברו מאז 2012. היא מחייבת PKCE בזרימת Authorization Code ומסירה את זרימות Implicit ו-Password. אם אפליקציה כבר עובדת לפי ההמלצות העדכניות של OAuth 2.0, המעבר אליה כמעט לא דורש שינויים.