OpenID Connect: що це таке, протокол автентифікації та авторизації

Що таке OpenID Connect?

OpenID Connect (OIDC) — це відкритий протокол автентифікації, побудований як надбудова над OAuth 2.0. Він стандартизує те, чого не вистачало OAuth 2.0: верифікацію особи користувача. Якщо OAuth 2.0 відповідає на питання “який застосунок має доступ?”, то OIDC відповідає на питання “хто саме цей користувач?”.

Протокол використовує ID Token — JSON Web Token (JWT), який містить набір claims: унікальний ідентифікатор суб’єкта, email, ім’я, аватар, часові мітки випуску та закінчення. Клієнтський застосунок може перевірити ID Token криптографічно — сервер підписує токен за допомогою RS256 або ES256, і клієнт звіряє підпис із публічним ключем, отриманим через JWKS endpoint.

За даними Auth0, 2025, понад 78% мобільних застосунків, які використовують сторонню автентифікацію, застосовують OIDC через Google Sign-In або Sign in with Apple. Це робить протокол стандартом де-факто для social login та корпоративної автентифікації.

Як працює OpenID Connect

OpenID Connect визначає декілька потоків (flows) залежно від типу клієнта. Для мобільних застосунків стандартом є Authorisation Code Flow з Proof Key for Code Exchange (PKCE) — він забезпечує захист навіть за відсутності client secret на пристрої.

Identity Provider та його роль

Identity Provider (IdP) — це сервер, який виконує автентифікацію користувача та випускає токени. В екосистемі OIDC IdP надає два ключових endpoint: Authorisation Endpoint для входу користувача та Token Endpoint для обміну коду на токени. Клієнт дізнається адреси цих endpoint через Discovery URL — стандартний шлях /.well-known/openid-configuration, який повертає JSON-документ з усією конфігурацією провайдера.

Кожен IdP публікує свій JWKS (JSON Web Key Set) — набір публічних ключів для перевірки підпису ID Token. Клієнт кешує ці ключі та використовує їх для верифікації кожного отриманого токена без звернення до сервера.

Authorisation Code Flow з PKCE

Authorisation Code Flow — це трикроковий процес. Спочатку мобільний застосунок генерує code verifier (випадковий рядок довжиною 43–128 символів) та його hash — code challenge. Застосунок відкриває браузер або WebView з URL, що містить client_id, redirect_uri, scope (openid profile email) та code challenge. Користувач вводить облікові дані на сторінці IdP та підтверджує згоду. IdP перенаправляє браузер назад у застосунок з authorisation code.

На другому кроці застосунок надсилає authorisation code, code verifier та client_id на Token Endpoint сервера. Сервер перевіряє code verifier проти збереженого code challenge і повертає ID Token, Access Token та опціонально Refresh Token. На третьому кроці застосунок перевіряє ID Token: валідує підпис за JWKS, звіряє issuer (iss), audience (aud) та час закінчення (exp). Якщо перевірка пройдена — користувач вважається автентифікованим.

PKCE (Proof Key for Code Exchange) усуває вразливість, властиву стандартному Authorisation Code Flow у публічних клієнтах. Оскільки мобільний застосунок не може зберегти client secret у безпеці, зловмисник, який перехопив authorisation code, міг би обміняти його на токени. Code verifier вирішує цю проблему: навіть якщо код перехоплено, без оригінального code verifier обмін неможливий. OAuth Security Best Practices (RFC 9700) вимагають PKCE для всіх публічних клієнтів, включаючи мобільні застосунки.

ID Token та Access Token

OpenID Connect повертає два принципово різних токени: ID Token та Access Token. ID Token — це завжди JWT, який клієнт може прочитати та перевірити самостійно. Він містить інформацію про користувача та використовується для автентифікації, а не для доступу до API.

Структура ID Token

ID Token складається з header, payload та signature, закодованих у Base64 та розділених крапками. Header містить alg (алгоритм підпису) та kid (ідентифікатор ключа). Payload включає обов’язкові claims: iss (issuer — видавець токена), sub (subject — унікальний ID користувача), aud (audience — ідентифікатор клієнта), exp (expiration), iat (issued at). Опціонально — name, email, picture, locale.

Приклад декодованого payload ID Token від Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token — це opaque token (довільний рядок) або JWT, який клієнт передає в API-запити. На відміну від ID Token, access token не призначений для читання клієнтом — його формат і вміст відомі лише серверу ресурсів та серверу авторизації. Access Token має scope — обмеження прав доступу — та короткий термін життя, зазвичай 15–60 хвилин.

Відмінності OpenID Connect від OAuth 2.0

OAuth 2.0 — це фреймворк авторизації, який визначає, як застосунок отримує доступ до ресурсів користувача. OpenID Connect — це надбудова, яка додає до цього процесу автентифікацію. Ключова відмінність: OAuth 2.0 не визначає формат токена і не дає застосунку способу дізнатися, хто саме зробив запит.

Коли вибирати OpenID Connect

OpenID Connect необхідний, коли застосунку потрібно впізнати користувача, а не просто отримати доступ до його даних. Якщо ви використовуєте “Увійти через Google” або “Sign in with Apple” — це OIDC. Якщо ваш застосунок викликає сторонній API від імені користувача без необхідності знати його особу — достатньо чистого OAuth 2.0. Для корпоративних систем з Single Sign-On (SSO) вибір однозначний: тільки OpenID Connect, оскільки він надає стандартизований logout та session management.

Реалізація OpenID Connect у мобільних застосунках

Впровадження OpenID Connect у мобільний застосунок потребує вибору відповідної бібліотеки та правильного налаштування потоку. Для Android використовується credential manager (AndroidX Credentials) або бібліотека AppAuth. Для iOS — AuthenticationServices framework з ASWebAuthenticationSession.

Приклад коду на Kotlin (Android)

Нижче наведено приклад запуску Authorisation Code Flow за допомогою бібліотеки AppAuth-Android. Застосунок створює запит авторизації, відкриває браузер для входу користувача та обробляє callback з токенами.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Приклад коду на Swift (iOS)

ASWebAuthenticationSession від Apple надає вбудований браузер для OIDC-потоку з підтримкою SSO через iCloud Keychain. Сесія запускається з URL авторизації, а callback обробляється через completion handler.

При виборі бібліотеки для OpenID Connect враховуйте підтримку PKCE з коробки: AppAuth-Android і AppAuth-iOS підтримують PKCE за замовчуванням. Firebase Authentication використовує OIDD під капотом для Google Sign-In, Sign in with Apple та Microsoft — розробнику не потрібно реалізовувати потік вручну. Для корпоративних систем з власним IdP (наприклад, Keycloak або Okta) AppAuth залишається стандартним вибором з повним контролем над конфігурацією та обробкою помилок.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()