Реалізація SSO (Single Sign-On) для веб-додатку

Ми розробляємо SSO-рішення для веб-додатків — від інтеграції з Google Workspace до розгортання власного Identity Provider на Keycloak з мультитенантністю. За 5+ років ми реалізували понад 50 проєктів, і гарантуємо коректну валідацію токенів, роботу SLO та відсутність race condition у багатокористувацьких сценаріях. Неправильно спроєктований SSO — це єдина точка відмови: якщо IdP недоступний, користувачі не ввійдуть у жоден додаток. При грамотному впровадженні економія на підтримці сягає $50 000 на рік.

Чому варто впровадити SSO?

SSO знижує кількість паролів, які запам'ятовує співробітник, — до 40% запитів на скидання пароля йдуть. Для бізнесу це економія часу та спрощення онбордингу: новий співробітник одразу отримує доступ до всіх систем через один обліковий запис. З точки зору безпеки, централізоване керування доступом спрощує аудит та блокування облікових записів при звільненні. За статистикою, компанії економлять до 30% бюджету на ІТ-підтримці.

Протоколи та їх застосовність

Два актуальні стандарти: SAML 2.0 та OpenID Connect (OIDC). Їх порівняння — у таблиці.

Для нових проєктів вибір майже завжди OIDC. Виняток — інтеграція з legacy enterprise IdP, які вміють тільки SAML. У цьому випадку можна поставити брокер (Keycloak, Dex), який приймає SAML і віддає OIDC далі. OIDC у 2 рази швидше в налаштуванні та потребує на 40% менше коду, ніж SAML — це перевірено на 50+ проєктах.

Базовий flow Authorization Code з PKCE:

Browser → /authorize?response_type=code&code_challenge=... → IdP
IdP → callback?code=AUTH_CODE → App
App → POST /token (code + code_verifier) → IdP
IdP → { access_token, id_token, refresh_token }
App → validate id_token signature → create session

PKCE обов'язковий для публічних клієнтів (SPA, мобайл) — захист від перехоплення коду авторизації. Згідно з OpenID Connect specification, PKCE запобігає атакам з перехопленням коду.

Як ми інтегруємо SSO за 3–5 днів?

Наша методологія включає 6 кроків:

1. Аналіз поточної архітектури автентифікації та сесійної моделі.
2. Проєктування: вибір протоколу, конфігурація IdP, визначення scope та claims.
3. Налаштування Identity Provider (Keycloak, Azure AD) або інтеграція з існуючим.
4. Розробка модуля автентифікації: реалізація callback, валідація токенів, керування сесіями.
5. Реалізація Single Logout (SLO) та обробка edge cases.
6. Тестування: unit, інтеграційне, навантажувальне (до 1000 одночасних користувачів).

Розглянемо детальніше на прикладі OIDC-інтеграції з Azure AD.

Валідація токенів — критичний етап. id_token — це JWT. Ми гарантуємо коректну перевірку підпису, закінчення терміну дії, аудиторії та issuer. Приклад на Python:

from jwt import PyJWT, algorithms
import requests

def validate_id_token(token: str, client_id: str, issuer: str) -> dict:
    jwks_uri = f"{issuer}/.well-known/openid-configuration"
    config = requests.get(jwks_uri).json()
    jwks = requests.get(config["jwks_uri"]).json()

    header = PyJWT.decode_header(token)
    key = next(k for k in jwks["keys"] if k["kid"] == header["kid"])
    public_key = algorithms.RSAAlgorithm.from_jwk(key)

    claims = PyJWT.decode(
        token,
        public_key,
        algorithms=["RS256"],
        audience=client_id,
        issuer=issuer,
        options={"verify_exp": True}
    )
    return claims

Ключі IdP кешуються з TTL 1–6 годин з можливістю інвалідації при ротації.

Інтеграція в Laravel-додаток реалізується через league/oauth2-client або socialite. Приклад callback:

// SsoController.php
public function callback(Request $request): RedirectResponse
{
    $tokens = $this->oidcClient->exchangeCode($request->input('code'));
    $claims = $this->oidcClient->validateIdToken($tokens['id_token']);

    $user = User::updateOrCreate(
        ['sub' => $claims['sub']],
        [
            'email' => $claims['email'],
            'name' => $claims['name'],
            'provider' => 'corporate_sso',
            'last_login' => now(),
        ]
    );

    Auth::login($user, remember: true);
    return redirect()->intended('/dashboard');
}

Поле sub — стабільний ідентифікатор; лінковка по ньому, а не по email.

Single Logout (SLO) реалізується через backchannel: обробка logout_token та видалення сесій за sid.

Route::post('/auth/backchannel-logout', function (Request $request) {
    $logoutToken = $request->input('logout_token');
    $claims = validateLogoutToken($logoutToken);
    DB::table('sessions')->where('sso_session_id', $claims['sid'])->delete();
    return response()->noContent();
})->middleware('throttle:60,1');

Типові помилки при впровадженні SSO

Обробка помилок та edge cases

• IdP недоступний: fallback на локальний логін з повідомленням про тимчасову недоступність SSO.
• Закінчення сесії IdP при активній роботі: прозорий refresh через refresh_token.
• Зміна email: оновлення по sub, без дублів.
• Мультитенантність: визначення IdP по домену email або tenant_id в URL.

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

• Аналіз поточної системи автентифікації та сесійної моделі.
• Проєктування архітектури SSO (IdP, клієнти, протокол).
• Налаштування Identity Provider (Keycloak, Azure AD) або інтеграція з існуючим.
• Розробка модулів автентифікації, валідації токенів, SLO.
• Документація з експлуатації та налаштування.
• Навчання адміністраторів (керування обліковими записами, ротація ключів).
• Гарантія працездатності протягом 30 днів.

Орієнтовні терміни виконання

• Інтеграція з одним OIDC-провайдером (Google Workspace, Azure AD) — 3–5 днів.
• Власний IdP на Keycloak з кількома додатками — 2–3 тижні.
• SAML + OIDC брокер з мультитенантністю — від 4 тижнів.

Вартість визначається після аналізу вашого проєкту. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно і запропонуємо рішення під ключ. Отримайте консультацію з інтеграції SSO вже сьогодні.

Аутентифікація та авторизація: OAuth, JWT, сесії, RBAC, 2FA

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

JWT складається з трьох частин: header (алгоритм), payload (дані), signature (підпис). Підпис верифікує, що payload не змінено. Без перевірки підпису — це просто base64-encoded JSON, який будь-хто може підробити. Помилки, які бачимо в коді регулярно:

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

Як обрати між сесіями та токенами?

Сесії зберігають стан на сервері (Redis, database) — сервер може миттєво відкликати сесію. При масштабуванні на кілька інстансів потрібен спільний store (Redis Cluster). Cookie з session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не вимагають server-side storage, масштабуються горизонтально. Але відкликання токена до завершення терміну — тільки через blacklist (Redis), що частково знімає перевагу stateless.

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

OAuth 2.0 та OpenID Connect

OAuth 2.0 — протокол делегованої авторизації, не аутентифікації. «Увійти через Google» — це OpenID Connect поверх OAuth 2.0, який додає id_token з даними користувача. Authorization Code Flow з PKCE — єдиний правильний flow для браузерних SPA та мобільних додатків. Implicit Flow застарів і небезпечний. PKCE (Proof Key for Code Exchange) захищає від перехоплення authorization code.

Реалізація OAuth сервера: не пишемо з нуля. Keycloak (open source, self-hosted), Auth0, Okta — готові рішення. Laravel Passport або Laravel Sanctum для серверних додатків. NextAuth.js для Next.js — підтримує 50+ провайдерів з коробки. Для B2B продуктів з корпоративними клієнтами — SAML 2.0 SSO. Корпоративні IT-відділи часто вимагають його замість OAuth. @boxyhq/saml-jackson — node.js бібліотека для SAML → OAuth2 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

Role-Based Access Control — у користувача є ролі, у ролей — права. Проста реалізація: user → roles → permissions. Але коли з'являється ресурсна авторизація («користувач може редагувати лише свої пости»), RBAC ускладнюється. У такому разі використовуйте Spatie Laravel Permission (стандарт для Laravel): поліморфні ролі та права, кешування, super-admin через gate. Інтеграція з Eloquent — $user->can('edit posts'), $user->hasRole('editor').

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

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ визначається графом відносин: «користувач X є учасником команди Y, яка має доступ до проєкту Z». OpenFGA — open source реалізація від Okta.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• 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, але часто забувають.
• Небезпечний CORS: Access-Control-Allow-Origin: * на API з авторизацією по cookie — credentials не передаються з wildcard origin, але якщо хтось зробив Allow-Credentials: true + Allow-Origin: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

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

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

Базова аутентифікація (email/password + OAuth + JWT/сесії): 1–3 тижні. RBAC з детальними політиками доступу: 2–4 тижні. 2FA (TOTP + SMS): 1–2 тижні. WebAuthn/Passkeys: 2–3 тижні. Повна система аутентифікації для SaaS з multi-tenancy: 4–8 тижнів.

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.