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. Това прави протокола де факто стандарт за социално влизане и корпоративно удостоверяване.

Как работи 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": "Иван Петров",
  "email": "ivan@example.com"
}

Access 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, тъй като предоставя стандартизирано излизане и управление на сесиите.

Реализация на OpenID Connect в мобилни приложения

Интегрирането на OpenID Connect в мобилно приложение изисква избор на подходяща библиотека и правилна конфигурация на потока. За Android се използва credential manager (AndroidX Credentials) или библиотеката AppAuth. За iOS — рамката AuthenticationServices с 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()