OpenID Connect: ano ito, protokol ng pagpapatotoo at awtorisasyon

Ano ang OpenID Connect?

OpenID Connect (OIDC) — ay isang bukas na protokol ng pagpapatotoo na binuo bilang isang layer sa ibabaw ng OAuth 2.0. Istandardisa nito ang kulang sa OAuth 2.0: pag-verify ng pagkakakilanlan ng gumagamit. Kung ang OAuth 2.0 ay sumasagot sa tanong na “aling app ang may access?”, ang OIDC naman ay sumasagot sa tanong na “sino ba talaga ang gumagamit na ito?”.

Ang protokol ay gumagamit ng ID Token — JSON Web Token (JWT), na naglalaman ng isang set ng claims: natatanging identifier ng paksa, email, pangalan, avatar, mga timestamp ng pagpapalabas at pag-expire. Ang client app ay maaaring mag-verify ng ID Token nang cryptographically — nilagdaan ng server ang token gamit ang RS256 o ES256, at sinusuri ng client ang lagda gamit ang pampublikong susi na nakuha sa pamamagitan ng JWKS endpoint.

Ayon sa datos ng Auth0, 2025, mahigit 78% ng mobile apps na gumagamit ng third-party authentication ay nag-aapply ng OIDC sa pamamagitan ng Google Sign-In o Sign in with Apple. Ginagawa nitong de facto standard ang protokol para sa social login at corporate authentication.

Paano gumagana ang OpenID Connect

OpenID Connect ay nagdedefine ng maraming daloy (flows) depende sa uri ng client. Para sa mobile apps, ang pamantayan ay Authorisation Code Flow na may Proof Key for Code Exchange (PKCE) — nagbibigay ng proteksyon kahit walang client secret sa device.

Identity Provider at ang papel nito

Identity Provider (IdP) — ay ang server na nagsasagawa ng pagpapatotoo ng gumagamit at naglalabas ng mga token. Sa ecosystem ng OIDC, ang IdP ay nagbibigay ng dalawang pangunahing endpoint: Authorisation Endpoint para sa pag-login ng gumagamit at Token Endpoint para sa pagpapalit ng code sa mga token. Natutuklasan ng client ang mga address ng mga endpoint na ito sa pamamagitan ng Discovery URL — ang karaniwang landas /.well-known/openid-configuration, na nagbabalik ng JSON dokumento na may buong configuration ng provider.

Bawat IdP ay naglalathala ng sarili nitong JWKS (JSON Web Key Set) — set ng mga pampublikong susi para sa pag-verify ng lagda ng ID Token. Ini-cache ng client ang mga susi na ito at ginagamit para sa pag-verify ng bawat natanggap na token nang hindi kumokonsulta sa server.

Authorisation Code Flow na may PKCE

Authorisation Code Flow — ay isang prosesong may tatlong hakbang. Una, ang mobile app ay gumagawa ng code verifier (random na string na may habang 43–128 character) at ang hash nito — code challenge. Binuksan ng app ang browser o WebView na may URL na naglalaman ng client_id, redirect_uri, scope (openid profile email) at code challenge. Ipinapasok ng gumagamit ang kanyang mga kredensyal sa pahina ng IdP at kinukumpirma ang pahintulot. Ini-redirect ng IdP ang browser pabalik sa app na may authorisation code.

Sa ikalawang hakbang, ipinapadala ng app ang authorisation code, code verifier at client_id sa Token Endpoint ng server. Sinusuri ng server ang code verifier laban sa naka-store na code challenge at ibinabalik ang ID Token, Access Token at opsiyonal na Refresh Token. Sa ikatlong hakbang, vini-verify ng app ang ID Token: vina-validate ang lagda sa pamamagitan ng JWKS, sinusuri ang issuer (iss), audience (aud) at oras ng pag-expire (exp). Kung matagumpay ang pag-verify — ang gumagamit ay itinuturing na napatotohanan.

Inaalis ng PKCE (Proof Key for Code Exchange) ang kahinaan na likas sa karaniwang Authorisation Code Flow sa mga pampublikong client. Dahil hindi ligtas na maiimbak ng mobile app ang client secret, ang isang attacker na nakaharang sa authorisation code ay maaaring ipagpalit ito sa mga token. Niresolba ng Code verifier ang problemang ito: kahit na ang code ay maharang, kung wala ang orihinal na code verifier, imposible ang pagpapalit. Ang OAuth Security Best Practices (RFC 9700) ay nangangailangan ng PKCE para sa lahat ng pampublikong client, kabilang ang mobile apps.

ID Token at Access Token

Ang OpenID Connect ay nagbabalik ng dalawang pangunahing magkaibang token: ID Token at Access Token. ID Token — ay palaging JWT na maaaring basahin at i-verify nang nakapag-iisa ng client. Naglalaman ito ng impormasyon tungkol sa gumagamit at ginagamit para sa pagpapatotoo, hindi para sa pag-access sa API.

Istraktura ng ID Token

ID Token ay binubuo ng header, payload at signature, na naka-encode sa Base64 at pinaghihiwalay ng mga tuldok. Ang header ay naglalaman ng alg (algoritmo ng lagda) at kid (identifier ng susi). Ang payload ay may kasamang mandatory claims: iss (issuer — naglabas ng token), sub (subject — natatanging ID ng gumagamit), aud (audience — identifier ng client), exp (expiration), iat (issued at). Opsiyonal — name, email, picture, locale.

Halimbawa ng na-decode na payload ng ID Token mula sa 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 — ay isang opaque token (arbitraryong string) o JWT na ipinapadala ng client sa mga kahilingan sa API. Hindi tulad ng ID Token, ang access token ay hindi inilaan para basahin ng client — ang format at nilalaman nito ay alam lamang ng resource server at ng authorization server. Ang Access Token ay may scope — paghihigpit ng mga karapatan sa pag-access — at maikling buhay, karaniwang 15–60 minuto.

Mga Pagkakaiba ng OpenID Connect at OAuth 2.0

OAuth 2.0 — ay isang balangkas ng awtorisasyon na nagdedefine kung paano nakakakuha ng access ang app sa mga mapagkukunan ng gumagamit. OpenID Connect — ay isang layer na nagdaragdag ng pagpapatotoo sa prosesong ito. Pangunahing pagkakaiba: Ang OAuth 2.0 ay hindi nagdedefine ng format ng token at hindi nagbibigay sa app ng paraan upang malaman kung sino talaga ang gumawa ng kahilingan.

Kailan pumili ng OpenID Connect

Ang OpenID Connect ay kinakailangan kapag kailangan ng app na makilala ang gumagamit, hindi lamang makakuha ng access sa kanyang datos. Kung gumagamit ka ng “Mag-login gamit ang Google” o “Sign in with Apple” — ito ay OIDC. Kung ang iyong app ay tumatawag sa third-party API sa ngalan ng gumagamit nang hindi kailangang malaman ang kanyang pagkakakilanlan — sapat na ang purong OAuth 2.0. Para sa mga corporate system na may Single Sign-On (SSO) ang pagpili ay malinaw: OpenID Connect lamang, dahil nagbibigay ito ng standardized logout at pamamahala ng sesyon.

Pagpapatupad ng OpenID Connect sa mobile apps

Ang pagsasama ng OpenID Connect sa isang mobile app ay nangangailangan ng pagpili ng angkop na library at tamang configuration ng daloy. Para sa Android ginagamit ang credential manager (AndroidX Credentials) o AppAuth library. Para sa iOS — AuthenticationServices framework na may ASWebAuthenticationSession.

Halimbawa ng code sa Kotlin (Android)

Sa ibaba ay isang halimbawa ng pagpapatakbo ng Authorisation Code Flow gamit ang AppAuth-Android library. Gumagawa ang app ng kahilingan sa awtorisasyon, binuksan ang browser para sa pag-login ng gumagamit at pinoproseso ang callback na may mga token.

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)
        }
    }
}

Halimbawa ng code sa Swift (iOS)

Ang ASWebAuthenticationSession mula sa Apple ay nagbibigay ng built-in na browser para sa OIDC flow na may suporta sa SSO sa pamamagitan ng iCloud Keychain. Ang sesyon ay sinisimulan sa URL ng awtorisasyon, at ang callback ay pinoproseso sa pamamagitan ng completion handler.

Sa pagpili ng library para sa OpenID Connect, isaalang-alang ang suporta sa PKCE na built-in: ang AppAuth-Android at AppAuth-iOS ay sumusuporta sa PKCE bilang default. Ang Firebase Authentication ay gumagamit ng OIDC sa ilalim ng hood para sa Google Sign-In, Sign in with Apple at Microsoft — hindi kailangan ng developer na manu-manong ipatupad ang daloy. Para sa corporate system na may sariling IdP (halimbawa, Keycloak o Okta), ang AppAuth ay nananatiling karaniwang pagpili na may ganap na kontrol sa configuration at paghawak ng error.

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()