Авторизація через Microsoft / Azure AD на сайті: налаштування під ключ

Реалізація авторизації через Microsoft / 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 vs multi-tenant?

Azure AD підтримує чотири комбінації акаунтів: single-tenant — лише ваш тенант, multi-tenant — будь-які організації, personal accounts — особисті Microsoft/Outlook, і combination — те й інше. Для корпоративних інтеграцій стандартний вибір — single-tenant або multi-tenant з додатковою валідацією. Для споживчих застосунків — personal + organizational.

Порівняння типів застосунків

Реєстрація застосунку в Azure

1. portal.azure.com → Azure Active Directory → App registrations → New registration
2. Вказати Redirect URI: https://example.com/auth/microsoft/callback
3. Вибрати Supported account types (single/multi-tenant)
4. Після створення: зберегти Application (client) ID та Directory (tenant) ID
5. Certificates & secrets → New client secret → зберегти значення (видно тільки одразу)
6. API permissions → додати: openid, profile, email, User.Read

Microsoft identity platform рекомендує завжди вказувати коректні Redirect URIs — саме на них платформа перенаправляє браузер користувача після аутентифікації. Документація Microsoft з реєстрації застосунку доступна на Microsoft identity platform.

Laravel Socialite

Встановіть пакет через composer: composer require laravel/socialite socialiteproviders/microsoft-azure. Потім налаштуйте сервіс:

// 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'); } } 

Чому при multi-tenant важливо валідувати tenant ID?

При single-tenant Azure сам обмежує коло користувачів, і перевірка tenant ID не обов'язкова. Однак при multi-tenant токен може бути виданий будь-якій організації — і якщо її tenant ID не додано до білого списку, зловмисник з іншої компанії отримає доступ. Валідація tenant ID — критичний крок для безпеки. На практиці ми стикалися з ситуаціями, коли розробники пропускали цю перевірку, і через місяць виявляли в системі користувачів з чужих організацій. Виправлення потім обходилося в 2-3 рази дорожче, ніж своєчасна валідація.

Multi-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 vs OAuth

Великі корпоративні клієнти можуть запитати підтримку SAML 2.0 замість OAuth. Azure AD підтримує обидва протоколи, але SAML потребує окремої бібліотеки та іншої архітектури. За нашими оцінками, впровадження OAuth в 2–3 рази швидше, ніж SAML, і значно простіше в підтримці. Рекомендуємо OAuth як основний протокол.

Що входить у роботу

При замовленні інтеграції Azure AD на сайті під ключ ви отримуєте:

• Документацію з конфігурації Azure (redirect URI, permissions, secrets).
• Реалізацію OAuth callback та зв'язування з обліковими записами користувачів.
• Інтеграцію MS Graph для отримання додаткових даних (аватар, посада, відділ).
• Валідацію tenant ID для multi-tenant сценаріїв.
• Тестування з реальним тенантом — підтверджуємо працездатність.
• Передачу доступів та навчання вашої команди.

Строки робіт

Разом: 4–5 робочих днів. Вартість розраховується індивідуально після аналізу вашого проєкту. Замовте інтеграцію Azure AD — ми реалізуємо її за 4–5 робочих днів. Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення під ваш стек та бізнес-вимоги.