הטמעת OAuth 2.0 עם PKCE: מדריך למפתחי מובייל

הטמעת OAuth 2.0 עם PKCE: מדריך למפתחי מובייל

לעתים קרובות אנו רואים פרויקטים שבהם הרשאת OAuth 2.0 מיושמת באמצעות סכמות מיושנות או לא מאובטחות. אנו משתמשים ב-Authorization Code Flow עם PKCE—האפשרות הנכונה היחידה עבור אפליקציות native. Implicit Flow הוצא משימוש עם RFC 9700, ו-Client Credentials אינו מספק הקשר משתמש. אם מציעים לך Implicit Flow עבור אפליקציית מובייל—זו דגל אדום.

כיצד PKCE עובד

PKCE (Proof Key for Code Exchange) פותר את הבעיה של חוסר client_secret בקוד מובייל. האפליקציה מייצרת code_verifier אקראי, מגזימה אותו עם SHA-256, ושולחת את code_challenge לשרת ההרשאות. בעת החלפת הקוד לטוקן, השרת מוודא שה-verifier תואם ל-challenge. יירוט הקוד ושימוש בו ללא verifier הוא בלתי אפשרי.

// iOS - генерация verifier
var buffer = [UInt8](repeating: 0, count: 32)
_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
let verifier = Data(buffer).base64URLEncodedString()

// Android
val bytes = ByteArray(32)
SecureRandom().nextBytes(bytes)
val verifier = Base64.encodeToString(bytes, Base64.URL_SAFE or Base64.NO_PADDING or Base64.NO_WRAP)

Universal Links לעומת Custom URL Scheme עבור OAuth 2.0

סכמה כמו // iOS - генерация verifier var buffer = [UInt8](repeating: 0, count: 32) _ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer) let verifier = Data(buffer).base64URLEncodedString() יכולה להיות מיורטת על ידי כל אפליקציה הרושמת את אותו מזהה. Universal Links ב-iOS ו-App Links ב-Android מאמתים תעודות דומיין דיגיטליות באמצעות // Android val bytes = ByteArray(32) SecureRandom().nextBytes(bytes) val verifier = Base64.encodeToString(bytes, Base64.URL_SAFE or Base64.NO_PADDING or Base64.NO_WRAP) או myapp://callback. רק האתר שלך יכול להיות מורשה לפתוח את האפליקציה שלך.

ההגדרה דורשת:

• קובץ AASA ב-apple-app-site-association
• יכולת assetlinks.json עם https://yourapp.com/.well-known/apple-app-site-association
• טיפול בכתובות URL ב-Associated Domains או applinks:yourapp.com

ספריות עבור OAuth 2.0 באפליקציות מובייל

אל תיישם את הפרוטוקול מאפס. AppAuth (iOS/Android), react-native-app-auth, ו-flutter_appauth מטפלים ב-PKCE, פתיחת דפדפן, ועיבוד הפניות. AppAuth אמין ומהיר יותר מיישום מותאם אישית—מפחית את זמן הפיתוח פי 3 ומבטל 80% מהפגיעויות הנפוצות.

אחסון טוקנים

שמור את טוקן הגישה קצר המועד בזיכרון (לדוגמה, scene(_:continue:) ב-SwiftUI). אחסן את טוקן הרענון באחסון מוגן: Keychain ב-iOS, EncryptedSharedPreferences ב-Android. מעל 70% מאפליקציות המובייל מאחסנות טוקנים בצורה לא מאובטחת—אל תהיה אחד מהם. יירוט טוקן כזה מ-application(_:continue:restorationHandler:) במכשיר rooted הוא וקטור תקיפה אמיתי.

סיבוב טוקן רענון וזיהוי פשרה

סיבוב טוקן רענון הוא נוהג חובה עבור אפליקציות production. עם כל החלפה מוצלחת, השרת מנפיק טוקן גישה חדש ומבטל מיד את טוקן הרענון הישן. אם תוקף גונב טוקן ומנסה להשתמש בטוקן שכבר אינו תקף, השרת מזהה את הקונפליקט ומבטל את כל הסשן. Keycloak מאפשר סיבוב עם @State, AWS Cognito משתמש בפרמטר Refresh Token Revocation.

זמני חיים מומלצים: טוקן גישה 15–60 דקות, טוקן רענון 30–90 ימים עם הארכת חלון נע על כל שימוש. תמיד יישם התנתקות עם ביטול טוקן בצד השרת—קרא ל-endpoint של SharedPreferences לפי RFC 7009. טוקן רענון ארוך חיים ללא ביטול התנתקות הוא המקור הנפוץ ביותר לפשרות חשבון באפליקציות מובייל.

טיפול ב-State והגנת CSRF

פרמטר ה-state הוא מחרוזת אקראית שהאפליקציה שולחת בבקשת ההרשאה ובודקת בהפניה. ללא בדיקת state, מתקפת CSRF אפשרית: תוקף מחליף קוד הרשאה של מישהו אחר, והאפליקציה מקשרת את החשבון שלהם לסשן של הקורבן. AppAuth מייצר ומאמת state אוטומטית. אם אתה כותב לקוח OAuth ידנית, state הוא חובה. רישום ביקורת (audit-logging) של כל בקשת הרשאה עם טביעת אצבע מכשיר, IP, ו-User-Agent עוזר לזהות חריגות. הניסיון שלנו עם 30+ אינטגרציות OAuth מראה שיומני אירועים תופסים אירועי גישה לא מורשים תוך דקות.

השוואת זרמי OAuth

מה כלול בעבודה שלנו

אנו מספקים: תיעוד אינטגרציה, גישה לסביבות בדיקה, הדרכת צוות, ותמיכה לאחר השקה. השירות שלנו מתחיל ב-$2,500 עבור אינטגרציה של ספק יחיד, ואנו מבטיחים הפחתה של 30% בממצאי ביקורת אבטחה. הניסיון שלנו של 5+ שנים באבטחת מובייל מבטיח שהפתרון שלך יעבור את בדיקת App Store Review (סעיפים 4.8, 5.1). אנו מיישמים את האינטגרציה turnkey ב-5–10 ימי עסקים עבור ספק אחד.

טעויות נפוצות

שגיאות נפוצות כוללות: שימוש ב-Implicit flow, אחסון טוקנים ב-code_verifier, וחוסר PKCE. אנו צוות של מהנדסים מוסמכי OAuth—מעל 100 אפליקציות נבדקו, 70% נמצאו עם אחסון טוקנים לא מאובטח בתחילה. תן לנו לבדוק את הקוד שלך ולספק הערכת פרויקט. השאר בקשה—נצביע על המקרה שלך.