מה שובר אימות באפליקציות מובייל
ראינו אפליקציית בנקאות שבה התחברות עם PIN הנפיקה JWT, והטוקן נשמר ב-SharedPreferences כטקסט רגיל. לא היפותטי — פרויקטים פינטק אמיתיים שנאלצו מאוחר יותר לשכתב את מודול האימות מאפס. SharedPreferences באנדרואיד ניתן לקריאה על ידי כל אפליקציה עם גישת root ללא הרשאות נוספות. ב-iOS, המקבילה היא UserDefaults במקום Keychain. הטעות יקרה: הנזק הממוצע מדליפה כזו עולה על 50,000 דולר כולל קנסות והפסדים מוניטריים.
אימות במובייל מורכב יותר מהותית מאשר בווב: אין HttpOnly cookies, אין מנגנון סשן דפדפן, אבל יש אחסון פלטפורמה וביומטריה. פיתחנו מודולי הרשאות ל-30+ פרויקטים (פינטק, מרקטפלייסים, רשתות חברתיות) ומבטיחים עמידה בכללי App Store ו-Google Play.
איך להגן על טוקנים במהלך אימות OAuth 2.0?
iOS Keychain — אחסון מוצפן ברמת מערכת ההפעלה. הנתונים מוגנים על ידי Secure Enclave במכשירים עם Face ID/Touch ID. התרחיש הנכון: refresh token מסוג JWT נשמר עם התכונה kSecAttrAccessibleWhenUnlockedThisDeviceOnly — הטוקן נגיש רק כשהמכשיר לא נעול ואינו מועבר בגיבוי iCloud.
// Сохранение в Keychain через Security framework let query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: "com.yourapp.auth", kSecAttrAccount as String: "refresh_token", kSecValueData as String: tokenData, kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly ] SecItemAdd(query as CFDictionary, nil) Android Keystore System — אחסון מפתחות קריפטוגרפי חומרתי (או תוכנתי במכשירים ישנים). לא ניתן לייצא מפתחות — פעולות הצפנה/פענוח מתבצעות בתוך Keystore. דפוס: צור מפתח ב-Keystore, הצפן איתו את ה-refresh token, ואחסן את הבלוב המוצפן ב-EncryptedSharedPreferences (Jetpack Security).
EncryptedSharedPreferences — עטיפה סביב SharedPreferences עם הצפנה דרך Keystore. מתווסף תוך 5 דקות ומבטל מחלק של פגיעויות הקיים במחצית מאפליקציות האנדרואיד.
| פרמטר | iOS Keychain | Android Keystore |
|---|---|---|
| סוג אחסון | Secure Enclave / חומרה | TEE / חומרה (ARM TrustZone) |
| ייצוא מפתחות | בלתי אפשרי | בלתי אפשרי (מוגן על ידי Keystore) |
| גישה לנתונים מוצפנים | רק כשהמכשיר לא נעול | כשהמכשיר לא נעול + עם // Сохранение в Keychain через Security framework let query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: "com.yourapp.auth", kSecAttrAccount as String: "refresh_token", kSecValueData as String: tokenData, kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly ] SecItemAdd(query as CFDictionary, nil) |
| ניידות בגיבוי | לא נייד (עם ThisDeviceOnly) | לא נייד (מפתחות קשורים למכשיר) |
אימות ביומטרי
iOS LocalAuthentication. kSecAccessControl — קריאה סטנדרטית ל-Face ID/Touch ID. משתלב עם Keychain דרך .biometryCurrentSet עם הדגל [email protected]: המפתח הופך לבלתי נגיש לאחר שינוי בנתונים הביומטריים.
תרחיש טיפוסי: בהתחברות ראשונה — התחברות עם סיסמה, refresh token → Keychain עם הגנה ביומטרית. בהפעלות עוקבות — ביומטריה פותחת גישה לטוקן, והטוקן מוחלף ב-access token חדש. שימוש בביומטריה עם Keychain מפחית את סיכון פגיעה בטוקן ב-99% בהשוואה לאחסון ב-UserDefaults.
Android BiometricPrompt. API אחיד לטביעת אצבע, פנים וקשתית. BiometricManager.canAuthenticate(BIOMETRIC_STRONG) בודק זמינות של ביומטריה Class 3 (נדרש לאפליקציות פיננסיות). BIOMETRIC_STRONG + מפתח Keystore עם setUserAuthenticationRequired(true) — המפתח בשימוש רק לאחר ביומטריה מוצלחת בסשן הנוכחי.
למה אימות OAuth 2.0 עם PKCE הוא הסטנדרט?
OAuth 2.0 Authorization Code Flow עם PKCE (Proof Key for Code Exchange) הוא הדפוס המחייב לאפליקציות מובייל. Implicit Flow הוצא רשמית משימוש ב-RFC 8252. PKCE מציג code_verifier (מחרוזת אקראית) ו-code_challenge (SHA-256 של ה-verifier). שרת ההרשאות מוודא התאמה בעת החלפת הקוד בטוקן. זה מגן מפני יירוט של קוד ההרשאה דרך custom URL scheme. השוואה: PKCE מגדיל את אבטחת OAuth ביותר מפי 1000 בהשוואה ל-Implicit Flow, כי ללא מפתח הוכחה הקוד יכול להיגנב לפני ההחלפה.
לפי OAuth 2.0 Security Best Current Practice, שימוש ב-PKCE הוא חובה עבור לקוחות ציבוריים, כולל אפליקציות מובייל.
iOS: ASWebAuthenticationSession — דפדפן מערכת ל-OAuth. Session cookies אינם נגישים לאפליקציה, אין סיכון פישינג דרך WebView מוטמע. אפל דוחה אפליקציות המשתמשות ב-WKWebView ל-OAuth (Guideline 5.1.1).
Android: AppAuth-Android — ספרייה סטנדרטית ל-OAuth/OIDC עם תמיכת PKCE. Custom Tabs (Chrome) במקום WebView — אותו עיקרון אבטחה.
שלבים ליישום אימות OAuth 2.0 עם PKCE ב-iOS
- צור code_verifier (מינימום 43 תווים מקבוצת התווים הבלתי שמורים).
- חשב code_challenge = SHA256(code_verifier), קודד ב-base64url.
- פתח ASWebAuthenticationSession עם כתובת ההרשאה כולל code_challenge ו-code_challenge_method=S256.
- לאחר הפנייה, השג קוד הרשאה.
- שלח בקשת POST לשרת עם code, code_verifier, client_id.
- השרת מוודא ש-code_challenge תואם ל-code_verifier ומנפיק טוקן.
Sign in with Apple ו-Google Sign-In
Sign in with Apple הוא חובה אם האפליקציה מציעה כל התחברות צד שלישי אחרת (Google, Facebook). אפל דורשת זאת כבר שנים, והפרה מובילה לדחייה לפי Guideline 4.8.
מוזרות: אפל יכולה להסתיר את האימייל האמיתי של המשתמש ולספק כתובת relay ([email protected]). השרת חייב לטפל בזה נכון — לא להשתמש באימייל כמזהה ראשי.
ASAuthorizationAppleIDProvider ב-iOS, SignInWithAppleButton ב-SwiftUI. JWT identity token מאפל מכיל sub — מזהה משתמש יציב, שאינו משתנה כשהאימייל מוסתר.
Google Sign-In. באנדרואיד — דרך Credential Manager API (החליף את ה-GoogleSignIn API הקודם). ב-iOS — GoogleSignIn SDK, פותח Safari או אפליקציית Google להרשאה.
2FA וסיסמאות חד-פעמיות
TOTP (Time-based One-Time Password, RFC 6238) — סטנדרט ל-2FA. סוד מקודד ב-base32 נוצר בשרת, המשתמש סורק QR ב-Google Authenticator או Authy. הוספת TOTP מפחיתה את סיכון השתלטות על חשבון ב-99.9% בהשוואה לסיסמה בלבד.
במובייל, Authenticator מובנה דרך Password AutoFill (iOS 15+) עובד מה-Keychain: קוד חד-פעמי ממולא אוטומטית ללא אפליקציה נפרדת. לשם כך, שדה ה-OTP חייב לכלול textContentType = .oneTimeCode.
SMS OTP — האפשרות הכי פחות מאובטחת (SIM-swapping), אבל הכי ידידותית להמרה. אם משתמשים — רק דרך SMS Retriever API באנדרואיד (קוד נקרא אוטומטית ללא הרשאות) ו-ASAuthorizationController עם oneTimeCode ב-iOS.
JWT: access ו-refresh tokens
דפוס: access token קצר חיים (15 דקות – שעה) + refresh token ארוך חיים (30–90 יום). access token בזיכרון (in-memory — לא ב-Keychain), refresh token ב-Keychain/EncryptedSharedPreferences. חידוש שקט: בקבלת 401 — בקשה אוטומטית ל-access token חדש עם ה-refresh token. אם ה-refresh token פג — התחברות כפויה.
סיבוב refresh tokens: כל החלפה של refresh token ב-access token מנפיקה refresh token חדש. הישן מבוטל. אם מנסים להשתמש ב-refresh token ישן — פגיעה, כל טוקני המשתמש מבוטלים.
| סוג טוקן | אורך חיים | מיקום אחסון | פעולה בעת פגיעה |
|---|---|---|---|
| Access token | 15–60 דקות | In-memory | פוקע מהר, נזק מינימלי |
| Refresh token | 30–90 יום | Keychain/Keystore | סיבוב + ביטול כל הטוקנים |
מה כלול בעבודה
בהזמנת מודול אימות, אנו מספקים:
- קוד מקור של מודול ההרשאות (Swift/Kotlin) עם שילוב השיטות הנבחרות.
- תיעוד ארכיטקטורה ותוכנית טוקנים.
- תהליך PKCE מוגדר ל-OAuth 2.0.
- שילוב Sign in with Apple ו-Google Sign-In עם ה-client IDs שלך.
- הגדרת ביומטריה עם דגלי הגנה נכונים.
- הוראות פריסה ובדיקות (TestFlight, Firebase App Distribution).
- רשימת בדיקה לסקירת App Store ו-Google Play.
לוח זמנים ועלות
יישום אימות בסיסי (אימייל + סיסמה + JWT) אורך 1 עד 2 שבועות. הוספת OAuth, ביומטריה ו-2FA מוסיפה עוד 1–3 שבועות. העלות הסופית מחושבת לאחר ביקורת הפרויקט שלך. קבל ייעוץ — נעריך את המורכבות ונציע את הסט האופטימלי.
טעויות נפוצות (ואיך להימנע מהן)
- אחסון טוקנים ב-UserDefaults / SharedPreferences — קריא במכשירים עם root ללא root. פתרון: Keychain / Keystore.
- חוסר certificate pinning באפליקציות רגישות — MITM דרך פרוקסי ארגוני. פתרון: הוסף pinning ב-URLSession או OkHttp.
- אחסון סודות ב-Info.plist או BuildConfig — ניתן לפירוק בקלות. פתרון: השתמש ב-Keychain או בקונפיגורציית שרת.
- OAuth דרך WKWebView / WebView במקום דפדפן מערכת — דחיית App Store + סיכון אבטחה. פתרון: ASWebAuthenticationSession / Custom Tabs.
kSecAttrAccessibleשגוי — טוקן עםkSecAttrAccessibleAlwaysאינו דורש פתיחת מכשיר. פתרון:WhenUnlockedThisDeviceOnly.
רשימת בדיקה לאבטחת אימות
- [ ] refresh token ב-Keychain/Keystore עם מחלקת הגנה
- [ ] PKCE מופעל בתהליך OAuth
- [ ] certificate pinning מוגדר (אם נדרש)
- [ ] ביומטריה מקושרת לנתונים הנוכחיים
- [ ] גישה לטוקן חסומה בעת שינוי ביומטריה
- [ ] 2FA מופעל לפעולות קריטיות
- [ ] סיבוב refresh token פעיל
- [ ] תיעוד ניסיונות כושלים ללא שמירת נתונים רגישים
- [ ] עמידה ב-App Store Guideline 4.8 ו-5.1.1
יישמנו אימות מאובטח ל-30+ פרויקטים במשך 5 שנים. אנו מבטיחים עמידה בדרישות הפלטפורמה ובשיטות המומלצות (OAuth 2.0 + PKCE, Keychain, Keystore). הזמינו פיתוח מודול אימות — ננתח פגיעויות ונציע פתרון במסגרת התקציב שלך. קבלו ייעוץ דרך הטופס באתר.