Уявіть: користувач авторизується через соціальну мережу, додаток отримує access token, але не може дізнатися, хто саме увійшов — лише якийсь абстрактний ресурс. Або гірше: ID-токен парситься без перевірки підпису, і зловмисник може підмінити особу. Ми щодня бачимо такі кейси на проєктах, де авторизацію впроваджували нашвидкоруч. OpenID Connect (OIDC) вирішує проблему, додаючи до OAuth 2.0 стандартизований ID-токен з верифікацією. У цій статті — практичний досвід інтеграції OIDC у мобільні додатки з правильною безпекою.
Чому OpenID Connect, а не чистий OAuth 2.0?
OAuth 2.0 — протокол авторизації. access token не гарантує наявність даних користувача в читабельному форматі. OIDC додає аутентифікацію: ID token — JWT з фіксованим набором claims (sub, iss, aud, exp, iat). Це єдиний спосіб надійно отримати особу користувача на мобільному пристрої.
Різниця на практиці: при чистому OAuth 2.0 доводиться додатково запитувати userinfo endpoint, який може вимагати окремого scope або повернути неповні дані. OIDC дає ID token вже на етапі authorization code flow — швидше та стандартизованіше.
Як правильно верифікувати ID-токен на мобільному пристрої?
Головна помилка — довіряти ID token без верифікації підпису. Бачили проєкти, де мобільний додаток парсить payload JWT base64-декодуванням і читає sub claim — без перевірки підпису, iss, aud. Це еквівалентно довірі будь-якому JWT від кого завгодно.
Правильний flow:
- Отримуємо ID token від Authorization Server.
- Завантажуємо JWKS за jwks_uri з discovery document (
.well-known/openid-configuration). - Верифікуємо підпис ID token за публічним ключем з JWKS.
- Перевіряємо iss == очікуваний issuer, aud містить наш client_id, exp не закінчився, nonce збігається (захист від replay-атак).
На практиці все це робить AppAuth у зв'язці з JWTDecode (iOS) або nimbus-jose-jwt (Android). AppAuth кращий за саморобну реалізацію: у 10 разів швидша інтеграція та виключає типові вразливості. Не економте на безпеці — одне невірне рішення може коштувати часу та репутації.
Nonce
Nonce генеруємо криптографічно до початку authorization request, зберігаємо в пам'яті, передаємо в параметрах запиту. Після отримання ID token — перевіряємо, що nonce в token збігається. Якщо сервер повернув token без nonce або з іншим — відхиляємо аутентифікацію. Це захищає від CSRF та replay-атак на мобільному рівні.
Discovery Document та автоконфігурація
OIDC провайдери публікують метадані за .well-known/openid-configuration. AppAuth вміє завантажувати їх автоматично — немає потреби хардкодити endpoints:
// iOS — автодискавері OIDAuthorizationService.discoverConfiguration(forIssuer: issuerURL) { config, error in guard let config else { return } // config містить authorizationEndpoint, tokenEndpoint, jwksURL тощо } // Android AuthorizationServiceConfiguration.fetchFromIssuer(issuerUri) { config, error -> // використовуємо config для побудови AuthorizationRequest } Кешуємо discovery document на годину-дві, не скачуємо при кожній операції — це знижує навантаження та прискорює повторні запити.
UserInfo endpoint
Після отримання access token можна запросити userinfo_endpoint для додаткових claims (email, name, picture). Claims в ID token навмисно мінімальні — OIDC Core не гарантує їх без scope (profile, email, phone).
Важливо: userinfo endpoint захищений access token. Якщо access token закінчився — оновлюємо його через refresh token до запиту. Робимо це прозоро через interceptor/middleware у HTTP-клієнті. Знижуємо час очікування на 40% за рахунок кешування userinfo на годину.
Logout: часто забувають
OIDC визначає три варіанти завершення сесії:
- RP-Initiated Logout (ви, як додаток): редиректимо на end_session_endpoint.
- Front-Channel Logout: сервер пінгує клієнти через iframe (не підходить для нативних додатків).
- Back-Channel Logout: сервер надсилає POST на backchannel_logout_uri.
Для мобільних додатків працює лише RP-Initiated. Відкриваємо end_session_endpoint у браузері (ASWebAuthenticationSession / Custom Tabs), передаємо id_token_hint та post_logout_redirect_uri. Без id_token_hint деякі провайдери (Keycloak, Auth0) не завершать сесію на сервері — користувач вийде з додатку, але SSO-сесія в браузері залишиться активною.
Що входить у роботу
При замовленні інтеграції OIDC під ключ ви отримуєте:
- Налаштування OIDC провайдера (Keycloak, Azure AD, Okta) з коректною конфігурацією redirect URI, scopes, claims.
- Інтеграцію бібліотеки AppAuth або аналога з повною верифікацією JWKS та nonce.
- Реалізацію UserInfo запиту з кешуванням та refresh token rotation.
- Налаштування RP-Initiated Logout.
- Тестування всіх flow (login, token refresh, logout) на реальних пристроях.
- Документацію з інтеграції та підтримку 2 тижні після здачі.
Ми спеціалізуємося на мобільній безпеці понад 5 років, виконали 50+ проєктів з авторизацією. Оцінимо ваш проєкт за 2 дні безкоштовно — зв'яжіться для консультації.
| Параметр | OAuth 2.0 | OpenID Connect |
|---|---|---| | Аутентифікація | Ні, тільки авторизація | Так, через ID token | | Формат токена | Access token (довільний) | ID token (JWT з claims) | | Верифікація | За access token (якщо opaque) | За JWKS | | UserInfo | Опціонально | Стандартний endpoint |
Строки
Один OIDC провайдер зі стандартною конфігурацією — 5–8 робочих днів (включно з тестами та налаштуванням redirect). Корпоративний IdP з нестандартними claims та B2C user flows — 10–15 днів з урахуванням coordination з командою IdP. Вартість розраховується індивідуально, пишіть для точної оцінки.