פורטל ההסכמות של Bedrock AgentCore סוגר פינה
במקום לתחזק שרת אימות עצמאי כדי לחבר סוכני פיתוח ל-GitHub ול-Slack, שירות ה-Consent Portal החדש מנהל את הסשנים ישירות מול ה-IdP הארגוני.
- בדקו שספק הזהויות הארגוני שלכם מנפיק טוקני JWT תקינים, ומפו את שלושת ניתובי ה-Callback מראש כדי להימנע מלופ אימות שבור.
כל מי שניסה לחבר סוכן AI פנימי לכלים כמו GitHub או Slack גילה מהר מאוד שהבעיה היא לא המודל, אלא השרת שצריך להרים מסביבו. פתאום משימה של הוספת יכולת לסוכן פיתוח הופכת לפרויקט תשתית של ניהול סשנים, תחזוקת נקודות קצה ציבוריות והחלפת טוקנים.
זה כאב ראש מיותר.
ב-14 בספטמבר 2026, AWS פרסמה פתרון מנוהל בדמות Consent Portal עבור Amazon Bedrock AgentCore. הפורטל מיועד לחסוך את הקמת השרת העצמאי ומעביר את כל ניהול ההרשאות לתשתית מנוהלת ישירות מול ה-IdP הארגוני.
סוף לתחזוקת שרתי אימות ייעודיים
עד להשקה הזו, שימוש בתהליך Three-Legged OAuth (או 3LO) בתוך AgentCore חייב ארכיטקטים להרים שרת אימות עצמאי לחלוטין. השרת הזה נדרש להציג את כתובת האימות, להאזין לקריאת ה-callback החיצונית ברשת הציבורית, לאמת את המשתמש שחוזר מהדפדפן, לנהל את ה-session, ולקרוא לפונקציית CompleteResourceTokenAuth כדי לקשור את הטוקן למשתמש הספציפי. מדובר בהמון קוד תשתיתי שאין לו שום קשר ללוגיקה של הסוכן עצמו. אם משהו נפל בהאזנה החיצונית ב-HTTPS או בניהול העוגיות, כל תהליך ההרשאות של סביבת הפיתוח נעצר מיד.
הפורטל המנוהל של AgentCore Identity מחליף את כל התשתית הזו בנקודת קצה יחידה ומנוהלת. הוא מיועד בדיוק למקרים שבהם מפתחים מתחברים לסוכני AI באמצעות ממשקי Model Context Protocol (או MCP) וסביבות פיתוח כמו Cursor, Kiro, Visual Studio Code או Claude Code. במקום שהמשתמש יקבל שגיאת הרשאה או יוקפץ לאימות באמצע כתיבת הקוד, הוא נכנס פעם אחת לדפדפן, מאשר גישה לכלים הרלוונטיים, והסוכן ב-IDE מקבל גישה ישירה לטוקן ששמור בכספת המאובטחת של AgentCore Identity לשימוש חוזר בכל הפעלה עתידית. הפורטל מנהל בעצמו את ה-redirects של הדפדפן ואת קשירת הסשן, בזמן שכל הפעולות מתועדות לביקורת ב-AWS CloudTrail.
ההפרדה הזו מקלה על הניהול.
סביבות הפיתוח יכולות להריץ כלים שונים במקביל בלי לבקש אימות מחדש בכל כלי. משתמש יכול לאשר הרשאות גישה לקריאת מאגרים ויצירת issues ב-GitHub, ורק מאוחר יותר לחבר בנפרד את הגישה לערוצים ציבוריים ושליחת הודעות ב-Slack, בלי ששני התהליכים יתנגשו זה בזה או ידרשו אימות ארגוני כפול. כל חיבור לספק חיצוני מנוהל באופן עצמאי לחלוטין מול ספק הזהויות של החברה, והטוקנים נשמרים בנפרד עבור כל עובד ועובד.
מה צריך להכין מראש
לפני שניגשים להקים את הפורטל, יש כמה דרישות קדם שחייבים לסגור ברמת התשתית. הבסיס הוא חשבון AWS פעיל עם הרשאות מתאימות, וסביבת עבודה שבה הותקן ה-CLI של AgentCore באמצעות חבילת ה-npm הרשמית, לפי מדריך ההתקנה של AgentCore CLI. דרישות ה-CLI כוללות התקנה של Node.js בגרסה 20 ומעלה, מנהל החבילות npm, וסביבת Python בגרסה 3.10 ומעלה אם אתם כותבים את קוד הסוכן באופן ישיר. מי שבוחר בבנייה מבוססת מכולה יצטרך גם את Docker, בעוד שמסלול CodeZip הרגיל חוסך את התלות הזו.
בנוסף, תצטרכו AgentCore Gateway מוגדר שמשתמש ב-אימות JWT Inbound, מכיוון שהפורטל לא עובד עם אימות IAM ישיר או תצורות offloaded. בתצורת JWT, השער מאמת כל קריאה נכנסת על בסיס הטוקן החתום שנופק למשתמש הקצה, וכך נמנע הצורך לנהל מפתחות IAM ישירים בתוך כלי הפיתוח של העובדים. כלי ה-IDE או לקוח ה-MCP חייב להיות מוגדר מראש להתחברות לאותו שער בדיוק שאליו יוצמד הפורטל, לפי מדריך ההגדרה של AgentCore Gateway. מנהל המערכת שמבצע את ההגדרות זקוק לפוליסת IAM עם הרשאת CreateConsentPortal לבניית הפורטל עצמו, לצד הרשאת iam:PassRole כדי להעביר את תפקיד השירות.
בצד הזהויות, ספק הזהויות הארגוני (IdP) שלכם חייב לספק יישום מסוג OIDC המנפיק טוקן גישה בתצורת JWT חתום שהפורטל יכול לאמת. כאשר עובדים עם Okta, הדוקומנטציה מציינת כי יש להשתמש בשרת אימות מותאם (custom authorization server) עם מדיניות גישה שמאפשרת במפורש את תהליך ה-authorization code grant. כשעובדים עם Auth0, מגדירים ערך audience לפי הצורך (when needed) כדי שהספק יחזיר טוקן גישה חתום מסוג JWT ולא Opaque Token שהפורטל לא יוכל לפענח. כמו כן, נדרש להגדיר לפחות את scope הכניסה הבסיסי של openid, לשמור את כתובת ה-OIDC Discovery URL שכוללת את נקודות הקצה של ה-authorization וה-token ומפתחות החתימה, ולהגדיר כתובת callback זמנית שאותה נעדכן בהמשך.
בצד ספקי הקצה, יש לרשום אפליקציית GitHub OAuth ו-אפליקציית Slack, ולשמור את מפתחות ה-Client Secret שלהן בתוך AWS Secrets Manager. תפקיד ה-IAM של הפורטל חייב לכלול הרשאה מפורשת לקריאת הסודות הללו כדי להשלים את החלפת הטוקנים מול הספקים. בנוסף, יש לוודא שיעדי השער עבור GitHub ו-Slack מוגדרים להשתמש ב-authorization code grant, מבקשים אך ורק את ה-scopes המינימליים הנדרשים לפעולתם, ונמצאים בסטטוס Ready.
מפת הדרכים להקמת הפורטל
תהליך ההקמה בצד המנהל כולל שישה צעדים מסודרים מתוך קונסולת הניהול של AWS או באמצעות כלי ה-CLI של AgentCore. הקמת פורטל ההסכמות מחייבת קישור חד-פעמי ל-Gateway ספציפי ושיוך של ספק זהויות תומך OIDC לפני חלוקת הכתובת למשתמשים.
ששת שלבי ההקמה של פורטל ההסכמות למנהל המערכת
- 01הכינו את חיבורי ה-IdP והשער וצרפו למשתמש הניהול פוליסת IAM הכוללת הרשאות ייעודיות לניהול הפורטל ויעדי השער.
- 02צרו ב-IdP הארגוני יישום OIDC חדש עבור הפורטל, אפשרו תהליך authorization code grant, קבעו scope של openid ושמרו את ה-Discovery URL וכתובת חזרה זמנית.
- 03הקימו ספק זהויות OAuth2 מסוג IdP תחת Outbound Auth בקונסולת Bedrock AgentCore עם מזהה הלקוח, הסוד ונתוני ה-OIDC.
- 04וודאו שדרישות ה-Outbound מוכנות, כולל רישום אפליקציות GitHub ו-Slack, שמירת סודותיהן ב-Secrets Manager ויעדי Gateway במצב Ready.
- 05צרו Consent Portal חדש תחת לשונית הפורטלים, קשרו אותו ל-Gateway הרצוי, הגדירו את ספק ה-IdP, קבעו scopes ואת תפקיד ה-IAM של הפורטל.
- 06עדכנו את כתובות ה-Callback ב-IdP וביעדי השער לפי כתובת הפורטל שהוקצתה, בדקו את הקישור בדפדפן ושלחו אותו למפתחים.
בעת יצירת הפורטל בקונסולה, שמו מוגבל לטווח שבין תו 1 ל-50 תווים ויכול לכלול אותיות באנגלית, ספרות, מקפים ומקפים תחתונים. תיאור הפורטל הוא אופציונלי ומאפשר עד 512 תווים. שמו של ה-Gateway שאליו משייכים את הפורטל יוצג למשתמשי הקצה בדפדפן, ולכן כדאי לתת לו שם ברור שמזהה את סביבת הפיתוח. תחת הגדרות ה-IdP נדרש לשמור על ה-scope של openid, כאשר הוספת scopes נוספים נעשית רק אם ה-IdP או היישום דורשים זאת במפורש. שדה ה-Audience הוא אופציונלי ומומלץ להשאירו על None אלא אם הוגדרו ערכי audience ספציפיים על גבי השער, שכן הערך מאומת מול הגדרות ה-Gateway.
מבחינת הרשאות, הקונסולה מאפשרת לבחור באפשרות Create default role, שמייצרת באופן אוטומטי תפקיד שירות בשם AmazonBedrockAgentCoreConsentPortalDefaultServiceRole בצירוף סיומת ייחודית. אם מעדיפים להשתמש בתפקיד קיים, יש לבחור באפשרות Use another role ולוודא שהפוליסה של המנהל כוללת הרשאת iam:PassRole ייעודית לאותו תפקיד. התפקיד של הפורטל נדרש כדי לגלות את יעדי השער המוגדרים, לבצע session binding ולאחסן את הטוקנים בכספת.
בזמן יצירת הפורטל הסטטוס הראשוני הוא Creating, ובשלב זה מוצגים ה-ARN של הפורטל ותפקיד הריצה אך הכתובת עדיין אינה מוקצית. ברגע שהסטטוס עובר מ-Creating ל-Active, הקונסולה מציגה את כתובת הפורטל הקבועה במבנה הדומיין המנוהל של AWS, ומאפשרת לפתוח אותו ישירות בלחיצה על Launch Consent portal בדפדפן כדי לבדוק את זרימת האימות.
איפה כל Callback נרשם
המכשול הנפוץ ביותר בהטמעת תהליכי 3LO הוא בלבול בין כתובות החזרה השונות. בדוקומנטציה של AgentCore מופיעים שלושה ניתובי callback שונים, ורישום של כתובת שגויה במקום הלא נכון ישבור את רצף האימות מיידית.
הכתובת הראשונה מיועדת ליישום ה-OIDC בספק הזהויות הארגוני, כגון Amazon Cognito, Okta או Auth0. הכתובת בנויה מה-URL המוקצה של הפורטל בתוספת הנתיב callback, ללא לוכסן בסוף. אם ספק הזהויות לא יכיר את הכתובת הזו בדיוק, המשתמש ייחסם כבר במסך הכניסה הראשוני של הפורטל ולא יוכל להתחבר עם הזהות הארגונית שלו.
הכתובת השנייה מוגדרת כברירת המחדל לחזרה (default return URL) בהגדרות של כל 3LO gateway target ב-AgentCore Gateway. כתובת זו בנויה מכתובת הפורטל בתוספת הנתיב connect/callback, ותפקידה להחזיר את הדפדפן לנקודת הקצה המנוהלת שמבצעת את קשירת הסשן (session binding) לאחר מתן ההסכמה לספק הספציפי. ללא הגדרה זו ביעד השער, תהליך האישור של הכלי לא יוכל להסתיים בהצלחה.
הכתובת השלישית היא כתובת ה-Callback הייחודית של AgentCore Identity, שנוצרת באופן אוטומטי בעת הקמת ספק האימות היוצא (outbound credential provider). כתובת זו מוזנת ישירות בהגדרות אפליקציית ה-OAuth החיצונית ב-GitHub או ב-Slack. היא משמשת לקבלת קוד האימות (authorization code) ישירות מהספק החיצוני ולשמירת הטוקן הסופי בכספת של Identity.
| כתובת ניתוב | היכן מוגדרת במערכת | מטרה ותפקיד בארכיטקטורה |
|---|---|---|
| <portal-url>/callback | יישום OIDC בספק הזהויות הארגוני (Cognito, Okta, Auth0) | מחזירה את דפדפן המשתמש לפורטל לאחר אימות זהות ארגונית מוצלח. |
| <portal-url>/connect/callback | הגדרות היעד ב-AgentCore Gateway ככתובת ברירת מחדל | מחזירה את המשתמש לנקודת הקצה המנוהלת לביצוע session binding. |
| AgentCore Identity callbackUrl | הגדרות אפליקציית ה-OAuth החיצונית (GitHub, Slack) | קולטת את קוד האימות מהספק ושומרת את הטוקן הסופי בכספת של Identity. |
המגבלות שצריך להכיר בפרודקשן
הפורטל המנוהל פותר בעיה הנדסית מעצבנת, אבל הוא מגיע עם מגבלות ארכיטקטוניות ברורות שחשוב לשים לב אליהן. ראשית, כל Gateway מוגבל לפורטל הסכמה בודד בלבד, ולא ניתן לשנות את ה-Gateway המשויך לאחר היצירה. אם טעיתם בשיוך או ששם ה-Gateway שמופיע למשתמש אינו ברור, תצטרכו למחוק ולהקים מחדש. בנוסף, יש להקים פורטל רק כאשר השער באמת עושה שימוש ביעדי 3LO הדורשים הסכמת משתמש קצה.
מעבר לכך, הממשק אינו כולל אפשרות למיתוג אישי או שימוש בדומיין מותאם (vanity domain), והכתובת שתשלחו לעובדים תמיד תסתיים במבנה הדומיין של bedrock-agentcore ואזור ה-AWS. ברמת השוק המקומי, השירות טרם הושק באזור ישראל il-central-1, כך שארגונים ישראליים הכפופים למגבלות רגולטוריות של אחסון מידע לא יוכלו להשתמש בו ללא העברת נתוני זהות לאזורים אחרים בעולם, כמו אירופה או ארצות הברית.
AgentCore Identity now offers a Consent portal, a managed web experience and session binding endpoint for AgentCore Gateway.הדוקומנטציה של AWS
שאלה מהותית נוספת שנשארת פתוחה נוגעת לביטול הרשאות. הדוקומנטציה אינה מפרטת מה קורה כשמשתמש מבטל טוקן באופן יזום ישירות בהגדרות של GitHub או שפג תוקפו של הטוקן. נכון לעכשיו, הקריאה הבאה של הסוכן פשוט תיכשל, ותדרוש מהמשתמש לגשת שוב לפורטל באופן עצמאי. גם מודל התמחור הספציפי על ניהול והחלפת טוקנים מחוץ לעלויות ה-Gateway הרגילות טרם פורסם. בינתיים, לפחות נחסך הצורך לתחזק שרת Node.js קטן רק בשביל אימות OAuth.
מה שואלים על זה
- Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCoreaws.amazon.com · המקור
- Get started with Amazon Bedrock AgentCore - Amazon Bedrock AgentCoredocs.aws.amazon.com · דוקומנטציה
- Get started with AgentCore Gateway - Amazon Bedrock AgentCoredocs.aws.amazon.com · דוקומנטציה
- Set up inbound authorization for your gateway - Amazon Bedrock AgentCoredocs.aws.amazon.com · דוקומנטציה
- GitHub OAuth Appdocs.github.com · מקושר מההודעה
- Slack appdocs.slack.dev · מקושר מההודעה
30 עובדות בכתבה נבדקו אחת־אחת מול המקורות המקושרים ומול חיפוש ברשת ב־15 בספטמבר 2026. מה שלא אומת הוסר או מסומן כטענה של החברה. הכתיבה נעשתה בעזרת AI מהמקורות האלה בלבד, בעריכה ובאחריות של סלבה מלנדוביץ׳. טעות? כתבו לנו.
