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": "Иван Петров",
  "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, јер пружа стандардизовану одјаву и управљање сесијама.

Имплементација 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()