Enterprise Azure AD Authentication for Your Website

Enterprise Azure AD Authentication for Your Website

We are a team of engineers with 10+ years of experience in corporate authentication: Azure AD, SAML, OAuth, OpenID Connect. Over 5 years in the market, we have completed over 40 projects integrating Microsoft 365 into web applications on Laravel, React, Next.js, Vue, and other stacks. We guarantee correct authentication and seamless migration from password-based login. We will assess your project and offer a turnkey solution.

Microsoft OAuth via Azure Active Directory is the standard for B2B applications, corporate portals, and SaaS services targeting companies using Microsoft 365. Employees log in with corporate credentials without creating separate passwords. Azure AD handles the protocol complexity; the developer only needs to connect the callback with the system.

How to Choose the App Type: Single-Tenant vs. Multi-Tenant?

Azure AD supports four account combinations: single-tenant (only your tenant), multi-tenant (any organization), personal accounts (personal Microsoft/Outlook), and a combination of both. For corporate integrations, the standard choice is single-tenant or multi-tenant with additional validation. For consumer applications, use personal + organizational.

Comparison of App Types

Registering an Application in Azure

1. portal.azure.com → Azure Active Directory → App registrations → New registration
2. Specify Redirect URI: https://example.com/auth/microsoft/callback
3. Select Supported account types (single/multi-tenant)
4. After creation: save Application (client) ID and Directory (tenant) ID
5. Certificates & secrets → New client secret → save the value (only visible immediately)
6. API permissions → add: openid, profile, email, User.Read

Microsoft identity platform recommends always specifying correct Redirect URIs—the platform redirects the user's browser to these URIs after authentication. Microsoft's app registration documentation is available on Microsoft identity platform.

Laravel Socialite

Install the package via composer: composer require laravel/socialite socialiteproviders/microsoft-azure. Then configure the service:

// 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' for multi-tenant
],

Authentication Controller

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 authorization error']);
        }

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

Why Tenant ID Validation Is Critical in Multi-Tenant Scenarios

With single-tenant, Azure itself restricts the user pool, so tenant ID validation is not required. However, with multi-tenant, a token can be issued for any organization—if that tenant ID is not whitelisted, an attacker from another company could gain access. Tenant ID validation is a critical security step. In practice, we have encountered cases where developers skipped this check, and after a month, they found users from foreign organizations in the system. Fixing it later cost 2–3 times more than implementing timely validation.

Multi-Tenant: Tenant Validation

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' => 'Your organization does not have access to this application'
        ]);
    }

    // ...
}

Obtaining Additional Data via 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']      — job title
// $profile['department']    — department
// $profile['officeLocation']— office

// Getting avatar
$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

Large corporate clients may request SAML 2.0 support instead of OAuth. Azure AD supports both protocols, but SAML requires a separate library and a different architecture. According to our estimates, OAuth implementation is 2–3 times faster than SAML and significantly easier to maintain. We recommend OAuth as the primary protocol.

What Is Included in the Work

When you order turnkey Azure AD integration on your website, you receive:

• Documentation on Azure configuration (redirect URIs, permissions, secrets).
• Implementation of the OAuth callback and linking with user accounts.
• Integration with MS Graph to obtain additional data (avatar, job title, department).
• Tenant ID validation for multi-tenant scenarios.
• Testing with a real tenant—we confirm operability.
• Handover of access and training for your team.

Timeline

Total: 4–5 business days. The cost is calculated individually after analyzing your project. Order Azure AD integration—we will implement it in 4–5 business days. Contact us for a project assessment—we will pick the optimal solution for your stack and business requirements.

Why JWT Signature Verification Is Critical?

Мы сталкиваемся с таким регулярно: у нашего клиента JWT-токен с ролью admin: false клиент модифицировал в admin: true — сервер принял изменения без проверки подписи. Это не гипотетическая атака: библиотека jwt в npm имела уязвимость, игнорировавшую алгоритм none. Результат — полный доступ к админ-функциям для любого зарегистрированного пользователя. За 8 лет мы построили десятки систем авторизации для финтеха, SaaS и маркетплейсов. Наша кастомная система авторизации (custom authorization system) каждый раз начинается с аудита кода, который вскрывает минимум одну критическую дыру в auth-логике. Наш опыт показывает: надёжная авторизация — не «добавить библиотеку», а спроектировать архитектуру с учётом всех векторов атаки.

How Our Custom Authorization System Prevents JWT Vulnerabilities

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует целостность payload’а — без её проверки это просто base64-строка, которую может подделать кто угодно. Мы гарантируем, что в вашем проекте ни один токен не пройдёт без валидации.

Common Mistakes We Fix

• Хранение в localStorage — доступно любому JS на странице. XSS-атака крадёт токен. Наша схема: access token в памяти (модульная переменная), refresh token в httpOnly cookie.
• Долгоживущие access token’ы — 7 дней без отзыва. Утекло — 7 дней доступа. Стандарт: 15 минут для access, 30 дней для refresh с ротацией. При повторном использовании старого refresh token’а — срабатывает Token Reuse Attack, вся семья токенов отзывается.
• Секреты в payload — JWT не шифрует данные, только подписывает. Пароли, платёжные данные, личная информация — не в JWT.
• Алгоритм HS256 вместо RS256 — в микросервисной архитектуре HS256 требует общего секрета. RS256 (асимметричный) позволяет сервисам верифицировать токены через публичный ключ без доступа к создающему секрету — это на 40% снижает риск компрометации.

How OAuth 2.0 and OpenID Connect Work in Practice

OAuth 2.0 — протокол делегированной авторизации, а не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, добавляющий id_token с данными пользователя. Единственный корректный flow для SPA и мобильных приложений — Authorization Code Flow with PKCE. Implicit Flow deprecated и небезопасен. PKCE защищает от перехвата кода авторизации.

При реализации OAuth-сервера не пишите с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Для Laravel — Passport или Sanctum. Для Next.js — NextAuth.js с поддержкой 50+ провайдеров. Для B2B-продуктов с корпоративными клиентами — SAML 2.0 SSO. @boxyhq/saml-jackson — Node.js библиотека для адаптера SAML → OAuth2.

Sessions vs JWT: When to Choose What

Для большинства веб-приложений сессии проще и безопаснее. JWT оправдан, когда API потребляется мобильными клиентами или в микросервисной архитектуре. Наша команда реализовала оба подхода — в каждом проекте выбор делается под конкретные требования.

RBAC, ABAC, ReBAC: Which Access Model Fits Your System?

Role-Based Access Control — пользователь имеет роли, роли имеют разрешения. Простая реализация: user → roles → permissions. Но как только появляется resource-based авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и разрешения, кеширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов пользователя, ресурса, окружения. Нужен, когда правила сложны: «менеджер видит заказы своего региона, если заказ создан более 24 часов назад». Casbin — кроссплатформенная библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — модель Google Zanzibar. Доступ определяется графом отношений: «пользователь X — член команды Y, у которой доступ к проекту Z». OpenFGA — open source реализация от Okta. Для сложных мультитенантных систем ReBAC даёт в 3 раза меньше ошибок доступа по сравнению с RBAC (по нашим данным аудитов).

Two-Factor Authentication: TOTP, SMS, WebAuthn

TOTP (Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при настройке содержит base32-секрет — если скомпрометирован, код воспроизводим. Храним секрет зашифрованным.

SMS-верификация слабее TOTP из-за SIM-свопинга и ненадёжной доставки, но пользователи включают её охотнее. Email-OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Приватный ключ на устройстве, публичный на сервере. Нет пароля — нет утечки. Поддерживается всеми современными браузерами. @simplewebauthn/server + @simplewebauthn/browser — хорошая Node.js библиотека.

Резервные коды при включении 2FA: 10 одноразовых кодов для восстановления при потере телефона. Храним хешированными (bcrypt), показываем только при генерации.

Common Vulnerabilities We Eliminate

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки принадлежности пользователю. Самая частая API-уязвимость по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Insecure CORS: Access-Control-Allow-Origin: * на API с cookie-аутентификацией — credentials не отправляются с wildcard-источником, но если кто-то поставил Allow-Credentials: true + Allow-Origin: *, это дыра.

Process: From Requirements to Secure Production

1. Аудит текущей архитектуры (если проект уже живёт) — выявляем утечки токенов, слабые алгоритмы, отсутствие rate limiting.
2. Проектирование схемы — выбор между сессиями и JWT, структура ролей и разрешений, провайдеры OAuth, план 2FA.
3. Реализация — пишем код с покрытием тестов (unit + integration + security).
4. Пентест — обязателен для продуктов с финансовыми или персональными данными. Проводим автоматическое и ручное тестирование.
5. Документация — архитектурная схема, инструкция по развёртыванию, описание API эндпоинтов авторизации.
6. Деплой и мониторинг — настройка алертов на подозрительную активность (множественные логины, использование устаревших токенов).
7. Пост-релизная поддержка — 30 дней исправлений и консультаций.

What’s Included in the Deliverable

• Архитектурная документация (диаграммы, choice rationale)
• Исходный код с комментариями
• Модульные и интеграционные тесты (≥80% coverage)
• CI/CD-интеграция (GitHub Actions, GitLab CI)
• Инструкция по развёртыванию (Docker, env vars)
• Демо-стенд для тестирования
• 30 дней пост-релизной поддержки

Timeline and Project Estimate

Стоимость рассчитывается индивидуально. Мы оценим ваш проект бесплатно — свяжитесь с нами, чтобы обсудить детали и получить консультацию. Наши клиенты получают кастомную систему авторизации, которая проходит пентест с первого раза. Закажите аудит текущей auth-логики или разработку с нуля — напишите нам.