Матриця прийняття рішень (5 Факторів)
Оберіть параметри вашого проєкту для розрахунку оптимальної архітектури автентифікації:
Каталог Архітектурних Рішень
1. Традиційна Парольна Автентифікація
Базовий метод на основі знання секрету. Досі популярний через простоту впровадження, але вкрай вразливий до фішингу та витоків баз даних. Після успішного логіну зазвичай видають Session cookie або JWT — див. пункти 2–4.
🏦 Банківський домен
Практично виведений з експлуатації як єдиний фактор. Використовується лише в комбінації з 2FA або як резервний метод для відновлення на старих порталах.
🌐 Інший домен
Новинні сайти, невеликі форуми, внутрішні некритичні системи, де втрата акаунта не несе фінансових чи репутаційних ризиків.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant U as Користувач
participant C as Клієнт (Браузер)
participant API as Auth API
participant DB as База Даних
U->>C: Вводить Логін + Пароль
C->>API: POST /login (username, pass)
API->>API: Хешує (Argon2 / bcrypt)
API->>DB: Запит хешу по username
DB-->>API: Повертає (Hash, Salt)
API->>API: Порівнює хеші
alt Збіг
API-->>C: 200 OK (далі Session або JWT)
else Помилка
API-->>C: 401 Unauthorized
end
🏗 Architecture Diagram (Архітектура)
graph LR
User((Користувач)) --> UI[Web / App Client]
UI --> WAF[WAF / Load Balancer]
WAF --> Auth[Auth Service]
Auth --> Cache[(Redis Session Store)]
Auth --> DB[(PostgreSQL Users/Hashes)]
2. Session + Cookie (Server-side)
Після логіну сервер створює сесію і віддає браузеру лише opaque session id у HttpOnly-cookie. Стан живе на бекенді (Redis/DB) — зручний revoke і logout.
🏦 Банківський домен
Legacy web-банкінг: сесія в Redis після MFA; timeout неактивності; примусовий logout усіх пристроїв при зміні пароля.
🌐 Інший домен
Класичний B2B портал (Django/Rails): SESSIONID cookie, server-side store, CSRF-token у формах.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant U as Користувач
participant B as Браузер
participant API as Auth API
participant R as Redis Session Store
U->>B: Успішний логін (пароль/MFA)
B->>API: POST /login
API->>R: Створити session (user_id, roles)
R-->>API: session_id
API-->>B: Set-Cookie: SESSIONID (HttpOnly, Secure)
B->>API: GET /dashboard + Cookie
API->>R: Lookup session_id
R-->>API: User context
API-->>B: 200 OK
🏗 Architecture Diagram (Архітектура)
graph LR
Browser[Браузер + Cookie] --> LB[Load Balancer]
LB --> App[Web App / BFF]
App --> Redis[(Redis Sessions)]
App --> DB[(Users DB)]
3. JWT Bearer (Stateless Token)
Самодостатній підписаний токен з claims (sub, exp, roles). API перевіряє підпис і термін — без lookup сесії на кожен запит. Зручно для SPA, mobile API та microservices.
🏦 Банківський домен
Mobile banking API: короткоживучий access JWT + refresh token; окремі scopes для переказів vs перегляду балансу.
🌐 Інший домен
React SPA + REST: Authorization: Bearer eyJ… після OIDC; gateway валідує JWT перед маршрутизацією.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant C as Клієнт (SPA/App)
participant Auth as Auth Service
participant API as Resource API
C->>Auth: POST /token (login / refresh)
Auth->>Auth: Підпис JWT (private key)
Auth-->>C: access_token + refresh_token
C->>API: GET /data Authorization Bearer
API->>API: Verify signature + exp + scopes
API-->>C: 200 OK + JSON
🏗 Architecture Diagram (Архітектура)
graph LR
Client[SPA / Mobile] --> GW[API Gateway]
GW --> Auth[Auth / Token Issuer]
GW --> Svc1[Service A]
GW --> Svc2[Service B]
Auth --> Keys[(JWKS / Key Store)]
4. API Key (Machine / Integration)
Статичний довгоживучий секрет для machine-to-machine або B2B-інтеграцій. Простий у onboarding, але потребує rotation, scopes і rate limits — не для людського логіну.
🏦 Банківський домен
Open Banking / PSD2: партнерський X-API-Key або mTLS + client_id для доступу до агрегованих рахунків (окремо від user session).
🌐 Інший домен
Stripe / SendGrid: secret key у заголовку для server-side викликів; publishable key лише для публічних операцій.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant P as Partner System
participant GW as API Gateway
participant S as Backend Service
participant K as Key Registry
P->>GW: GET /v1/data X-API-Key sk_live_...
GW->>K: Validate key + scopes + quota
K-->>GW: tenant_id, permissions
GW->>S: Forward + tenant context
S-->>GW: Response
GW-->>P: 200 OK
🏗 Architecture Diagram (Архітектура)
graph LR
Partner[Partner / Cron / Webhook] --> GW[API Gateway]
GW --> KeySvc[Key Validation Service]
KeySvc --> KeyDB[(API Keys DB)]
GW --> Core[Core API]
5. Багатофакторна Автентифікація (MFA)
Додає другий рівень захисту (SMS, TOTP, Push). Значно підвищує безпеку порівняно з паролями, але SMS-канал залишається вразливим до SIM-свопінгу.
🏦 Банківський домен
Monobank / Приват24: Підтвердження транзакцій (Step-up Auth) через Push-сповіщення у додатку, або дзвінок від робота на довірений номер.
🌐 Інший домен
AWS / GitHub: Обов'язкове використання TOTP-додатків (Google Authenticator) для всіх розробників при логіні.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant U as Користувач
participant C as Клієнт (UI)
participant S as Auth API
participant SMS as Провайдер SMS/TOTP
U->>C: Логін + Пароль
C->>S: Перевірка пароля
S->>SMS: Ініціація 2FA (Генерація коду)
SMS-->>U: Доставка коду (телефон)
S-->>C: Вимога 2FA Challenge
C-->>U: Екран вводу коду
U->>C: Вводить код
C->>S: Відправка коду на валідацію
S-->>C: 200 OK + Access Token
🏗 Architecture Diagram (Архітектура)
graph TD
UI[Клієнтський UI] --> API[API Gateway]
API --> AuthS[Auth Service]
AuthS --> DB[(Identity DB)]
AuthS --> 2FAService[2FA Microservice]
2FAService --> Twilio[Twilio / SMS Gateway]
2FAService --> Redis[(Redis OTP Cache)]
6. Біометрична Автентифікація (Локальна)
Авторизація на основі FaceID/TouchID. Біометрія не передається на сервер, а перевіряється в захищеному анклаві пристрою, який підписує токен доступу.
🏦 Банківський домен
Revolut / ПУМБ: Швидкий вхід у мобільний застосунок. Заміняє необхідність вводити PIN-код або пароль при кожному запуску.
🌐 Інший домен
WhatsApp: Додаткове блокування месенджера. Під час відкриття програми ОС запитує відбиток пальця власника пристрою.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant U as Користувач
participant App as Мобільний Додаток
participant Enclave as Secure Enclave (OS)
participant S as Сервер
U->>App: Натискає "Увійти за FaceID"
App->>S: Запит Challenge
S-->>App: Challenge String
App->>Enclave: Запит на біометричний підпис
Enclave-->>U: Сенсор сканує обличчя
Enclave->>Enclave: Перевірка еталону (Локально)
Enclave->>Enclave: Підпис Challenge приватним ключем
Enclave-->>App: Signed Payload
App->>S: Відправка підпису
S->>S: Перевірка публічним ключем
S-->>App: Access Token
🏗 Architecture Diagram (Архітектура)
graph LR
subgraph Device [Мобільний пристрій]
App[Native App]
SE[Secure Enclave / TEE]
Sensors[Камера / Сканер відбитку]
end
App <--> API[API Gateway]
API <--> IdentityS[Identity Server]
IdentityS <--> PKDB[(Public Keys DB)]
Sensors --> SE
SE <--> App
7. SSO / Об'єднана ідентифікація (OAuth 2.0 / OIDC)
Делегування перевірки особи сторонньому довіреному провайдеру (IdP). Зручно для користувачів (менше паролів), але створює єдину точку відмови.
🏦 Банківський домен
BankID (НБУ): Відкриття рахунку у новому банку через верифікацію існуючим акаунтом ПриватБанку або вхід у державні сервіси (Дія).
🌐 Інший домен
Spotify / Figma: Можливість створити акаунт та увійти через Google, Apple або Facebook (Social Login) за 1 клік.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant U as Користувач
participant C as Наш Додаток
participant IdP as Identity Provider (Google)
U->>C: Натискає "Увійти через Google"
C-->>U: Redirect на IdP
U->>IdP: Вводить пароль від Google
IdP->>U: Згода на доступ (Consent)
U->>IdP: OK
IdP-->>C: Redirect назад з Auth Code
C->>IdP: POST (Auth Code + Client Secret)
IdP-->>C: Access Token + ID Token
C->>C: Створює локальну сесію
🏗 Architecture Diagram (Архітектура)
graph TD
User((Користувач)) --> Browser[Браузер]
Browser --> Client[Client App / Frontend]
Client --> BFF[Backend-for-Frontend]
BFF <--> ExternalIdP[Google / Apple IdP]
BFF --> InternalDB[(Users DB)]
8. Passkeys (WebAuthn / FIDO2)
Новий індустріальний стандарт безпарольного входу. Стійкий до фішингу. Ключі (Passkeys) синхронізуються через екосистеми (Apple, Google) або зберігаються на апаратних токенах (YubiKey).
🏦 Банківський домен
PayPal: Вхід у гаманець без пароля. Користувач використовує сканер відбитку на ноутбуці або FaceID на телефоні, і ключ автоматично підписує запит сервісу.
🌐 Інший домен
Google / GitHub: Повна відмова від пароля налаштовується в профілі безпеки. Забезпечує найвищий рівень захисту від крадіжки облікових даних.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant B as Браузер
participant Auth as Authenticator (ОС/Токен)
participant RP as Relying Party (Сервер)
B->>RP: Запит на вхід (username)
RP-->>B: Challenge + RP ID
B->>Auth: navigator.credentials.get()
Auth-->>B: Вимагає Біометрію/PIN у юзера
Auth->>Auth: Підписує Challenge приватним ключем
Auth-->>B: Public Key Credential (Assertion)
B->>RP: Відправка Assertion
RP->>RP: Перевірка підпису (WebAuthn Library)
RP-->>B: 200 OK (Вхід успішний)
🏗 Architecture Diagram (Архітектура)
graph TD
Authn[Platform Authenticator / YubiKey] <--> Browser[WebAuthn API]
Browser <--> WAF[WAF]
WAF <--> FidoSrv[FIDO2 / WebAuthn Server]
FidoSrv <--> Core[Core Identity API]
FidoSrv <--> DB[(DB: Public Keys, User Handle)]
9. Поведінкова біометрія (Risk-Based Auth)
Безперервна невидима перевірка (Continuous Auth). Аналізує, як користувач тримає телефон, друкує або рухає мишкою, формуючи Trust Score. Використовується як доповнення до інших факторів.
🏦 Банківський домен
Barclays: Аналізує патерни навігації в онлайн-банкінгу. Якщо швидкість рухів миші або патерн набору тексту не збігається з профілем, блокує великі перекази.
🌐 Інший домен
Stripe Radar: Аналіз сотень сигналів під час чекауту (час заповнення форми, копіювання даних, геолокація) для блокування ботів та кардерів.
🔄 Sequence Diagram (Процес)
sequenceDiagram
autonumber
participant C as Клієнт (SDK)
participant S as API Сервер
participant ML as Risk/ML Двигун
C->>C: Трекінг (миша, гіроскоп, ритм клавіатури)
C->>S: Відправка телеметрії (Background)
S->>ML: Оцінка ризику (User_ID, Telemetry)
ML->>ML: Порівняння з Baseline моделлю
ML-->>S: Trust Score (напр. 20%)
alt Score < 50% (Аномалія)
S-->>C: Виклик Step-up Auth (MFA)
else Score > 80% (Легітимно)
S-->>C: Продовження сесії непомітно
end
🏗 Architecture Diagram (Архітектура)
graph TD
Client["Web / Mobile + SDK"] --> EventHub["Kafka / Event Hub"]
EventHub --> StreamProcessing["Stream Processor (Flink)"]
StreamProcessing --> ML["Machine Learning Model"]
ML <--> ProfileDB[("User Baseline DB")]
ML --> RiskAPI["Risk Score API"]
RiskAPI --> CoreAuth["Core Auth Service"]
CoreAuth --> Client