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 перехвачен, без оригинального 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": "Иван Петров",
  "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 использует OIDC под капотом для 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()