מדריך לרישום אפליקציות ו-OAuth לשילוב אפליקציות מאובטח

By Mirko Peters · 2026-05-04

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

Automatically translated with AI from the original post. Read the English original

בואו נודה באמת: רישום אפליקציות ואימות נכונים אינם עניין של מעקב אחר פרוטוקולים חכמים בלבד; מדובר בהבטחה שהמשתמשים, הנתונים והארגון שלכם נשארים מאובטחים. מדריך זה מפרק את רישום האפליקציות ואת OAuth 2.0, כך שתוכלו לבנות אימות מאובטח ותואם תקנים עם Microsoft Entra ID (שנקרא בעבר Azure AD) או עם ספק הזהויות שתבחרו.

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

מדריך רישום אפליקציות ו-OAuth — הגדרה

רישום אפליקציה הוא התהליך של יצירת זהות אפליקציה והגדרתה אצל ספק זהויות (כגון Azure AD, Google או Auth0), כך שהאפליקציה תוכל לבקש אימות והרשאה בצורה מאובטחת. התהליך כולל בדרך כלל הקצאת מזהה לקוח (client ID), סוד לקוח (client secret) או אישור, הגדרת כתובות הפניה חוזרת (redirect URIs), קביעת הרשאות והיקפים (scopes), והגדרת סוגי המענקים (grant types) המותרים.

8 עובדות מפתיעות על רישום אפליקציות ו-OAuth

• סודות לקוח עלולים לדלוף דרך יומנים: מפתחים רבים מתעדים בטעות מזהי לקוח וסודות במהלך איתור תקלות, וכך פרטי הכניסה של רישום האפליקציה נחשפים, אלא אם מדיניות הרישום מוקשחת; יש להתייחס למזהים תמיד בזהירות.
• כתובות הפניה חוזרת מחמירות מכפי שתצפו: ספקי OAuth דורשים לעיתים התאמה מדויקת של כתובות הפניה חוזרת (כולל לוכסן סוגר וסכמת הפרוטוקול), ולכן הבדלים עדינים יכולים לשבור זרימות שנראות מוגדרות כראוי ברישום האפליקציה.
• לקוחות ציבוריים אינם דורשים סודות, אך עדיין צריך להגן עליהם: אפליקציות מקומיות ואפליקציות דף יחיד נחשבות ללקוחות ציבוריים ללא סודות לקוח, ועדיין עליהן להשתמש ב-PKCE ובגישות הפניה חוזרת מאובטחות כדי למנוע יירוט קוד.
• היקפים אינם מבטיחים הרשאות מינימליות כברירת מחדל: בעת רישום אפליקציות, היקפי ברירת המחדל או מסכי ההסכמה עשויים לבקש הרשאות רחבות; הגבלה מפורשת של היקפים והסכמה מדורגת הם חיוניים כדי לאכוף הרשאות מינימליות.
• ביטול אסימונים אינו נתמך באופן אוניברסלי: לא כל ספקי הזהויות מכבדים ביטול אסימונים או מספקים התנתקות מיידית בין הפעלות, ולכן רישום האפליקציה חייב לכלול מדיניות לניהול הפעלות ולאסימוני רענון.
• מטא-נתונים של רישום אפליקציה הם משטח תקיפה: שמות אפליקציות, לוגואים וכתובות הפניה חוזרת שנחשפים לציבור עלולים לסייע לתוקפים ליצור הונאות פישינג משכנעות או מתקפות הפניה פתוחה, אם לא מנהלים אותם בזהירות.
• הקצאה אוטומטית עלולה להגדיר הרשאות באופן שגוי: אוטומציה של CI/CD שיוצרת רישומי אפליקציות מעניקה לעיתים הרשאות API רחבות מדי, או נכשלת ברישום כתובות הפניה חוזרת נדרשות, וכך נוצרים כשלים שקטים או חשיפה אבטחתית.
• חוויית המשתמש במסך ההסכמה משפיעה על החלטות אבטחה: משתמשים ומנהלים מעניקים לעיתים הסכמה רחבה מדי, משום שמסכי ההסכמה מבלבלים; עיצוב מסכי הסכמה ברורים ומינימליים ברישום האפליקציה ובמדריך OAuth מפחית העברת הרשאות יתר.

הבנת OAuth 2.0 ויסודות Entra ID

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

אבל מה קורה כשרוצים לאמת משתמשים, ולא רק להעניק גישה למידע? כאן נכנס לתמונה OpenID Connect, שמוסיף שכבת זהות והתחברות מאובטחת מעל OAuth 2.0. באמצעות OpenID Connect, ספקים כמו Microsoft Entra ID ו-Google מאפשרים לאפליקציות שלכם לוודא מי המשתמשים ולבקש הרשאות מוגבלות למשאבים נוספים, והכול בחוויה אחידה אחת.

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

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

מדריך רישום אפליקציות ו-OAuth: טעויות נפוצות ב-OAuth 2.0 וב-Entra ID

מדריך רישום האפליקציות וה-OAuth הזה מפרט טעויות נפוצות שצוותים עושים בעת יישום OAuth 2.0 עם Microsoft Entra ID (Azure AD), ואת השפעתן על האבטחה, על התפקוד ועל חוויית המשתמש.

• ערבוב בין מושגי OAuth 2.0 לבין מושגי OpenID Connect (למשל, ציפייה לאסימוני ID במקום שבו מונפקים רק אסימוני גישה).
• שימוש שגוי בתהליכי OAuth, כגון התייחסות ל-implicit flow כמתאים לאפליקציות מודרניות, במקום Authorization Code עם PKCE.

• רישום שגוי של redirect URIs (סכמה שגויה, לוכסן סופי, או שימוש ב-localhost בסביבת ייצור).
• שימוש בהגדרות של לקוח ציבורי עבור אפליקציות סודיות, או להפך, מה שגורם לשגיאות אסימון או לחשיפת סודות.
• אי-הגדרת הרשאות API/היקפים נכונים, או שכחה להעניק הסכמת מנהל במקומות שבהם היא נדרשת.

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

• אימות לא תקין של אסימונים (מנפיק, קהל יעד, חתימה, nonce, exp).
• אחסון לא מאובטח של אסימוני גישה או אסימוני רענון (למשל, local storage בדפדפן ללא הגנה).
• סמיכה על תוכן האסימון מבלי לאמת את ההיקפים או התפקידים שמוחזרים מ-Entra ID.

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

• אי-טיפול ב-refresh token rotation ובמדיניות ביטול של Entra ID, מה שגורם להתנתקויות לא צפויות.
• שימוש באסימוני רענון בלקוחות ציבוריים ללא הגנות מתאימות (יש להשתמש ב-PKCE ובאורכי חיים מתאימים לאסימונים).

• אי-הגדרה נכונה של הגדרות ריבוי דיירים לאפליקציות שמיועדות לפעול בין דיירים.
• שימוש בנקודות קצה לא נכונות (ייעודיות לדייר לעומת common) ונתקלים בבעיות כניסה או הסכמה.

• אי-בדיקה של התנהגות האפליקציה כאשר נאכפות Conditional Access, MFA או מדיניות תאימות מכשירים.
• הנחה שטוקנים יונפקו תמיד באותם תנאים אינה נכונה – מדיניות עלולה לחסום אותם או לדרוש שלבי אימות נוספים.

• שימוש בזרימות OAuth ישנות או בדפוסי Azure AD v1 במקום בהמלצות של פלטפורמת הזהויות של Microsoft (v2).
• שימוש בדוגמאות קהילתיות מבלי לוודא שהן מיישמות שיטות אבטחה נכונות (PKCE, אחסון מאובטח, אימות תקין).

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

השתמשו במדריך רישום האפליקציות וב-OAuth הזה כדי לבדוק את המימוש שלכם, לפעול לפי שיטות העבודה המומלצות של פלטפורמת הזהויות של Microsoft, ולהפחית סיכוני אבטחה ותפעול בעת שילוב OAuth 2.0 עם Entra ID.

דרישות מוקדמות לרישום אפליקציה להגדרת OAuth

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

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

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

לבסוף, אספו פרטים טכניים כמו כתובות URL מותרות להפניה בעת הכניסה, אילו פלטפורמות תתמכו (iOS, Android, Windows?) ואילו הרשאות (או "היקפים") האפליקציה צריכה לבקש. יישור הפרטים האלה מראש חוסך זמן רב בזמן ההגדרה ומונע תקלות נפוצות, כגון כתובות URI לא תקינות או אי-התאמה בסוגי החשבונות בהמשך.

כיצד לרשום את האפליקציה שלכם ב-Microsoft Entra ID

רישום האפליקציה ב-Microsoft Entra ID (לשעבר Azure AD) מניח את היסוד לכל מה שקשור לאימות ולגישה ל-API. התהליך מתחיל במרכז הניהול של Entra, שבו תיצרו רישום אפליקציה חדש – ותעניקו לאפליקציה זהות ייחודית (הנקראת "מזהה לקוח" או "client ID") בתוך הספרייה של הארגון.

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

לאחר בחירת קהל היעד, מגדירים את פרטי הפלטפורמה של האפליקציה. באפליקציות אינטרנט תוסיפו כתובת URI להפניה; באפליקציות לנייד או לעמודים יחידים, הגדרות ספציפיות לפלטפורמה מבטיחות חוויית כניסה חלקה. פורטל Entra ילווה אתכם בהוספת אישורים, כגון סודות לקוח או אישורים (certificates), שבאמצעותם האפליקציה תוכיח את זהותה.

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

היתרונות העיקריים של רישום האפליקציה ב-Microsoft Entra ID

• ניהול זהויות מרכזי: ניהול האימות, ההרשאות וזהויות המשתמשים של האפליקציה ממקום אחד, מדייר Entra ID יחיד.
• זרימות OAuth מאובטחות: ניצול התמיכה המובנית ב-OAuth 2.0 וב-OpenID Connect ליישום כניסה מאובטחת, הנפקת טוקנים וגישה מואצלת.
• כניסה אחודה (SSO): מתן כניסה אחודה חלקה בין Microsoft 365, Azure ושירותים משולבים אחרים, לשיפור חוויית המשתמש וצמצום בקשות סיסמה.
• שליטה מדויקת בהרשאות: הגדרה וניהול של הרשאות API ברמת פירוט גבוהה, חוויות הסכמה ועקרון הרשאה מינימלית (least-privilege) עבור הרשאות מואצלות והרשאות אפליקציה כאחד.
• גישה מותנית ומדיניות אבטחה: אכיפת MFA, תאימות מכשירים, מיקום ומדיניות מבוססת סיכון כדי להגן על גישת אפליקציות ועל נתונים רגישים.
• ניהול סודות ואישורים של אפליקציות: אחסון והחלפה תקופתית של סודות לקוח, תעודות ותצורה מרובת דיירים באופן בטוח, תוך שימוש בשיטות לניהול מחזור חיים כדי לשמור על תקינות השימושים באפליקציה.
• אינטגרציה עם שירותי הפלטפורמה של Microsoft: גישה ל-Microsoft Graph, ל-Azure APIs, ל-Teams וליכולות פלטפורמה נוספות באמצעות אסימונים סטנדרטיים ומודלי הסכמה אחידים.
• תמיכה באפליקציות היברידיות ורב-פלטפורמיות: אימות משתמשים באינטרנט, במכשירים ניידים, בשולחן העבודה ובתרחישים של שירות לשירות, באמצעות פרוטוקולי זהות עקביים, תוך וידוא שכל אפליקציה משתמשת במזהים הנכונים.
• ניטור וביקורת: שימוש ביומנים, בדוחות כניסה ובתובנות אבטחה כדי לזהות חריגות, לחקור אירועים ולשמור על תאימות.
• יכולת הרחבה ומוכנות לארגונים גדולים: ניצול התשתית הגלובלית של Entra ID, אפשרויות מרובות דיירים ותכונות ארגוניות לתמיכה בבסיסי משתמשים הגדלים וצרכים ארגוניים מורכבים.
• כלי פיתוח ותיעוד: שימוש ב-SDK, בקוד לדוגמה ובמדריך רישום אפליקציות ו-OAuth כדי להאיץ את היישום ולפתור תרחישים נפוצים.

הגדרת כתובות Redirect URI והגדרות פלטפורמה לאפליקציות Entra ID

הגדרת כתובות Redirect URI נכונות במהלך רישום האפליקציה נראית פשוטה, אך שלב זה קריטי מבחינת אבטחה. כתובות Redirect URI אומרות ל-Entra ID לאן לשלוח את המשתמשים (יחד עם האסימונים שלהם) לאחר ניסיון כניסה מוצלח. בעת ההגדרה, Entra אוכף כללים מחמירים: אין דומיינים עם תווים כלליים (wildcard), אין סכמות URI מסוכנות, ואין פתחים שתוקפים יכולים לנצל.

אם אתם בונים אפליקציית דף יחיד (SPA), בדרך כלל תשתמשו בכתובת HTTPS המפנה לדומיין של האפליקציה, כדי להבטיח תקשורת מאובטחת לצורך קבלת הנתונים. אפליקציות מקומיות זקוקות לסכמות URI הקשורות לשם חבילת האפליקציה (bundle) או לשם החבילה (package), וזה מונע מאפליקציות אקראיות לחטוף אסימונים באותו מכשיר. באפליקציות אינטרנט נהוג להשתמש בנקודות קצה של callback לכניסה, וכל אחת מהן חייבת להירשם במפורש.

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

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

עקרונות מרכזיים ב-OAuth Flows וניהול אסימונים

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

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

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

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

יישום זרימת קוד ההרשאה של OAuth

1. התחלת ההרשאה: האפליקציה שלכם מפנה את המשתמש לנקודת הקצה להרשאה של Entra ID, וכוללת פרטים כגון מזהה הלקוח (client ID), היקפי ההרשאה המבוקשים ופרמטר state ייחודי ואקראי להגנה מפני CSRF.
2. מתן הרשאה על ידי המשתמש: המשתמש בוחן את מסך ההסכמה – שמציג בבירור אילו הרשאות האפליקציה צריכה – ומאשר את הגישה.
3. קבלת קוד ההרשאה: לאחר ההסכמה, Entra ID מפנה אותך בחזרה ל-redirect URI שציינת, ומעביר אליך קוד הרשאה זמני וגם את ערך ה-state שהגדרת בתחילה.
4. החלפת הקוד באסימונים: השרת האחורי שלך שולח בצורה מאובטחת את הקוד, יחד עם פרטי ה-client credentials שלך (וגם את ה-PKCE code verifier, אם נעשה בו שימוש), אל נקודת הקצה של האסימונים ב-Entra. אם האימות מצליח, תקבל אסימון גישה (ולעיתים גם אסימון רענון).
5. שימוש באסימונים לגישה ל-APIs: האפליקציה שלך מצרפת כעת את אסימון הגישה לכל בקשת API, ובכך מוכיחה הרשאה מטעם המשתמש. אסימוני גישה תקפים לזמן קצר בלבד, וכך נחשפים פחות, ואילו אסימוני רענון מאפשרים לקבל אסימוני גישה חדשים לאורך סשנים מתמשכים.

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

שיטות עבודה מומלצות לניהול תפוגת אסימוני גישה ואסימוני רענון

1. אחסון מאובטח של אסימונים: השתמשו בפתרונות אחסון מאובטחים שמספקת מערכת ההפעלה, כמו Keychain ב-iOS, Keystore ב-Android, או מנהלי סודות מוצפנים בצד השרת. לעולם אל תקודדו אסימונים בקבצים הבינאריים של האפליקציה, ואל תחשפו אותם ביומנים.
2. כבדו את משכי החיים של האסימונים: עקבו אחר ערך התפוגה (exp claim) שבכל אסימון, ובצעו רענון באופן יזום לפני שהאסימון פג, כדי להימנע מכשלי בקשות API ומחוויית משתמש גרועה.
3. תמכו בסבב אסימונים (token rotation): השתמשו תמיד באסימון הרענון החדש ביותר בכל בקשה, והשליכו במהירות אסימונים שנעשה בהם שימוש חוזר או שאינם עדכניים. כך מצטמצמת ההשפעה אם אסימון נפרץ.
4. הגבילו הרשאות לכל אסימון: בקשו רק את ההיקפים (scopes) שאתם צריכים, והעדיפו אסימוני גישה קצרי מועד. כך מצטמצם באופן משמעותי הנזק אם אסימון דלף או נגנב.

אבטחת מימושי OAuth בהקשרים שונים

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

טכנולוגיות כמו PKCE (Proof Key for Code Exchange) מהדקות את זרימת הקוד ללקוחות ציבוריים, ומונעות מתוקפים לירט קודים ולהמיר אותם לאסימונים. מנגד, לאפליקציות שפועלות בסביבות מאובטחות, סודות לקוח ותעודות הם הכלים הטובים ביותר לאימות זהות וניהול אמון.

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

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

כיצד PKCE מגן על הרשאות OAuth בלקוחות ציבוריים

PKCE (Proof Key for Code Exchange) הוא קריטי בעת שימוש ב-OAuth באפליקציות לנייד ובאפליקציות מבוססות דפדפן — לקוחות ציבוריים שבהם אי אפשר לאחסן סוד. כאשר מתחילים את זרימת קוד ההרשאה, האפליקציה יוצרת "code verifier" אקראי ו-"code challenge" מגובב. ערכים אלה נעים יחד עם המשתמש ועד לבקשת האסימון הסופית. גם אם תוקף יתפוס קוד הרשאה, הוא לא יוכל להמיר אותו לאסימון בלי ה-verifier הסודי, וכך התקפות יירוט קוד הופכות לכמעט בלתי אפשריות ב-Microsoft Entra ID ובפלטפורמות דומות.

ניהול סודות לקוח, תעודות ו-Federated Credentials

• סודות לקוח (Client Secrets): משמשים אפליקציות סודיות, כמו שירותי קצה אחורי מהימנים, להוכחת זהותן בנקודת הקצה של האסימונים. אחסנו סודות בכספות מאובטחות, סובבו אותם באופן קבוע, ואל תשלחו אותם לעולם בקוד של צד הלקוח.
• תעודות (Certificates): לרמת ביטחון גבוהה יותר, השתמשו בתעודות X.509 במקום סודות רגילים, כדי לחזק את אבטחת המזהים של האפליקציה. תעודות מאפשרות אימות מאובטח יותר באמצעות זוגות מפתחות ציבורי/פרטי, והן אידיאליות לתעשיות מפוקחות או לאפליקציות עם דרישות תאימות קפדניות.
• Federated Credentials: להגדרות של "הביאו את הזהות שלכם" (bring your own identity), השתמשו בפרטי כניסה מאוחדים כמו federated identity של Microsoft Entra או ספקים חיצוניים. כך מתאפשר אימות בלי לטפל בסודות ישירות, ומפחיתים את עומס הניהול.
• טיפול בצינורות אוטומציה (Pipeline Handling): בתהליכי CI/CD, הזריקו וסובבו סודות ותעודות לפי הצורך, ואל תקודדו אותם בקוד המקור. התראות אוטומטיות על תפוגה מוסיפות שכבת חוסן נוספת.

אבטחת טוקנים וצמצום חשיפת הרשאות

• יש לאחסן טוקנים רק במיקומים מאובטחים (כספות מערכת ההפעלה, סביבות שרת מוצפנות), ולעולם לא באחסון הנגיש למשתמשים.
• יש להעביר טוקנים תמיד דרך HTTPS או ערוצים מאובטחים אחרים. HTTP רגיל חושף את הטוקנים ליירוט.
• יש לבקש הרשאות מינימליות ("scopes") לכל טוקן. לעולם אל תבקשו יותר ממה שהאפליקציה שלכם צריכה.
• יש לבצע ביקורת שוטפת של השימוש בטוקנים ושל הקצאות ההרשאות, כדי למנוע התרחבות שקטה ובלתי מזוהה של הרשאות.

שיטות מומלצות ל-OAuth באפליקציות ניידות ובאפליקציות מקומיות

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

ערכת ה-SDK הנכונה (כמו MSAL עבור Microsoft Entra ID) מבצעת חלק גדול מהעבודה הכבדה: ניהול טוקנים, טיפול בלוגיקת הרענון והשתלבות באחסון המאובטח ברמת מערכת ההפעלה. עבור טוקנים רגישים, ערכות ה-SDK בוחרות כברירת מחדל את המאגר הבטוח ביותר, ומטפלות בהתנהגויות הייחודיות למכשיר או למערכת ההפעלה.

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

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

קישורים אוניברסליים ואימות מקורי של צד ראשון

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

פתרון בעיות בשגיאות OAuth ותרחישים מתקדמים

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

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

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

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

פענוח תשובות שגיאה של OAuth וכשלים בהחלפת קודים

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

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

• חשבונות שירות (זרימת client credentials): מאפשרים לאפליקציות להתאמת ללא משתמש. מתאים מאוד לאוטומציה ולעבודות שרת לשרת.
• זרימת קוד מכשיר: מיועדת לטלוויזיות חכמות ולמכשירי IoT, ומבקשת מהמשתמשים להשלים את התהליך במכשיר אחר. מתאימה למקומות שבהם אין דפדפן זמין.
• הרחבת Mutual TLS: משתמשת באישורים גם בשרת וגם בלקוח, ומעלה את רמת האבטחה לאינטגרציות רגישות, ומבטיחה שהאפליקציה משתמשת בשיטות אימות חזקות.
• רישום לקוחות דינמי: מאוטם את תהליך הקליטה של אפליקציות במערכות SaaS גדולות או מרובות דיירים, ומפשט את ניהול פרטי ההזדהות בקנה מידה רחב.

מדריך רישום אפליקציות ו-OAuth ב-Entra ID

יתרונות

• ניהול זהויות מרכזי: משתלב עם Microsoft Entra ID ומספק זהות עקבית למשתמשים ולאפליקציות בין השירותים.
• בקרות אבטחה חזקות: תומך ב-OAuth 2.0, ב-OpenID Connect, ב-Conditional Access ובהרשאות מדויקות (scopes ותפקידים).
• פרוטוקולים סטנדרטיים בתעשייה: מבוסס על תקני OAuth ו-OIDC הנתמכים באופן נרחב, ומפשט את the הפעולה ההדדית עם כלים וספריות של צד שלישי.
• תצורת אפליקציה מפורטת: מאפשר להגדיר כתובות הפניה מחדש (redirect URIs), אישורים וסודות, הרשאות API ואפשרויות מיתוג לאפליקציות.
• מודל הסכמה מדורג: תומך בהרשאות מואצלות והרשאות ברמת האפליקציה, עם תהליכי הסכמת מנהל שמגבילים אפליקציות בעלות הרשאות יתר.
• תכונות לארגונים: תומך באפליקציות מרובות דיירים, בשיתוף פעולה B2B ובשילוב עם שירותי Microsoft 365 ו-Azure.
• ניטור וביקורת: יומנים מובנים, כניסות ומסלולי ביקורת לרישומי אפליקציות ולתהליכי OAuth, לסיוע בציות ובפתרון תקלות.
• כלי פיתוח וערכות SDK: ערכות SDK נרחבות של פלטפורמת הזהות של Microsoft, תיעוד ודוגמאות התחלה מהירה שמייעלים את היישום.

חסרונות

• מורכבות למתחילים: מודלי התצורה וההרשאות (כתובות הפניה מחדש, כתובות תגובה, זרימות implicit לעומת authorization code, scopes) עלולים לבלבל מפתחים חדשים.
• עקומת למידה תלולה בתכונות האבטחה: Conditional Access, זהויות מנוהלות והגדרות טוקנים מתקדמות דורשים ידע אבטחתי מעמיק כדי להגדיר אותם בצורה בטוחה.
• סיכון להתפשטות הרשאות: הסכמה לא נכונה או הרשאות רחבות לאפליקציות עלולות להוביל לאפליקציות בעלות הרשאות יתר אם לא נבדקות באופן קבוע.
• דקויות בניהול טוקנים: טיפול ב-refresh tokens, בתוקף הטוקנים ובביטולם כולל התנהגויות ספציפיות לפלטפורמה שעלולות לגרום לתקלות אינטגרציה.
• שיקולים לגבי גבולות דיירים: התנהגות של אפליקציות מרובות דיירים והנחיות הסכמת מנהל מוסיפות מורכבות תפעולית בתרחישים בין-דיירים.
• שינויים בממשק ובמונחים: Microsoft מעדכנת מדי פעם את הממשק והשמות של Entra (Azure AD → Entra ID), מה שעלול ליצור אי-התאמה בתיעוד או בלבול.
• תלות במערכת האקולוגית של Microsoft: הקישור ההדוק לתכונות Entra ID עלול להגביל את הניידות לספקי זהות שאינם של Microsoft בלי עבודה מחדש.
• סיכון לתצורה שגויה: הגדרות רישום אפליקציה שגויות (למשל כתובות הפניה מחדש, כתובות תגובה, הגדרות זרימה implicit) עלולות ליצור פרצות אבטחה או לשבור זרימות אימות.

צעדים הבאים ומשאבי קהילה מרכזיים להצלחה ב-OAuth

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

גם את זה לא חייבים לפתור לבד. התיעוד של Microsoft Entra ID עמוק כמו אגם מישיגן, ומלא במדריכים מעודכנים, דוגמאות קוד וכל המפרטים הטכניים שכדאי שיהיו לידכם. כדאי להפוך להרגל לבדוק עדכונים, במיוחד כש-OAuth ותקני זהות ענן ממשיכים להשתנות.

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

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

רשימת בדיקה למדריך רישום אפליקציות ו-OAuth - Entra ID

• תכנון סוג האפליקציה ומודל הגישה – בחרו בין דייר יחיד, מרובה דיירים או חשבונות Microsoft אישיים, וקבעו אם מדובר ב-SPA, באפליקציית אינטרנט, באפליקציית נייד, ב-daemon או באפליקציית שירות.
• רישום האפליקציה ב-Entra ID — יצירת App Registration חדש עם שם ברור וסוגי חשבונות נתמכים.
• הגדרת כתובות Redirect URI — הוספת כתובות redirect/callback נכונות לכל פלטפורמה (https, סכמה מותאמת אישית, localhost לפיתוח).
• הגדרת הגדרות פלטפורמת היישום — הפעלת אפשרויות הפלטפורמה SPA, Web ו-Mobile & Desktop, והגדרת זרימות implicit/grant לפי הצורך.
• יצירה וניהול של סודות לקוח (Client Secrets) — יצירת סודות לקוח עבור לקוחות סודיים (confidential clients), רישום תאריך התפוגה ואחסון מאובטח ב-Key Vault.
• שימוש באישורים לאימות — העלאת אישורי מפתח ציבורי (public key certificates) עבור לקוחות סודיים בסביבת ייצור, במקום סודות ארוכי טווח.
• הגדרת הרשאות API — הוספת scopes והרשאות של Microsoft Graph או של API מותאם אישית, הנדרשים לאפליקציה.
• מתן הסכמת מנהל במקום הנדרש — בקשה ותיעוד של הסכמת מנהל להרשאות מואצלות (delegated) שדורשות הסכמה ברמת הדייר.
• הגדרה וחשיפה של scopes מותאמים אישית (אם מדובר ב-API) — הוספת scopes תחת “Expose an API” והגדרת שמות ה-scopes, התיאורים ושמות התצוגה של הסכמת המנהל.
• הגדרת App Roles (במידת הצורך) — הגדרת תפקידי אפליקציה ותפקידים מואצלים לצורך בקרת גישה מבוססת תפקידים, והקצאתם למשתמשים, לקבוצות או לאפליקציות לקוח.
• הגדרת CORS ל-SPAs הקוראים ל-APIs — הוספת מקורות מותרים ב-API, או הגדרת מדיניות CORS בשער (gateway).
• בחירת זרימת OAuth 2.0 — בחירה בין Authorization Code (עם PKCE ללקוחות ציבוריים), Client Credentials עבור daemon apps, או Device Code, לפי המקרה.
• יישום PKCE ללקוחות ציבוריים — חובה להשתמש ב-Proof Key for Code Exchange עבור SPAs ואפליקציות native, כדי למנוע יירוט של הקוד.
• אימות נכון של טוקנים — וידוא ה-issuer, ה-audience, החתימה, תוקף הטוקן והטענות (claims) הנדרשות, באמצעות ספריות הזהות של Microsoft או לוגיקת אימות JWT.
• שימוש ב-Microsoft Authentication Libraries (MSAL) — עדיפות ל-MSAL לצורך קבלת טוקנים, שמירה במטמון, רענון וטיפול מאובטח בכל הפלטפורמות.
• הגדרת גישה מותנית ו-MFA (במידת הצורך) — החלת מדיניות על רישום האפליקציה או על זרימות הכניסה של המשתמשים, לאכיפת בקרות אבטחה.
• ניטור כניסות ורישומי ביקורת — הפעלת רישום לוגים ובדיקת אירועי כניסה, הסכמות ופעולות מנהל ביומני Entra ID.
• יישום הרשאות מינימליות (least privilege) — בקשת ההרשאות הנדרשות בלבד, והעדפת הסכמה הדרגתית (incremental consent) לצמצום החשיפה.
• החלפה סדירה של סודות ואישורים — יישום החלפה אוטומטית והתראות על אישורים שעומדים לפוג.
• אבטחת קוד ואחסון בצד הלקוח — הימנעות משמירת סודות באפליקציות לקוח, שימוש באחסון מאובטח ובשיטות העבודה המומלצות של כל פלטפורמה.
• בדיקת זרימות כניסה וטוקנים בסביבות dev/staging — אימות זרימות האימות, משכי חיים של טוקנים, לוגיקת רענון, טיפול בשגיאות וחוויית הסכמה.
• הכנת תיעוד למשתמשים ולמנהלים — כולל שלבי הסכמה, ההרשאות הנדרשות והנחיות לפתרון בעיות.
• סקירה ועדכון תקופתי של רישומי האפליקציות — ביקורת הרשאות, תפקידים, סודות ורישומים, לאיתור אפליקציות מיושנות או שאינן בשימוש.
• יישום הגנות רשת ו-API — שקלו שימוש ב-API Management, WAF, הגבלת קצב (rate limiting) ו-service endpoints להגנה על ה-APIs בצד השרת.

שימוש באסימון גישה (access token) של Azure ב-OAuth לאימות

מהו מדריך רישום אפליקציה & OAuth, ומדוע הוא חשוב?

מדריך רישום אפליקציה & OAuth מסביר כיצד לרשום אפליקציית לקוח אצל ספק זהות (לדוגמה, באמצעות Azure), וכיצד לממש זרימות הרשאה של OAuth 2.0, כך שהאפליקציה תוכל לבקש גישה למשאבים מוגנים בצורה מאובטחת. זה קריטי בין שמפתחים אפליקציות אינטרנט, אפליקציות דף יחיד (SPA), אפליקציות שולחן עבודה או שרתי אינטרנט בצד השרת, מאחר שהאפליקציה זקוקה ל-App ID או Application ID, וכן ל-Client ID ולסוד לקוח (Client Secret) עבור לקוחות סודיים (confidential clients), כדי להשיג access token ולקבל, במידת הצורך, id token.

כיצד אני רושם אפליקציית Azure ומשיג את ה-Application ID וה-App ID?

כדי לרשום אפליקציית Azure, יש להיכנס ל-Azure portal וליצור App Registration חדש, לספק שם וכתובות Redirect URI, ולשמור את ה-Client ID (Application ID) המוצג בסקירת האפליקציה. אם האפליקציה היא לקוח סודי (שרת אינטרנט או אפליקציית אינטרנט מסורתית), יש ליצור Client Secret לשימוש יחד עם ה-Client ID וה-Client Secret. האפליקציה הרשומה משמשת בתהליך ההרשאה ולבקשת access tokens משירותי Microsoft.

איזו זרימת הרשאה של OAuth 2.0 עליי להשתמש בה עבור אפליקציות דף יחיד (SPA)?

על אפליקציות דף יחיד (SPA) להשתמש בהענקת קוד הרשאה עם PKCE (Proof Key for Code Exchange) ולא בזרם המרומז (implicit flow), כדי להבטיח שהאפליקציה תקבל טוקנים באופן מאובטח. הענקת הקוד עם PKCE מאפשרת לאפליקציה להחליף את הקוד בטוקן גישה באופן מאובטח מתוך לקוח מבוסס דפדפן, כך שאפליקציות דף יחיד יכולות להשתמש ב-OAuth מבלי לחשוף סודות לקוח בדפדפן.

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

בקשת הרשאה נשלחת לנקודת הקצה של ההרשאה אצל ספק הזהויות, והיא כוללת בדרך כלל את client_id (מזהה האפליקציה), response_type (לדוגמה code), redirect_uri, scope ו-state. עבור אפליקציות דף יחיד המשתמשות בהענקת קוד עם PKCE, יש לכלול גם את code_challenge ואת code_challenge_method. המשתמש מאמת את זהותו ונותן הסכמה (OAuth consent), ושרת ההרשאה מחזיר קוד אל ה-redirect URI, שאותו האפליקציה יכולה להחליף בטוקן גישה.

כיצד מתבצעת החלפת הקוד בטוקן גישה (code for an access token) בקוד?

לאחר קבלת קוד ההרשאה, אפליקציית הלקוח שולחת בקשת POST לנקודת הקצה של הטוקנים, הכוללת את הקוד, את client_id (ואת client_secret עבור לקוחות חסויים), את redirect_uri ואת grant_type=authorization_code. בשימוש ב-PKCE יש לכלול גם את code_verifier. נקודת הקצה מחזירה טוקן גישה, טוקן זהות (כאשר התבקש), ולעיתים גם טוקן רענון (refresh token) לקבלת טוקן גישה חדש כאשר טוקן הגישה פג.

כיצד ניתן לקבל טוקן גישה ולהשתמש בו לקריאה ל-APIs?

יש לקבל טוקן גישה על ידי השלמת זרם ההרשאה של OAuth 2.0 שבחרתם וקריאה לנקודת הקצה של הטוקנים. לאחר שקיבלתם את טוקן הגישה, שלחו אותו בכותרת Authorization בפורמט Bearer בעת קריאה לשירותי Microsoft או ל-APIs אחרים (לדוגמה Google Calendar או APIs מותאמים אישית). אמתו את הטוקנים בצד שרת האינטרנט או בצד המשאב, כדי לוודא שבקשות האפליקציה מורשות.

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

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

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

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

מהו ההבדל בין רישום אפליקציית לקוח לבין אפליקציה בתוך דייר?

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

כיצד מבקשים גישה לשירותי Microsoft, ואילו הרשאות נדרשות?

בקשו גישה על ידי ציון ההיקפים (scopes) שהאפליקציה צריכה בבקשת ההרשאה. עבור שירותי Microsoft, הגדירו הרשאות API ברישום האפליקציה ב-Azure, ולאחר מכן בקשו מהמשתמשים הסכמה (OAuth consent) או הנחו מנהל להעניק הסכמה ברמת הדייר כולו. האפליקציה מבקשת היקפים כגון User.Read או היקפים של APIs מותאמים אישית במסגרת בקשות היישום, ומשתמשת בטוקן הגישה כדי לקרוא לשירותים.

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

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

מהו תפקידו של redirect URI, ומדוע עליו להתאים לרישום האפליקציה?

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

כיצד מאמתים משתמשים ומקבלים id token בנוסף ל-access token?

כדי לקבל id token, בקשו את ההיקף openid ואת response_type שמפעיל הנפקת id token (זרימת קוד הרשאה עם openid). ה-id token מכיל תביעות זהות על המשתמש שאומת. השתמשו ב-id token כדי להתחבר לאפליקציית הלקוח, וב-access token כדי לקרוא ל-APIs במורד הזרם.

אילו זרימות הרשאה חלות על אפליקציות web מסורתיות לעומת single page apps?

אפליקציות web מסורתיות (בצד השרת) משתמשות בדרך כלל בזרימת קוד הרשאה עם client credentials (מזהה לקוח וסוד לקוח), ומחליפות את הקוד בשרת ה-web. Single page apps משתמשות במענק קוד הרשאה עם PKCE וללא סוד לקוח. אפליקציות שולחן עבודה משתמשות גם הן ב-PKCE. בחרו את הזרימה לפי סוג האפליקציה ולפי המקום שבו ניתן לאחסן סודות בצורה מאובטחת.

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

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

כיצד מאמתים טוקנים בשרת ה-web או ב-API שלי?

שרת ה-web או ה-API צריכים לאמת את החתימה, המנפיק, הקהל (audience – מזהה אפליקציה או application id), ותוקף הטוקן של ה-access token או ה-id token. השתמשו במסמך ה-discovery של הספק כדי לקבל את מפתחות החתימה, ופעלו לפי ספריות האימות המומלצות לפלטפורמה שלכם. האימות מבטיח שיתקבלו רק בקשות מאפליקציות שאומתו והורשו.

מהו התהליך לבקשת access token עבור שירות backend באמצעות client credentials?

בתרחישים שרת-לשרת, רשמו אפליקציית Azure, העניקו לה הרשאות אפליקציה, ואז השתמשו בזרימת client credentials: שלחו POST לנקודת הקצה של הטוקן עם grant_type=client_credentials, client_id, client_secret ו-scope או resource. נקודת הקצה מחזירה access token שה-backend יכול להשתמש בו כדי לקרוא לשירותי Microsoft או ל-APIs מוגנים.

כיצד מטפלים בהסכמת OAuth והסכמת מנהל ביישומים מרובי דיירים?

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

אילו צעדי פתרון תקלות כדאי לבצע אם בקשת ההרשאה שלי נכשלת?

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

כיצד אפשר לשלב APIs של צד שלישי, כמו Google Calendar, עם האפליקציה הרשומה שלי?

כדי לשלב את Google Calendar או APIs אחרים של צד שלישי, יש ליישם את זרימות הרשאה OAuth 2.0 הנדרשות על ידי אותם ספקים. האפליקציה שלכם חייבת לבקש את ההיקפים הנכונים עבור ה-API של צד שלישי, ולטפל במחזורי חיים נפרדים של טוקנים. ייתכן שתצטרכו רישומי אפליקציית לקוח נפרדים אצל כל ספק, ולתאם את השגת ה-access tokens עבור כל שירות.

מתי כדאי להשתמש ב-device code flow או בזרימות מיוחדות אחרות למכשירים מסוימים?

השתמשו ב-device code flow עבור מכשירים עם קלט מוגבל שבהם אין דפדפן זמין. הזרימה מאפשרת למשתמש לבקר בכתובת אימות במכשיר אחר ולהתאמת. זו אחת מזרימות ההרשאה הספציפיות הנתמכות לצד קוד הרשאה, client credentials וזרימות refresh token, כדי להתאים לסוגי מכשירים ותצורות יישום שונים.