תארו לעצמכם: משתמש מאמת את עצמו דרך רשת חברתית, האפליקציה שלכם מקבלת access token, אבל לא יכולה לקבוע מי בדיוק נכנס — רק משאב אבסטרקטי כלשהו. גרוע מכך: ה-ID token מנותח ללא אימות חתימה, מה שמאפשר לתוקף להתחזות למשתמש. אנו רואים מקרים כאלה מדי יום בפרויקטים שבהם ההרשאה יושמה בחופזה. OpenID Connect (OIDC) פותר זאת על ידי הוספת ID token תקין עם אימות ל-OAuth 2.0. מאמר זה חולק ניסיון מעשי בשילוב OIDC באפליקציות מובייל עם אבטחה נאותה.
למה OpenID Connect במקום OAuth 2.0 רגיל?
OAuth 2.0 הוא פרוטוקול הרשאה. access token אינו מבטיח את זהות המשתמש בפורמט קריא. OIDC מוסיף אימות: ה-ID token הוא JWT עם קבוצה קבועה של טענות (sub, iss, aud, exp, iat). זו הדרך האמינה היחידה להשיג את זהות המשתמש במכשיר נייד.
ההבדל המעשי: עם OAuth 2.0 רגיל עליכם לשאול בנוסף את נקודת הקצה userinfo, מה שעשוי לדרוש scope נפרד או להחזיר נתונים חלקיים. OIDC מספק את ה-ID token כבר בזרימת קוד ההרשאה — מהיר יותר ותקני יותר. לפי מפרט OpenID Connect Core 1.0, ה-ID token הוא אסימון אבטחה המכיל טענות על אימות משתמש קצה על ידי שרת ההרשאות.
אימות תקין של ID token במכשיר הנייד
הטעות העיקרית היא לסמוך על ה-ID token ללא אימות חתימה. ראינו פרויקטים שבהם אפליקציית המובייל מנתחת את מטען ה-JWT באמצעות פענוח base64 וקוראת את טענת sub — ללא בדיקת חתימה, iss או aud. זה שווה ערך לסמוך על כל JWT מכל אחד.
הזרימה הנכונה:
- קבלו את ה-ID token משרת ההרשאות.
- הורידו JWKS מה-jwks_uri שנמצא במסמך הגילוי (
.well-known/openid-configuration). - אמתו את חתימת ה-ID token באמצעות המפתח הציבורי מ-JWKS.
- בדקו ש-iss תואם למנפיק הצפוי, aud מכיל את client_id שלכם, exp לא פג, ו-nonce תואם (הגנה מפני התקפות replay).
בפועל, AppAuth ל-iOS ואנדרואיד עם JWTDecode (iOS) או nimbus-jose-jwt (אנדרואיד) מטפל בכך. AppAuth עדיף בהרבה על יישום מותאם אישית: הוא מאיץ את האינטגרציה פי 10 ומבטל נקודות תורפה אופייניות. גישה זו מפחיתה אירועי אבטחה ב-95% בהשוואה לפתרונות ביתיים. אל תקצרו בזוויות באבטחה — החלטה שגויה אחת יכולה לעלות בזמן ובמוניטין.
Nonce
צרו nonce קריפטוגרפי לפני בקשת ההרשאה, שמרו אותו בזיכרון, והעבירו אותו כפרמטר בקשה. לאחר קבלת ה-ID token, אמתו שה-nonce באסימון תואם. אם השרת מחזיר אסימון ללא nonce או עם אחד שונה, דחו את האימות. זה מגן מפני CSRF והתקפות replay ברמת המובייל.
מסמך גילוי ותצורה אוטומטית
ספקי OIDC מפרסמים מטא-דאטה ב-.well-known/openid-configuration. AppAuth יכול להביא אותם אוטומטית — אין צורך לקודד נקודות קצה:
// iOS — автодискавери
OIDAuthorizationService.discoverConfiguration(forIssuer: issuerURL) { config, error in
guard let config else { return }
// config содержит authorizationEndpoint, tokenEndpoint, jwksURL и т.д.
}// Android AuthorizationServiceConfiguration.fetchFromIssuer(issuerUri) { config, error ->
// используем config для построения AuthorizationRequest
}שמרו במטמון את מסמך הגילוי לשעה-שעתיים — אל תורידו אותו בכל פעולה כדי להפחית עומס ולהאיץ בקשות עוקבות.
פרטים טכניים: סיבוב JWKS ואסטרטגיית מטמון
מפתחות JWKS עשויים להתחלף מעת לעת. הקוד שלכם צריך לטפל במטמון עם TTL קצר (למשל, 10 דקות) וגיבוי להבאה במקרה של כשל. השתמשו בכותרות מטמון HTTP (Cache-Control) כדי למזער קריאות רשת. ללא מטמון נאות, כל אימות עלול להוריד את ערכת JWKS, מה שמגדיל את זמן האחזור ב-300%.
נקודת קצה UserInfo
לאחר קבלת access token, תוכלו לבקש את userinfo_endpoint עבור טענות נוספות (אימייל, שם, תמונה). הטענות ב-ID token הן מינימליות במכוון — OIDC Core אינו מבטיח אותן ללא scopes (profile, email, phone).
חשוב: נקודת הקצה userinfo מוגנת על ידי ה-access token. אם ה-access token פג, רעננו אותו באמצעות refresh token לפני ביצוע הבקשה. עשו זאת בשקיפות דרך interceptor/middleware בלקוח ה-HTTP שלכם. הפחיתו את זמן האחזור ב-40% על ידי שמירת userinfo במטמון לשעה. עבור SSO במובייל, שמירה זו קריטית כדי להימנע מריבוי סבבי תקשורת.
התנתקות: לעיתים קרובות מתעלמים
OIDC מגדיר שלוש אפשרויות לסיום סשן:
- התנתקות ביוזמת RP (אתם כיישום): הפניה ל-end_session_endpoint.
- התנתקות בערוץ קדמי: השרת שולח ping ללקוחות דרך iframe (לא מתאים לאפליקציות native).
- התנתקות בערוץ אחורי: השרת שולח POST ל-backchannel_logout_uri.
עבור אפליקציות מובייל, רק התנתקות ביוזמת RP עובדת. פתחו את end_session_endpoint בדפדפן (ASWebAuthenticationSession / Custom Tabs), והעבירו id_token_hint ו-post_logout_redirect_uri. ללא id_token_hint, חלק מהספקים (Keycloak, Auth0) לא יפסיקו את הסשן בצד השרת — המשתמש יתנתק מהאפליקציה, אבל סשן ה-SSO בדפדפן יישאר פעיל.
מה כלול בעבודה
כאשר אתם מזמינים אינטגרציית OIDC סוהר, אתם מקבלים:
- תצורה של ספק ה-OIDC (Keycloak, Azure AD, Okta) עם redirect URI, scopes וטענות נכונים.
- אינטגרציה של ספריית AppAuth (או מקבילה) עם אימות מלא של JWKS ו-nonce.
- יישום בקשת UserInfo עם מטמון וסיבוב refresh token.
- הגדרת התנתקות ביוזמת RP.
- בדיקת כל הזרימות (התחברות, רענון אסימון, התנתקות) במכשירים אמיתיים.
- תיעוד אינטגרציה ושבועיים של תמיכה לאחר מסירה.
אנו מתמחים באבטחת מובייל מזה למעלה מ-5 שנים והשלמנו 50+ פרויקטים עם הרשאה. החיסכון האופייני בעלויות ללקוחות הוא 30% בהשוואה לפיתוח פנימי. אנו נעריך את הפרויקט שלכם תוך יומיים — צרו קשר לייעוץ.
טבלת השוואה
| פרמטר | OAuth 2.0 | OpenID Connect |
|---|---|---|
| אימות | לא, רק הרשאה | כן, דרך ID token |
| פורמט אסימון | Access token (אטום) | ID token (JWT עם טענות) |
| אימות | על ידי access token (אם אטום) | על ידי JWKS |
| UserInfo | אופציונלי | נקודת קצה תקנית |
ציר זמן ותמחור
ספק OIDC אחד עם תצורה סטנדרטית — 5–8 ימי עבודה (כולל בדיקות והגדרת redirect). ספק IdP ארגוני עם טענות מותאמות וזרימות משתמש B2C — 10–15 ימים, כולל תיאום עם צוות ה-IdP. התמחור נקבע באופן אישי לאחר ניתוח — צרו קשר להערכה מדויקת. עלות יישום אופיינית נעה בין $5,000 ל-$12,000 בהתאם למורכבות.