Part 006 — Authentication and Identity Foundations

Authentication bukan sekadar login. Authentication adalah proses membuktikan bahwa sebuah actor mengontrol authenticator tertentu, lalu menghasilkan identity context yang bisa dipercaya oleh sistem untuk keputusan berikutnya.

Part ini membangun fondasi identity dan authentication untuk sistem Java modern. Kita akan membedakan istilah yang sering tercampur: identity, subject, principal, credential, authenticator, token, session, claim, role, scope, dan permission.

Ini penting karena banyak bug authorization dan audit sebenarnya bermula dari model authentication yang kabur.

1. Posisi Part Ini dalam Framework Kaufman

Dalam Kaufman-style learning, kita tidak langsung menghafal OAuth, OIDC, SAML, JAAS, JWT, passkey, mTLS, atau session cookie. Kita pecah dulu skill authentication menjadi subskill kecil:

Tujuan part ini bukan membuat implementasi login lengkap. Tujuannya membangun mental model agar desain authentication tidak keliru sejak awal.

2. Vocabulary yang Harus Jelas

Kesalahan umum:

"User punya role Admin, berarti user authenticated."

Itu salah framing. Role adalah input authorization. Authentication menjawab “siapa/apa subject ini dan bagaimana kita tahu?”

3. NIST Digital Identity Model: IAL, AAL, FAL

NIST SP 800-63-4 memisahkan digital identity menjadi beberapa assurance function:

Pemisahan ini penting.

Contoh:

Jangan mencampur “saya tahu orang ini siapa secara legal” dengan “request ini sekarang berasal dari session yang masih valid”. Itu dua problem berbeda.

4. Authentication vs Authorization vs Accounting

Gunakan model AAA:

Contoh pada Java API:

Authentication:
- Request membawa session cookie/JWT/mTLS certificate.
- Sistem memverifikasi bukti dan membangun AuthenticatedActor.

Authorization:
- Actor mencoba approve Case C-123.
- Sistem mengecek actor punya capability approve untuk case tersebut.

Accounting/Audit:
- Sistem mencatat actor, action, resource, result, time, policy version, correlation id.

Bug sering terjadi ketika satu layer mengambil alih tugas layer lain.

Contoh anti-pattern:

if (jwt.getClaim("role").equals("ADMIN")) {
    approveCase(caseId);
}

Masalah:

• Authentication token langsung dipakai sebagai authorization final.
• Tidak ada resource-level check.
• Tidak ada policy version.
• Tidak jelas issuer/audience/expiry/token binding.
• Tidak jelas apakah role masih valid saat action dilakukan.

Role dalam token adalah input, bukan keputusan final.

5. Java Identity Vocabulary: Subject dan Principal

Java punya vocabulary security lama melalui JAAS:

• Subject merepresentasikan grouping informasi security untuk satu entity.
• Principal merepresentasikan identity/nama yang berasosiasi dengan subject.
• LoginContext menyediakan cara melakukan authentication dengan LoginModule yang bisa diganti.

Contoh sederhana:

import java.security.Principal;
import java.util.Set;

public record UserPrincipal(String name) implements Principal {
}

public record ServicePrincipal(String name) implements Principal {
}

public record AuthenticatedSubject(
        Set<Principal> principals,
        Set<String> authenticationMethods,
        String issuer,
        String sessionId
) {
    public boolean hasPrincipal(Class<? extends Principal> type) {
        return principals.stream().anyMatch(type::isInstance);
    }
}

Di aplikasi modern, terutama web service, kita jarang membangun sistem langsung di atas JAAS. Namun vocabulary-nya tetap berguna:

Subject = entity yang authenticated.
Principal = identifier/nama subject dalam domain tertentu.
Credential/authenticator = bukti atau mekanisme pembuktian.

Catatan penting: karena Security Manager sudah tidak menjadi boundary modern, jangan menganggap JAAS permission model lama sebagai sandbox aplikasi. Gunakan vocabulary-nya bila berguna, tetapi desain boundary dengan kontrol modern: process isolation, container, OS policy, network policy, explicit authorization, dan audit.

6. Actor Modeling: Human, Service, Device, Job

Sistem Java produksi tidak hanya melayani user manusia.

Actor modeling harus menjawab:

1. Apakah actor human atau machine?
2. Siapa issuer identity-nya?
3. Bagaimana credential diterbitkan?
4. Bagaimana credential diputar/dicabut?
5. Apa blast radius jika credential bocor?
6. Apakah actor boleh membawa user context atau hanya service context?

7. Credential, Authenticator, dan Token Bukan Hal yang Sama

Perbedaan ini fundamental.

Token adalah hasil dari proses authentication/authorization. Token bukan authenticator primer, kecuali dalam konteks session continuation.

8. Authentication Flow: Local vs Federated

8.1 Local Authentication

Risiko:

• password handling,
• credential stuffing,
• weak reset flow,
• session fixation,
• MFA bypass,
• credential store compromise.

8.2 Federated Authentication

Risiko:

• redirect URI mismatch,
• CSRF/state validation failure,
• nonce validation failure,
• issuer confusion,
• token substitution,
• audience confusion,
• over-trusting claims,
• account linking bugs.

IETF RFC 9700 menjadi rujukan security best current practice untuk OAuth 2.0 modern dan memperbarui threat model serta advice dari RFC OAuth sebelumnya.

9. Authentication Output: Jangan Hanya Simpan String Username

Setelah authentication berhasil, aplikasi harus membangun identity context yang eksplisit.

Contoh model:

import java.time.Instant;
import java.util.Set;

public record AuthenticatedActor(
        String subjectId,
        ActorType type,
        String issuer,
        Set<String> authenticationMethods,
        Set<String> assuranceTags,
        Instant authenticatedAt,
        Instant expiresAt,
        String sessionId,
        String tenantId
) {
    public boolean isExpired(Instant now) {
        return !expiresAt.isAfter(now);
    }

    public boolean isHuman() {
        return type == ActorType.HUMAN;
    }
}

public enum ActorType {
    HUMAN,
    SERVICE,
    BATCH_JOB,
    DEVICE,
    CI_RUNNER,
    THIRD_PARTY
}

Mengapa ini lebih baik daripada String username?

• Bisa membedakan human vs service.
• Bisa menyimpan issuer.
• Bisa menyimpan assurance/context.
• Bisa mengecek expiry.
• Bisa dipakai audit.
• Bisa dipakai authorization policy.

Tetapi jangan memasukkan terlalu banyak data sensitif ke context. Identity context harus cukup untuk security decision, bukan menjadi dump semua claim.

10. Claim: Pernyataan, Bukan Kebenaran Absolut

Claim adalah pernyataan dari issuer.

Contoh claim JWT:

{
  "iss": "https://idp.example.com",
  "sub": "user-123",
  "aud": "case-platform-api",
  "exp": 1782614400,
  "iat": 1782610800,
  "amr": ["pwd", "webauthn"],
  "tenant": "regulator-a",
  "scope": "case:read case:approve"
}

Aplikasi Java tidak boleh langsung percaya claim hanya karena token bisa di-decode. Ia harus memvalidasi:

• signature,
• algorithm policy,
• issuer,
• audience,
• expiry,
• not-before bila ada,
• nonce/state untuk flow tertentu,
• key source/JWKS,
• token type,
• tenant binding,
• replay/session policy bila relevan.

JWT decoding bukan verification.

Anti-pattern:

String payload = new String(Base64.getUrlDecoder().decode(parts[1]));
// Parse role from payload and trust it.

Ini hanya membaca klaim, bukan membuktikan klaim.

11. Session Model

Setelah authentication, sistem biasanya memakai session.

Dua model umum:

Session invariant:

A session is valid only if:
1. It was issued by trusted authority.
2. It has not expired.
3. It has not been revoked or superseded when revocation is required.
4. It is bound to expected client/security context when binding is used.
5. It satisfies the assurance required by the attempted action.

Cookie hardening untuk web session:

Set-Cookie: SID=<opaque>; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1800

Untuk action sensitif, session yang masih valid belum tentu cukup. Sistem bisa meminta step-up authentication.

Contoh:

12. MFA, Passkeys, dan Phishing Resistance

Multi-factor authentication bukan sekadar “ada OTP”. Faktor harus berbeda dan harus melawan ancaman yang ditargetkan.

Untuk sistem sensitif, pertanyaan yang lebih tepat bukan “apakah MFA ada?”, tetapi:

Apakah authentication method ini cukup kuat untuk attack path yang ingin kita cegah?

13. Service Identity dan Workload Authentication

Service-to-service call tidak boleh hanya mengandalkan network location.

Anti-pattern:

Jika request datang dari private subnet, berarti trusted.

Private network bukan identity. Private network hanya placement.

Model yang lebih baik:

Service identity harus menjawab:

• service apa yang memanggil,
• dari environment mana,
• credential diterbitkan oleh siapa,
• berapa lama valid,
• audience mana yang boleh menerima,
• scope/capability apa yang diberikan,
• bagaimana revocation/rotation dilakukan.

14. User Delegation vs Service Authority

Salah satu sumber bug besar adalah mencampur user delegation dan service authority.

Contoh:

Case API receives request from User A.
Case API calls Document API.
Should Document API see User A or Case API?

Ada dua model:

Keduanya valid, tetapi kontrolnya berbeda.

Pertanyaan desain:

• Apakah downstream butuh tahu user asli?
• Apakah downstream harus enforce resource-level authorization?
• Apakah user context bisa dipalsukan oleh service pemanggil?
• Apakah audit harus mencatat initiating user dan calling service?
• Apakah token exchange diperlukan?

Audit ideal sering menyimpan keduanya:

{
  "initiatingActor": "user-123",
  "callingService": "case-api",
  "effectiveAction": "document.read",
  "resource": "document-789",
  "correlationId": "..."
}

15. Account Linking: Bahaya Identity Ambiguity

Federated login sering butuh account linking.

Anti-pattern:

Jika email sama, account sama.

Email bisa berubah, tidak selalu verified, bisa reuse, dan bisa berasal dari issuer berbeda.

Model yang lebih aman:

External identity key = issuer + subject
Internal account binding = explicit verified link between external identity and internal account

Contoh Java value object:

public record ExternalIdentity(
        String issuer,
        String subject
) {
    public ExternalIdentity {
        if (issuer == null || issuer.isBlank()) {
            throw new IllegalArgumentException("issuer is required");
        }
        if (subject == null || subject.isBlank()) {
            throw new IllegalArgumentException("subject is required");
        }
    }
}

Jangan jadikan email sebagai primary security key kecuali policy domain benar-benar menjaminnya dan risiko sudah diterima.

16. Authentication Failure Modes

Recovery flow sering menjadi jalur takeover paling mudah. Perlakukan password reset dan MFA reset sebagai authentication system, bukan fitur tambahan.

17. Authentication Invariants

Contoh invariant untuk Java API:

For every protected request:
1. The actor identity must come from a verified authentication mechanism.
2. The issuer must be trusted for this application/environment.
3. The token/session must be intended for this audience.
4. The token/session must be unexpired and not revoked when revocation applies.
5. The actor type must be compatible with the action.
6. The assurance level must satisfy action sensitivity.
7. The resulting identity context must be propagated to authorization and audit without client-side mutation.

Invariant ini bisa diterjemahkan menjadi filter/interceptor.

Contoh skeleton:

public final class AuthenticationContextFactory {

    private final TokenVerifier tokenVerifier;
    private final TrustedIssuerPolicy issuerPolicy;

    public AuthenticationContextFactory(
            TokenVerifier tokenVerifier,
            TrustedIssuerPolicy issuerPolicy
    ) {
        this.tokenVerifier = tokenVerifier;
        this.issuerPolicy = issuerPolicy;
    }

    public AuthenticatedActor authenticate(BearerToken token) {
        VerifiedToken verified = tokenVerifier.verify(token);

        if (!issuerPolicy.isTrusted(verified.issuer())) {
            throw new SecurityException("Untrusted token issuer");
        }

        return new AuthenticatedActor(
                verified.subject(),
                verified.actorType(),
                verified.issuer(),
                verified.authenticationMethods(),
                verified.assuranceTags(),
                verified.issuedAt(),
                verified.expiresAt(),
                verified.sessionId(),
                verified.tenantId()
        );
    }
}

Perhatikan bahwa TokenVerifier.verify() harus melakukan verifikasi kriptografis dan semantic validation. Nama method harus mencerminkan tanggung jawabnya, bukan sekadar parse().

18. Authentication Context Propagation

Dalam sistem terdistribusi, identity context harus dipropagasi dengan hati-hati.

Anti-pattern:

X-User-Id: user-123
X-Role: admin

Jika header ini datang dari client atau service tidak dipercaya, ia bisa dipalsukan.

Pattern yang lebih aman:

• Gateway memverifikasi token eksternal.
• Gateway menerbitkan internal token/header yang hanya valid antar service terpercaya.
• Downstream memverifikasi issuer internal atau mTLS identity.
• Header user context hanya diterima dari trusted boundary.
• Audit mencatat chain of custody.

Pertanyaan penting:

Siapa yang boleh membuat identity context?
Siapa yang boleh meneruskannya?
Siapa yang harus memverifikasinya lagi?

19. Login Endpoint Threat Model

Login endpoint adalah high-value target.

Threats:

Jangan hanya mengamankan /login. Amankan semua jalan menuju authenticated session.

20. Logout, Revocation, dan Session Expiry

Logout sulit pada sistem terdistribusi karena token bisa tersebar.

Rule praktis:

Jika action sensitif membutuhkan revocation cepat, jangan bergantung hanya pada long-lived stateless token.

21. Authentication Logging dan Audit

Authentication event harus cukup untuk investigasi, tetapi tidak boleh bocor secret.

Log yang berguna:

Jangan log:

• password,
• OTP,
• raw token,
• refresh token,
• private key,
• full session cookie,
• sensitive recovery secret.

Untuk token/session id, log hash/fingerprint jika perlu korelasi.

22. Common Pitfalls

23. Practice: 20 Jam Pertama Authentication Design

24. Checklist Ringkas

Sebelum desain authentication dianggap cukup:

• Actor type eksplisit: human, service, batch, device, CI, third-party.
• Issuer identity jelas dan trusted.
• Credential/authenticator lifecycle jelas.
• Token/session expiry jelas.
• Revocation strategy sesuai risiko.
• Audience dan issuer divalidasi ketat.
• JWT/token tidak hanya di-decode, tetapi diverifikasi.
• Identity context memuat subject, issuer, actor type, assurance, expiry, tenant/context.
• Authorization tidak hanya bergantung pada role token.
• Step-up authentication didefinisikan untuk action sensitif.
• Recovery flow punya threat model.
• Authentication event diaudit tanpa membocorkan secret.

25. Ringkasan

Authentication adalah fondasi semua keputusan security berikutnya. Jika identity context kabur, authorization, audit, crypto, dan incident response akan ikut kabur.

Mental model utama:

Authenticator proves control.
Authentication verifies the proof.
Identity context represents the verified subject.
Authorization decides allowed actions.
Audit preserves evidence of what happened.

Untuk sistem Java modern, jangan hanya bertanya “user sudah login atau belum?”. Tanyakan:

Who or what is the actor?
Who asserted that identity?
What proof was verified?
How strong is the assurance?
What is the token/session lifecycle?
Can this context be safely used for this action?

Part berikutnya akan masuk ke authorization policy models: RBAC, ABAC, ReBAC, deny-by-default, confused deputy, segregation of duties, dan policy invariant.

References

• NIST SP 800-63-4, Digital Identity Guidelines — https://pages.nist.gov/800-63-4/
• NIST SP 800-63B-4, Authentication and Authenticator Management — https://csrc.nist.gov/pubs/sp/800/63/b/4/final
• IETF RFC 9700, Best Current Practice for OAuth 2.0 Security — https://datatracker.ietf.org/doc/rfc9700/
• Oracle Java SE 25 API, LoginContext — https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/security/auth/login/LoginContext.html
• Oracle Java SE, JAAS Reference Guide — https://docs.oracle.com/en/java/javase/23/security/java-authentication-and-authorization-service-jaas-reference-guide.html
• OWASP Application Security Verification Standard — https://owasp.org/www-project-application-security-verification-standard/