תהליך משתמש לאימות

סקירה כללית

מטרת תהליך האימות היא לזהות ולאמת את המשתמש מול 'משלב התשלומים' (משלב).

האימות הוא קלט לשיטות אחרות. במיוחד ל-associateAccount ול-capture. המשמעות היא שהוכחת האימות משמשת כקלט (פרמטר) לשתי השיטות האלה.

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

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

איך פועל הזרימה

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

  1. אימות של הפניות אוטומטיות
  2. אימות SMS-MT OTP

אימות של הפניות אוטומטיות

ייתכן שמשתמש Google שזקוק לאימות יופנה לאפליקציה או לאתר של השותף לצורך אימות הזהות שלו. הנה סקירה קצרה של השלבים בתהליך הזה:

  1. Google מפנה את המשתמשים לאתר האינטרנט או לאפליקציית Android של מבצע השילוב, ושם יהיה אפשר לאמת אותו.
  2. כדי לאמת, האימות requestId (מאת AuthenticationRequest) משמש כהוכחת אימות.
  3. כתוצאה מכך מתקבלת תגובה חתומה, שנקראת AuthenticationResponse.
  4. לאחר מכן, האפליקציה או האתר מפנים את המשתמשים בחזרה ל-Google.

אימות ההפניה האוטומטית משתמש בשיטת HTTP לאחזור נתונים, שכוללת פרמטרים שמקודדים בכתובת ה-URL של אפליקציית אינטרנט. היא משתמשת ב-Intent של Android לצורך אימות של אפליקציה ל-Android. לפרטים נוספים על קידוד, ניתן לעיין במאמר אימות באינטרנט, ולפרטים נוספים על פרמטרים של Intent ב-Android, ניתן לעיין במאמר אימות ב-Android.

התוצאה מכל אחד ממנגנוני האימות האלה היא תגובה חתומה שנקראת AuthenticationResponse. כוונה זו צריכה לכלול את תגובת האימות המוצפנת והמקודדת של Google Standard Payments Authentication Response (gspAuthenticationResponse) כדי להעביר אימות מוצלח. אם משתמשים במצב עצמאי, ה-gspResult והחתימה משמשים לקביעת האימות המוצלח.

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

תהליך אימות של כתובת אתר להפניה מחדש

תהליך אימות באינטרנט

לפניכם רשימה של האובייקטים והמאפיינים שהם מייצגים:

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

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

  1. ממשק המשתמש של Google יוצר כתובת URL לאימות שנשלחת לשרת Google (הקצה העורפי). זה מה שמפעיל את תהליך האימות.
  2. שרת Google יוצר בקשת אימות (AuthenticationRequest).
  3. בקשת האימות נשלחה לממשק המשתמש של Google.
  4. המשתמש יקבל את הבקשה לאמת את המזהה שלו אצל מבצע השילוב.
  5. המשתמש מגיב שהוא רוצה לבצע אימות, וההודעה הזו תישלח לאתר של מבצע השילוב.
  6. האתר של משלב התשלומים מבקש אימות של זהות המשתמש.
  7. המשתמש מספק הוכחה לזהות שלו, שנשלחת לאתר של משלב התשלומים.
  8. מבצע השילוב יוצר תגובה (authenticationResponse) להוכחה שניתנה לו (ה-authenticationResponse מקודד בהודעה).
  9. כתובת ה-URL של התגובה נשלחת למשתמש.
  10. כתובת ה-URL של התגובה נשלחת מיד מהמשתמש לממשק המשתמש של Google.
  11. התגובה של שרת Google נשלחת מממשק המשתמש של Google.
  12. השרת של Google מפרש את התגובה כמאומתת.

תרשים הרצף הבא מציג את האינטראקציה בין הטלפון של המשתמש, Google ואפליקציית Android של מבצע השילוב:

הפניה לכתובת URL אחרת – תהליך אימות האפליקציות ל-Android

תהליך אימות אפליקציות ל-Android

אלו האובייקטים והדברים שהם מייצגים:

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

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

  1. ממשק המשתמש של Google יוצר קריאת אימות שנשלחת לשרת Google (קצה העורפי).
  2. שרת Google יוצר בקשת אימות (AuthenticationRequest).
  3. שרת Google שולח APK של שיחה לממשק המשתמש של Google (אפליקציה), ובו בקשה לאימות.
  4. ממשק המשתמש של Google שולח את פרטי המשתמש ל-APK של שילוב התשלומים (AUTHENTICATE_V1(authReq)).
  5. ה-APK של הכלי לשילוב תשלומים שולח את הבקשה (authReq) לשרת של משלב התשלומים.
  6. שרת שילוב התשלומים שולח אתגר חזרה אל ה-APK של כלי שילוב תשלומים.
  7. ה-APK של הכלי לשילוב תשלומים שולח את האתגר חזרה למשתמש.
  8. המשתמש מספק הוכחה לזהות שלו, שנשלחת ל-APK של הכלי לשילוב תשלומים.
  9. ההוכחה הזו נשלחת לשרת של שילוב התשלומים.
  10. השרת יוצר authenticationResponse חתום.
  11. תגובת האימות הושלמה בהצלחה, והודעת authResp נשלחת ל-APK של הכלי לשילוב תשלומים.
  12. הודעת ההצלחה (authResp) נשלחת מה-APK של הכלי לשילוב תשלומים אל ממשק המשתמש של Google.
  13. התגובה של ממשק המשתמש של Google נשלחת לשרת של Google.
  14. השרת של Google מפרש את התגובה המוצלחת.

אימות SMS-MT OTP

שיטת אימות נוספת היא 'שירות הודעות קצר', 'נייד' הופסק, סיסמה חד-פעמית (SMS-MT OTP). המנגנון הזה משתמש במספר הטלפון של המשתמש כדי לשלוח לו סיסמה חד-פעמית לצורך אימות. Google מבקשת מהשותף לשלוח סיסמה חד-פעמית למספר הטלפון של המשתמש, ולאחר שהמשתמש מקבל אותה ולאחר מכן מזין את הסיסמה הזו בממשק של Google, המשתמש יאומת.

זה כולל את השלבים הבאים:

  1. ממשק המשתמש של Google (UI) מבקש מהמשתמש להזין את מספר הטלפון, שכבר רשום אצל מבצע השילוב.
  2. המשתמש מזין מספר טלפון בממשק המשתמש של Google.
  3. Google מפעילה את מבצע השילוב (קורא לשיטה sendOtp) כדי לשלוח סיסמה חד-פעמית (OTP) למשתמש.
  4. המשתמש יקבל את הודעת ה-SMS עם הסיסמה החד-פעמית (OTP).
  5. אחר כך המשתמש יזין בממשק של Google את ה-OTP (שמשמש כקלט ב-capture, ב-associateAccount וב-verifyOtp) שהוא קיבל בממשק של Google. זו הוכחת אימות.

במצב עצמאי, תתבצע קריאה רק לשיטה verifyOtp כדי לאמת את ערך ה-OTP.

תרשים הרצף הבא מציג את האינטראקציה בין הטלפון של המשתמש, Google והמבצע של השילוב בעת שליחת OTP:

תהליך אימות הטלפון (שליחת OTP)

תהליך אימות טלפון (OTP)

לפניכם רשימה של אובייקטים בתרשים והמשמעות שהם מייצגים:

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

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

  1. בממשק המשתמש של Google (טלפון או אתר) מוצגת למשתמש בקשה להזין את מספר הטלפון שלו.
  2. המשתמש מזין את מספר הטלפון שלו בממשק המשתמש של Google.
  3. ממשק המשתמש של Google שולח את המספר (sendChallenge(phoneNum)) לשרת Google.
  4. שרת Google שולח בקשה לשרת של שילוב התשלומים (SendOtp(phoneNum)) לשליחת סיסמה חד-פעמית.
  5. שרת שילוב התשלומים שולח למשתמש סיסמה חד-פעמית (OTP).
  6. שרת שילוב התשלומים מגיב לבקשה של Google בשלב מספר 5, ומסמן שה-OTP נשלח בהצלחה.
  7. המשתמש מזין את הסיסמה החד-פעמית הזו בממשק המשתמש של Google (בטלפון או באתר).
  8. ממשק המשתמש של Google שולח את הסיסמה החד-פעמית לשרת של Google, שבסופו של דבר הוא נשלח לשילוב התשלומים לצורך אימות. הפעולה הזאת מאמתת את זהות המשתמש ומאמתת אותו.

אימות ואימות מחדש

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

  1. אימות ראשוני – משמש לזיהוי ולאימות של המשתמש. האימות הראשוני משמש כקלט ל-method associateAccount.
  2. אימות מחדש – משמש בכל ההקשרים האחרים, כמו עצמאי או קלט ל-capture.

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

בתהליך הזה, קובץ עזר, שנקרא associationId, מסופק לשיוך המקורי (בתהליך השיוך). המידע הזה מסופק באמצעות הקריאה ל-method associateAccount במהלך תהליך השיוך. השדה associationId מזהה את החשבון שאיתו יש להתמודד. מטעמי אבטחה, אין למשתמש אפשרות לשנות את החשבון שעליו מתנהל הערעור.

לצורך אימות מחדש של SMS-MT OTP, Google שומרת את מספר הטלפון שסופק במהלך השיחה המקורית אל sendOtp כמספר קבוע. לא ניתן לשנות זאת שוב מטעמי אבטחה.

לפניכם תהליך לדוגמה שבו Google מחליטה לנסות לבצע אימות מחדש לפני ביצוע רכישה:

תהליך האימות מחדש

תהליך האימות מחדש

לפניך רשימת האובייקטים והדברים שהם מייצגים:

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

תהליך האימות מחדש מתחיל כשלקוח מתחיל לבצע רכישה. הפעולה הזו מפעילה תהליך אימות מחדש של המשתמש.

  1. המשתמש מחליט לרכוש פריט או שירות.
  2. הבקשה נשלחת מממשק המשתמש של Google לשרת של Google.
  3. שרת Google שולח בקשת אימות (authenticationRequest) חזרה לממשק המשתמש של Google.
  4. ממשק המשתמש של Google שולח בקשה לממשק המשתמש של שילוב התשלומים כדי לאמת (associationId, authenticationRequest) את המשתמש.
  5. ממשק המשתמש של הכלי לשילוב תשלומים מחפש את המשתמש כדי לאמת את הזהות שלו (LookupIdentity(associationId)).
  6. ממשק המשתמש של שילוב התשלומים מבקש מהמשתמש את פרטי הכניסה לממשק המשתמש שלו (האתר או האפליקציה של מבצע השילוב).
  7. תגובת האימות נשלחת לשרת של שילוב התשלומים.
  8. תגובת האימות החתומה (authenticationResponse) נשלחת חזרה לממשק המשתמש של משלב התשלומים.
  9. תגובת האימות (authenticationResponse) נשלחת מממשק המשתמש של משלב התשלומים אל ממשק המשתמש של Google.
  10. ממשק המשתמש של Google שולח את התגובה עם פרטי הרכישה לשרת של Google.
  11. השרת של Google שולח הודעת capture (כדי למצוא כסף זמין) לשרת משלב התשלומים (authenticationRequestId, GPT, סכום).
  12. השרת של שילוב תשלומים שולח הודעה על הצלחה חזרה לשרת של Google.
  13. השרת של Google שולח מסר של הצלחה לממשק המשתמש של Google.
  14. ממשק המשתמש של Google מעביר את הפריטים ללקוח (או מודיע לו שהם יימסרו בקרוב).

אימות SMS-MO

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

תהליך אימות SMS-MO

לפניכם רשימה של אובייקטים בתרשים והמשמעות שהם מייצגים:

  • משתמש: המשתמש שרוצה להוסיף אמצעי תשלום לחשבון Google שלו.
  • ממשק המשתמש של Google/מכשיר: במקרה הזה, אפליקציה לטלפון של Google שהלקוח מתחיל להגדיר אמצעי תשלום.
  • שרת Google: שרת הקצה העורפי ב-Google שיוצר את הוראות ה-SMS עם מזהה בקשת אימות (ARID) ומקבל את תוצאת האימות מהמשלב.
  • שרת שילוב תשלומים: שרת הקצה העורפי של מבצע השילוב שמקבל את הודעת ה-SMS לאימות ומחזיר ל-Google את המזהה של בקשת האימות.

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

  1. המשתמש בוחר להוסיף כלי שעבר הצפנה באמצעות אסימון (טוקניזציה).
  2. ממשק המשתמש של Google קורא לשרת של Google ליזום אתגר SMS-MO.
  3. שרת Google מחזיר הוראות SMS, המכילות יעד וגוף שמכיל את המזהה של בקשת האימות.
  4. ממשק המשתמש של Google שולח את ה-SMS לשילוב התשלומים.
  5. השרת של שילוב תשלומים קורא לנקודת הקצה verificationResultNotification בשרת Google עם המזהה של בקשת האימות.
  6. המזהה של בקשת האימות מאומת על ידי שרת Google, והתגובה שלו היא 'הצלחה'.
  7. ממשק המשתמש של Google קורא לשרת של Google כדי לקבל את התוצאה של ניסיון האימות.
  8. התגובה של שרת Google הסתיימה בהצלחה.

סימולציה של אימות SMS-MO

Google מגדירה נקודת קצה (endpoint) של סימולציה של SMS כדי לבצע בדיקות אבחון של תהליך האימות באמצעות SMS-MO. כך לא צריך לשלוח SMS אמיתי ולאמת אותו כשמבצעים שיוכי בדיקה בסביבת ארגז החול.

תהליך הדמייה של אימות SMS-MO

לפניכם רשימה של אובייקטים בתרשים והמשמעות שהם מייצגים:

  • בודק: זה האדם שהתחיל בדיקת אבחון לשיוך SMS-MO.
  • ממשק המשתמש של Google: ממשק משתמש של Google שבו הבודק מתחיל ועוקב אחר הסטטוס של בדיקת האבחון SMS-MO.
  • שרת Google: שרת הקצה העורפי של Google שיוצר את הוראות ה-SMS עם מזהה בקשת אימות (ARID), שולח את הודעת ה-SMS המדומה ומקבל את תוצאת האימות מהמבצע השילוב.
  • שרת שילוב תשלומים: שרת הקצה העורפי של מבצע השילוב שמקבל את הדמיית SMS של אימות ומחזיר ל-Google את המזהה של בקשת האימות.

השלבים בתהליך זה הם:

  1. הבודק מתחיל את בדיקת האבחון של SMS-MO באמצעות הזנה של מזהה מנוי לבדיקה (SID) לצורך הבדיקה. ה-SID הזה ייכלל בקריאה של simulateSms לשילוב התשלומים.
  2. ממשק המשתמש של Google קורא לשרת של Google ליזום אתגר SMS-MO.
  3. שרת Google מחזיר הוראות SMS, המכילות יעד וגוף שמכיל את המזהה של בקשת האימות. לצורך הבדיקה הזו, חיבור HTTPS של ארגז החול (Sandbox) של כלי שילוב התשלומים יבטל את היעד.
  4. ממשק המשתמש של Google מתקשר לשרת Google כדי לשלוח את הודעת ה-SMS המדומה.
  5. הקריאה simulateSms מתבצעת מהשרת של Google לשרת של שילוב התשלומים. גם מזהה בקשת האימות וגם מזהה המנוי (כפי שצוינו בשלב 1) נכללים בקריאה ל-API.
  6. התגובה של השרת לשילוב תשלומים היא ACKNOWLEDGED.
  7. שרת Google מגיב בהצלחה לממשק המשתמש של Google.
  8. השרת של שילוב תשלומים קורא לנקודת הקצה verificationResultNotification בשרת Google עם המזהה של בקשת האימות.
  9. התגובה של שרת Google הסתיימה בהצלחה.
  10. ממשק המשתמש של Google קורא לשרת של Google כדי לקבל את התוצאה של ניסיון האימות.
  11. התגובה של שרת Google היא 'הושלם'.
  12. ממשק המשתמש של Google קורא לשרת של Google לבצע ניסיון שיוך.
  13. הקריאה associateAccount מתבצעת מהשרת של Google לשרת של שילוב התשלומים.
  14. השרת של שילוב התשלומים מגיב בהצלחה.
  15. התגובה של שרת Google הסתיימה בהצלחה.
  16. ממשק המשתמש של Google מתעדכן כדי לציין לבודק שבדיקת האבחון SMS-MO הסתיימה בהצלחה.

שיטות מומלצות ושיקולים נוספים

בחירת פלטפורמות

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