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

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

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

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

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

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

אם הצורך שלכם הוא לעבוד מול הממשק של זום ישירות בצד השרת, ואין צורך לאפשר למשתמשי צד שלישי
לעבוד עם האפליקציה שלכם, אז הדרך הקלה והנוחה היא לעבוד עם,
JWT
ועל זה תיכף אפרט בהמשך.
אם יש צורך לאפשר למשתמשי צד שלישי לעבוד עם האפליקציה שלכם בזום, אז חייבים לעשות שימוש בדרך הזאת כדי לעבוד מול הממשק של זום.
הדרך השניה היא גם סטנדרט מקובל בעולם לאוטנטיקציה ואוטוריזציה וכפי שכתבתי בנ”ל היא הדרך הנוחה לעבוד מול הממשק של זום וקל מאד ליצור טוקן ולרענן אותו מיד עם כל קריאה כפי שעוד מעט תראו.
JWT = Jason Web Token
הוא אובייקט
JSON

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

aaaaa.bbbbb.ccccc
aaaaa = header
bbbbb = payload
ccccc = signature
החלק הראשון מכיל מידע כללי על סוג האלגוריתם שמשמש לחתימה (עוד על החתימה בהמשך), ועל סוג הטוקן, למשל:
{ “alg”: “HS256”,
“typ”: “JWT”
}
סוג הטוקן
typ
הוא
JWT
כפי שרואים לעיל
האלגוריתם שאיתו יוצרים את החתימה
alg
חייב להיות האלגוריתם
HS256
החלק השני מכיל מידע מזהה על המשתמש ומה מותר לו לעשות מול הממשק
וגם את זמן התפוגה של הטוקן, למשל:

{ “iss”: “API_KEY”,
“exp”: 1496091964000
}
iss
זה מזהה המשתמש שעושה שימוש בממשק
exp
זה זמן התפוגה של הטוקן ב
Unix Time
API_KEY
את המפתח הזה לוקחים מהאפליקציה שיוצרים בזום
החלק השלישי הוא החתימה והוא נוצר על ידי הפעלת האלגוריתם שציינתי לעיל בחלק הראשון
HS256
על שני החלקים לעיל כשהם מקודדים ב
base64UrlEncode
האלגוריתם הנ”ל מבצע פעולות של הזזת סיביות ועוד מניפולציות חשבוניות ומופעל של שני החלקים ככה

HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
API_SECRET)
התוצאה של הנ”ל היא הטוקן עצמו שיראה , כמו שכתבתי לעיל, לדוגמא ,ככה:
aaaaa.bbbbb.ccccc
בפועל המחרוזת הסופית של הטוקן היא יותר ארוכה, זה רק לצורך הדוגמא
API_SECRET
את המחזורת הסודית הזאת לוקחים גם כן מהאפליקציה שיוצרים בזום.
החתימה משמשת כדי לוודא שאף אחד לא ביצע שינוי בטוקן לפני שהוא הגיע לממשק של זום, שינוי הכי קטן במחרוזת של הטוקן יאותר מידית על ידי הממשק של זום שידחה את הבקשה לממשק עם שגיאה שהמחרוזת לא וולידית.
למעשה חתימה היא לא הצפנה כי כל אחד שיקבל את הטוקן יכול להסיר את הקידוד

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

API_SECRET
שהסבירות לחלץ אותו מתוך החתימה שייצר האלגוריתם הנ”ל היא לא סבירה לחלוטין למשל יידרשו כמה מאות או אלפי שנים להגיע אליו אם בכלל ולכן החתימה משמשת מנגנון ווידוי שאף אחד לא ביצע שינוי בטוקן אחרי שהוא כבר נוצר וגם מונעת יכולת לייצר אותו שוב אחרי שהוא פג תוקף
צריך לשים לב שחתימה שונה מהצפנה, הצפנה מונעת קיראה של התוכן של שני החלקים הראשונים של הטוקן ומחייבת שימוש באלגורתמים אחרים שקצרה כאן היריעה מלהרחיב על זה כי יש הרבה ספרים על הנושאים האלה
אפשר לקרוא עוד השימוש בטוקן בזום כאן
https://marketplace.zoom.us/docs/guides/auth/jwt
ועכשיו איך אני יצרתי את הטוקן בכמה שורות קוד עם תוקף חדש בכל פעם ?
אז הנה , תראו כמה זה פשוט :
קודם כל עושים שימוש בחבילה הזאת

const jwt = require(‘jsonwebtoken’);
אחרי שמתקינים אותה עם
npm i jsonwebtoken
ועכשיו יוצרים את הטוקן ככה
let options = { header: { alg: ‘HS256’, typ: ‘JWT’ }, noTimestamp: true };
זה החלק הראשון של הטוקן שציינתי לעיל עם עוד אופציה כדי למנוע הוספה של חתימת זמן על ידי החבילה הנ”ל שיוצרת את התוקן
noTimestamp: true
let token = jwt.sign({ iss: ‘API_KEY’, exp: Math.floor(Date.now() / 1000) + (60 * 2) }, ‘API_SECRET’, options);
וזה מכיל את החלק השני של הטוקן ומייצר אותו עם החבילה הנ”ל
שימו לב שמעבירים את ה
API_SECRET
לפונקציה של החבילה שיוצרת את הטוקן, זה מראה איך נוצרת החתימה
רק עם ה
API_SECRET
שיש אותו רק לבעלים של האפליקציה וכמובן גם האפליקציה של זום
יודעת את ה
API_SECRET
וככה היא יכולה לעשות
decode

לטוקן ולוודא שהוא אוטנטי ושאף אחד לא שינה אותו באפילו ביט אחד,
כלומר שהוא הגיע ממי שהוא היה צריך להגיע ולא מאף אחד אחר
שימו לב, (וזאת הפואנטה החשובה שרציתי להראות), איך זמן התפוגה של הטוקן נוצר דינמית בכל פעם שהקוד רץ
Math.floor(Date.now() / 1000) + (60 * 2)
זה מחזיר את ה
Unix Time
שהוא למעשה הזמן הנוכחי במילי שניות שמחלקים אותו באלף כדי לקבל שניות ומוסיפים לו
60
כלומר דקה או שמכפילים כדי לקבל
שתי דקות כמו בדוגמא כאן
ואז מבצעים Math.floor

כדי להוריד נקודה עשרונית מהמספר הסופי
וככה כל פעם שהקוד ירוץ אז הטוקן יהיה בתוקף ולא יהיה צריך שוב ושוב לרענן אותו כמו שחייבים לעשות אם עושים שימוש בשיטה הראשונה שציינתי לעיל
OAuth2
קל פשוט ונוח מאד
לבסוף, כדי לבצע קריאה אל הממשק של זום צריך לשים את הטוקן ב
header
של הקריאה ככה
{ ‘Content-Type’: ‘application/json’, ‘Authorization’: `Bearer ${token}` }
שימו לב ש
${token}
יוחלף עם הערך של הטוקן עצמו בצורה דינמית ולבסוף יתקבל
Bearer aaaaa.bbbbb.ccccc
המילה
Bearer
לפני הטוקן היא סטנדרט מקובל בעולם כשעושים שימוש ב
JWT

הנה דוגמא של קריאה לממשק של זום עם הטוקן
כדי ליצור פגישה שהפרטים שלה נימצאים בתוך ה
bodyCallObj
const baseUrl = ‘https://api.zoom.us/v2’;
const meetingUrl = `${baseUrl}/users/me/meetings`;
const res = await fetch(meetingUrl, {
method: ‘post’,
body: JSON.stringify(bodyCallObj),
headers: { ‘Content-Type’: ‘application/json’, ‘Authorization’: `Bearer ${token}` }
});
const response = await res.json();
עכשיו אתם רואים איך קל ונוח לעבוד עם
JWT
ואיך לא צריך לדאוג לרענון של התוקף של הטוקן מאחר והוא נעשה בכל פעם שתתבצע קריאה לממשק של זום