OAuth 2.0 і конфігурація

Authorization server видає/validates tokens і може масштабуватися окремо. Client — application, яка просить access; resource owner дає consent; resource server приймає access token і захищає API.

Відео розрізняє user authorization і service-to-service access. Токен має представляти конкретного subject/client і не давати більше privileges, ніж потрібно.

Access token короткоживучий; refresh token дає можливість отримати новий без повторної interactive authorization. Lifetime є server configuration, а не універсальні «дві години».

На developer portal демонструється registration application/client, вибір scopes і redirect/callback URL. Client secret не можна вбудовувати в public mobile/browser client; там потрібен Authorization Code + PKCE.

User flow емулює дії людини і consent, service flow представляє machine client. Якщо test завжди бере admin/service token, він не перевіряє real user authorization boundaries.

Потрібні positive/negative checks для scopes, audience, client type і resource access. Token exchange чи внутрішні service tokens не слід вигадувати за Network tab — їх contract має дати backend/security team.

Authorization request містить client ID, redirect URI, response type, scopes і state/PKCE parameters. Authorization server звіряє redirect з registered value, показує consent і повертає short-lived code.

У current implementation redirect URI порівнюється exact, public client використовує PKCE S256, а transaction захищається від CSRF/mix-up. Самого client ID/redirect недостатньо для safe flow.

Відео досліджує login flow у DevTools: initial cookies, form fields, origin/referer, anti-CSRF values, 302 redirects і callback. Це корисно для debugging та розуміння state machine.

Але browser login scraping крихкий: UI form, cookies, CAPTCHA і hidden fields можуть змінитися без API notice. Для production test client треба використати supported OAuth/OIDC library і documented endpoints, а не копіювати browser internals.

Демо послідовно відтворює open login page, authenticate user, follow location/callback, extract authorization code і exchange it for tokens. Cookies оновлюються між кроками, тому shared state має бути explicit.

Велика частина демо — live debugging невірного client/redirect та reverse engineering кроків. Практичний висновок: автоматизувати лише documented grant, а browser trace використовувати для пошуку discrepancy.

На іншому прикладі показані session cookie, target URL, user credentials, authorization code і token exchange. Далі access token передається в controller requests або обмінюється на service token згідно з архітектурою.

Тести мають перевіряти expired/wrong audience/insufficient scope, а не лише valid token. Окрема test application для auth load зменшує ризик засмітити production client/user data.

Environment-specific base URLs, client IDs, users і non-secret defaults можуть жити в typed configuration/enum. Client secret, password і tokens не комітяться: вони передаються з CI secret store/environment.

Відео показує enum/singleton-like initialization. Важливіший invariant: immutable configuration можна безпечно читати parallel tests, а mutable token/session state не можна безумовно розділяти між users/threads.

Token можна отримати в suite/JUnit lifecycle і передати в base controller. Це прибирає repeated login з кожного test і зберігає transport setup в одному місці.

Один global token доречний лише для одного immutable identity без parallel mutation. Для tests різних users/scopes потрібен session/token per test context або safe cache з expiry/refresh — інакше паралельні tests впливатимуть один на одного.