JWT: ano ito, istraktura ng JSON Web Token at paggamit

Ano ang JWT?

JSON Web Token (JWT) — ay isang bukas na pamantayan (RFC 7519) na tumutukoy ng isang compact at self-contained na paraan ng paglilipat ng impormasyon sa pagitan ng mga partido sa anyo ng isang JSON object. Ang impormasyon sa JWT ay tinatawag na claims — mga pahayag tungkol sa paksa (gumagamit) at karagdagang mga katangian. Bawat claim ay isang pares ng key-value: ID ng gumagamit, tungkulin, oras ng pag-expire, tagapagbigay.

Ang JWT ay tinatawag na self-contained dahil ang lahat ng impormasyong kailangan para sa pag-verify ay nasa loob mismo ng token. Hindi kailangan ng server na ma-access ang database o panlabas na imbakan upang matiyak ang validity ng token — sapat na upang suriin ang lagda. Ang katangiang ito ay ginagawang perpekto ang JWT para sa mga distributed system at microservice architecture, kung saan maraming serbisyo ang kailangang mag-authenticate ng mga kahilingan nang walang shared session storage.

Ayon sa data ng Auth0, 2025, higit sa 65% ng mga mobile at web application ay gumagamit ng JWT bilang pangunahing format ng token para sa API authentication, na nahihigitan ang opaque token at session identifier.

Istraktura ng JWT: header, payload at signature

JWT ay binubuo ng tatlong bahagi na pinaghihiwalay ng mga tuldok: header.payload.signature. Bawat bahagi ay isang Base64url-encoded JSON. Suriin natin ang bawat bahagi nang detalyado.

Header — algorithm at uri ng token

Header ay naglalaman ng dalawang mandatoryong field: alg (algorithm — algorithm ng lagda) at typ (type — uri ng token, palaging “JWT”). Ang algorithm ay maaaring symmetrical (HS256 — HMAC na may SHA-256) o asymmetrical (RS256 — RSA na may SHA-256, ES256 — ECDSA na may P-256). Mas gusto ang mga asymmetrical algorithm dahil pinapayagan nito ang client na suriin ang lagda nang walang pagmamay-ari ng sikretong key.

Halimbawa ng decoded header:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims at data

Payload ay naglalaman ng claims — mga pahayag tungkol sa paksa. Ang claims ay nahahati sa tatlong uri: rehistrado (iss, sub, aud, exp, nbf, iat, jti), pampubliko (tinukoy ng developer sa IANA Registry) at pribado (napagkasunduan sa pagitan ng mga partido). sub (subject) — natatanging identifier ng gumagamit. exp (expiration) — timestamp ng pag-expire ng token. iss (issuer) — tagapagbigay ng token.

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — pagsusuri ng integridad

Signature ay nilikha sa pamamagitan ng paglalapat ng algorithm ng lagda sa pinagsamang header at payload gamit ang isang sikreto o pribadong key. Pormula: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) para sa HMAC, o RSASHA256(...) para sa asymmetrical algorithm. Kinakalkula ng tatanggap ang lagda sa parehong paraan at inihahambing ito sa natanggap — kung magkatugma, hindi nabago ang data.

Paano gumagana ang JWT: paglikha at pag-verify

Ang proseso ng paggana ng JWT ay binubuo ng dalawang yugto: paglikha (pag-isyu) ng token ng authentication server at pag-verify ng token ng client o resource server. Ang authentication server ay tumatanggap ng mga kredensyal ng gumagamit, lumilikha ng payload na may claims at nilalagdaan ito. Ang resultang JWT ay ipinapadala sa client bilang tugon sa kahilingan sa pag-login o sa katawan ng tugon ng OAuth 2.0 / OpenID Connect.

JWT sa mobile authentication

Sa mga mobile application JWT ay ginagamit tulad ng sumusunod: pagkatapos ng matagumpay na pag-login, ang gumagamit ay tumatanggap ng access token sa JWT format. Iniimbak ito ng application sa secure na storage (Keychain sa iOS, EncryptedSharedPreferences sa Android). Sa bawat kahilingan sa API, nagdaragdag ang application ng header na Authorization: Bearer <token>. Sinusuri ng API server ang JWT lagda, kinukuha ang claims at batay dito gumagawa ng desisyon sa pag-access — nang hindi ina-access ang database.

Ayon sa data ng Google Codelabs, 2025, ang paggamit ng JWT sa Firebase Authentication ay binabawasan ang bilang ng mga kahilingan sa authentication server ng 40–60% kumpara sa mga session token, dahil ang data ay nabe-verify nang lokal sa bawat microservice. Ito ay lalong mahalaga sa mga architecture na may mataas na load, kung saan ang bawat millisecond ng pagkaantala ay nakakaapekto sa karanasan ng gumagamit. Sa 50,000 kahilingan bawat minuto, ang paglipat sa JWT ay maaaring makatipid ng hanggang 10 server instance na nagpoproseso ng introspection requests.

JWT vs Session Token

JWT at Session Token ay lumulutas ng parehong gawain — authentication ng mga kahilingan — ngunit pangunahing nagkakaiba sa architecture. Ang Session Token ay isang random na string ng identifier na tumutukoy sa data ng session na nakaimbak sa server (stateful). JWT — self-contained token na naglalaman ng lahat ng data sa loob (stateless).

Mga kalamangan at kahinaan ng JWT

JWT ay nananalo sa mga distributed system: ang mga microservice ay maaaring mag-verify ng token nang lokal nang walang shared storage. Halimbawa, sa isang architecture na may limang microservice, bawat serbisyo ay nagve-verify ng JWT sa loob ng 1–2 ms nang walang network call, habang ang session token ay nangangailangan ng pag-access sa centralized Redis sa bawat kahilingan, nagdadagdag ng 10–30 ms na pagkaantala. Gayunpaman, mahirap i-revoke ang JWT — kung ang token ay naibigay na, ito ay may bisa hanggang sa pag-expire. Ang Session Token ay madaling i-revoke sa pamamagitan ng pagtanggal ng record mula sa DB o Redis.

Para sa mga mobile application, ang pinagsamang approach — JWT na may maikling buhay (15–30 minuto) at Refresh Token — ay nagbibigay ng balanse sa pagitan ng performance at seguridad. JWT ay ginagamit para sa pag-access sa API, at ang refresh token (karaniwang opaque) para sa pagkuha ng mga bagong JWT. Kapag nakompromiso ang JWT, ang attacker ay may access sa loob ng 15–30 minuto; kapag nakompromiso ang refresh token, ang session ay naba-block sa pamamagitan ng rotation at pagtuklas ng muling paggamit.

Seguridad ng JWT

Seguridad ng JWT ay nakadepende sa tamang implementasyon. Ang pinakakaraniwang kahinaan ay ang “alg none” na pag-atake: binabago ng attacker ang header ng token sa “alg”: “none”, at tinatanggap ng server nang hindi sinusuri ang algorithm ang pekeng token. Proteksyon: palaging suriin na ang algorithm sa header ay tumutugma sa inaasahan (RS256, ES256) at tanggihan ang mga token na may alg: none.

Mga karaniwang kahinaan

Mga kahinaan ng JWT ay kasama rin ang: mahinang sikretong key para sa HMAC (na-crack sa loob ng ilang minuto), paglabas ng pribadong key (paglalagda ng anumang data sa ngalan ng server), pag-iimbak ng sensitibong data sa payload (JWT ay hindi nag-e-encrypt, taga-lagda lamang), pag-atake sa pamamagitan ng JWK header injection (pagpasok ng sariling pampublikong key). Ang paggamit ng mga na-verify na library — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — ay nagbabawas ng panganib ng pagsasamantala sa mga kahinaang ito.

Ang karagdagang hakbang sa proteksyon — JWK Thumbprint (RFC 7638): pag-ugnay ng pampublikong key sa token sa pamamagitan ng thumbprint sa header. Kung iniimbak ng server ang inaasahang thumbprint para sa bawat client, ang pag-atake ng JWK header injection ay nagiging imposible — tinatanggihan ng server ang anumang key na hindi tumutugma sa rehistrado. Inirerekomenda ng OAuth Security Workshop 2025 ang JWK Thumbprint bilang mandatoryong proteksyon para sa lahat ng JWT na ginagamit sa mga financial at medical application.

Halimbawa ng code: paggawa gamit ang JWT sa Kotlin

Ang library na jjwt (auth0/java-jwt) ay nagbibigay-daan sa paglikha at pag-verify ng JWT sa Android application sa ilang linya. Sa halimbawa sa ibaba, ang server ay lumilikha ng token na may sub at role, at ang client ay sumusuri ng lagda. Para sa secure na pag-iimbak ng sikretong key sa server, gumamit ng environment variables o HSM (Hardware Security Module) — ang pag-iimbak ng key sa code o configuration file ay isang malubhang pagkakamali sa seguridad.

Pagbuo ng JWT

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// Pagpapadala ng token sa client
println("JWT: $token")

Pag-verify ng JWT

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Ang lagda ay wasto, claims ay nakuha
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}