אימות Azure AD ארגוני לאתר שלך

אימות Azure AD ארגוני לאתר שלך

אנחנו צוות מהנדסים עם ניסיון של 10+ שנים באימות ארגוני: Azure AD, SAML, OAuth, OpenID Connect. במשך למעלה מ-5 שנים בשוק, השלמנו למעלה מ-40 פרויקטים של שילוב Microsoft 365 ביישומי אינטרנט על Laravel, React, Next.js, Vue וטכנולוגיות נוספות. אנו מבטיחים אימות תקין ומעבר חלק מהתחברות מבוססת סיסמה. נבחן את הפרויקט שלך ונציע פתרון סוהר.

Microsoft OAuth דרך Azure Active Directory הוא התקן עבור יישומי B2B, פורטלים ארגוניים ושירותי SaaS המיועדים לחברות המשתמשות ב-Microsoft 365. עובדים מתחברים עם פרטי התחברות ארגוניים מבלי ליצור סיסמאות נפרדות. Azure AD מטפל במורכבות הפרוטוקול; המפתח צריך רק לחבר את ה-callback למערכת.

כיצד לבחור את סוג היישום: Single-Tenant לעומת Multi-Tenant?

Azure AD תומך בארבעה שילובי חשבונות: single-tenant (רק ה-tenant שלך), multi-tenant (כל ארגון), חשבונות אישיים (Microsoft/Outlook אישי), ושילוב של שניהם. עבור אינטגרציות ארגוניות, הבחירה הסטנדרטית היא single-tenant או multi-tenant עם ולידציה נוספת. עבור יישומי צרכנים, השתמש בחשבונות אישיים + ארגוניים.

השוואת סוגי יישומים

רישום יישום ב-Azure

1. portal.azure.com → Azure Active Directory → App registrations → New registration
2. ציין Redirect URI: openid
3. בחר Supported account types (single/multi-tenant)
4. לאחר היצירה: שמור את Application (client) ID ואת Directory (tenant) ID
5. Certificates & secrets → New client secret → שמור את הערך (נראה רק מיד)
6. API permissions → הוסף: profile, email, User.Read, composer require laravel/socialite socialiteproviders/microsoft-azure

פלטפורמת הזהויות של Microsoft ממליצה תמיד לציין Redirect URIs נכונים—הפלטפורמה מפנה את דפדפן המשתמש ל-URIs אלה לאחר האימות. תיעוד רישום היישומים של Microsoft זמין ב-פלטפורמת הזהויות של Microsoft.

Laravel Socialite

התקן את החבילה דרך composer: // config/services.php 'azure' => [ 'client_id' => env('AZURE_CLIENT_ID'), 'client_secret' => env('AZURE_CLIENT_SECRET'), 'redirect' => env('AZURE_REDIRECT_URI'), 'tenant' => env('AZURE_TENANT_ID', 'common'), // 'common' для multi-tenant ], . לאחר מכן הגדר את השירות:

// config/services.php 'azure' => [ 'client_id' => env('AZURE_CLIENT_ID'), 'client_secret' => env('AZURE_CLIENT_SECRET'), 'redirect' => env('AZURE_REDIRECT_URI'), 'tenant' => env('AZURE_TENANT_ID', 'common'), // 'common' для multi-tenant ], 

בקר אימות

class MicrosoftAuthController extends Controller
{
    public function redirect(): RedirectResponse
    {
        return Socialite::driver('azure')
            ->scopes(['openid', 'profile', 'email', 'User.Read'])
            ->redirect();
    }

    public function callback(): RedirectResponse
    {
        try {
            $msUser = Socialite::driver('azure')->user();
        } catch (\Exception $e) {
            return redirect('/login')->withErrors(['microsoft' => 'Ошибка авторизации Microsoft']);
        }

        $user = User::updateOrCreate(
            ['azure_id' => $msUser->getId()],
            [
                'name' => $msUser->getName(),
                'email' => $msUser->getEmail(),
                'email_verified_at' => now(),
                'azure_tenant_id' => $msUser->user['tid'] ?? null,
            ]
        );

        Auth::login($user, remember: true);

        return redirect()->intended('/dashboard');
    }
}

מדוע ולידציית Tenant ID קריטית בתרחישי Multi-Tenant

עם single-tenant, Azure עצמו מגביל את מאגר המשתמשים, ולכן ולידציית tenant ID אינה נדרשת. עם זאת, עם multi-tenant, ניתן להנפיק token עבור כל ארגון—אם אותו tenant ID אינו ברשימה הלבנה, תוקף מחברה אחרת עלול לקבל גישה. ולידציית tenant ID היא שלב אבטחה קריטי. בפועל, נתקלנו במקרים שבהם מפתחים דילגו על בדיקה זו, ולאחר חודש מצאו משתמשים מארגונים זרים במערכת. תיקון מאוחר יותר עלה פי 2–3 יותר מאשר יישום ולידציה בזמן.

Multi-Tenant: ולידציית Tenant

public function callback(): RedirectResponse
{
    $msUser = Socialite::driver('azure')->user();
    $tenantId = $msUser->user['tid'] ?? null;
    $allowedTenants = explode(',', config('services.azure.allowed_tenants', ''));
    if ($allowedTenants && !in_array($tenantId, $allowedTenants)) {
        return redirect('/login')->withErrors([
            'microsoft' => 'Ваша организация не имеет доступа к этому приложению'
        ]);
    }
    // ...
}

קבלת נתונים נוספים דרך MS Graph

$graphResponse = Http::withToken($msUser->token)
    ->get('https://graph.microsoft.com/v1.0/me', [
        '$select' => 'id,displayName,mail,userPrincipalName,jobTitle,department,officeLocation',
    ]);

$profile = $graphResponse->json();

// $profile['jobTitle'] — должность
// $profile['department'] — подразделение
// $profile['officeLocation']— офис

// Получение аватара
$photoResponse = Http::withToken($msUser->token)
    ->get('https://graph.microsoft.com/v1.0/me/photo/$value');

if ($photoResponse->ok()) {
    Storage::disk('public')->put("avatars/{$user->id}.jpg", $photoResponse->body());
}

SAML לעומת OAuth

לקוחות ארגוניים גדולים עשויים לבקש תמיכה ב-SAML 2.0 במקום OAuth. Azure AD תומך בשני הפרוטוקולים, אך SAML דורש ספרייה נפרדת וארכיטקטורה שונה. לפי ההערכות שלנו, יישום OAuth מהיר פי 2–3 מ-SAML וקל יותר לתחזוקה משמעותית. אנו ממליצים על OAuth כפרוטוקול הראשי.

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

כאשר אתה מזמין אינטגרציית Azure AD סוהרת באתר שלך, אתה מקבל:

• תיעוד על הגדרת Azure (redirect URIs, הרשאות, סודות).
• יישום ה-OAuth callback וקישור עם חשבונות משתמשים.
• אינטגרציה עם MS Graph לקבלת נתונים נוספים (תמונה, תפקיד, מחלקה).
• ולידציית tenant ID לתרחישי multi-tenant.
• בדיקות עם tenant אמיתי—אנו מאשרים תקינות.
• העברת גישה והדרכה לצוות שלך.

לוח זמנים

סה"כ: 4–5 ימי עבודה. המחיר מחושב באופן אישי לאחר ניתוח הפרויקט שלך. הזמן אינטגרציית Azure AD—ניישם אותה תוך 4–5 ימי עבודה. צור קשר להערכת פרויקט—נבחר את הפתרון האופטימלי עבור הטכנולוגיה והדרישות העסקיות שלך.