Autentikasi dan Otorisasi Modern - Dari LDAP ke OAuth 2.0 SSO

#Pengantar

Autentikasi dan otorisasi adalah penjaga gerbang sistem modern. Setiap kali Anda masuk ke aplikasi, identitas Anda diverifikasi (autentikasi) dan izin Anda diperiksa (otorisasi). Namun, cara ini terjadi telah berubah secara fundamental selama dua dekade terakhir.

Selama bertahun-tahun, perusahaan mengandalkan LDAP dan Active Directory—layanan direktori terpusat yang bekerja baik dalam jaringan korporat. Hari ini, organisasi beroperasi di seluruh platform cloud, perangkat mobile, dan tim terdistribusi. Model lama tidak berfungsi. Sistem modern membutuhkan sesuatu yang berbeda: Single Sign-On (SSO) yang didukung oleh OAuth 2.0 dan OpenID Connect.

Pergeseran ini bukan hanya teknis—ini adalah arsitektur. Memahami evolusi ini membantu Anda membuat keputusan yang lebih baik tentang infrastruktur identitas, postur keamanan, dan pengalaman pengguna.

#Daftar Isi

#Evolusi Autentikasi: Sejarah Singkat

#Era LDAP (1990-an-2000-an)

LDAP (Lightweight Directory Access Protocol) revolusioner untuk zamannya. Ini menyediakan cara terpusat untuk menyimpan dan menanyakan kredensial pengguna dan informasi organisasi.

Cara kerja LDAP:

• Pengguna disimpan dalam pohon direktori hierarki
• Aplikasi menanyakan LDAP secara langsung untuk kredensial pengguna
• Kata sandi diverifikasi terhadap direktori
• Sederhana, tetapi tightly coupled dengan jaringan

Masalahnya: LDAP mengasumsikan pengguna berada di jaringan korporat. Akses VPN canggih. Mobile? Lupakan saja. Kolaborasi lintas organisasi memerlukan pengaturan federasi yang kompleks.

#Dominasi Active Directory (2000-an-2010-an)

Active Directory (AD) Microsoft memperluas LDAP dengan autentikasi Kerberos, kebijakan grup, dan integrasi Windows yang mendalam. Ini menjadi standar de facto untuk identitas enterprise.

Mengapa AD kuat:

• Kerberos menyediakan autentikasi berbasis tiket (lebih lanjut nanti)
• Kebijakan grup memungkinkan manajemen terpusat
• Integrasi domain Windows yang mulus
• Bekerja baik dalam batas jaringan korporat

Keterbatasannya: AD dirancang untuk jaringan on-premises. Adopsi cloud mengungkap kelemahannya. Mengelola identitas di AWS, Azure, dan aplikasi SaaS menjadi mimpi buruk.

#Pergeseran Cloud-Native (2010-an-Sekarang)

Ketika organisasi pindah ke platform cloud dan mengadopsi aplikasi SaaS, model baru muncul: autentikasi stateless berbasis token. OAuth 2.0 dan OpenID Connect menjadi standar.

Mengapa pergeseran terjadi:

• Pengguna bekerja dari mana saja, bukan hanya jaringan korporat
• Aplikasi didistribusikan di seluruh penyedia cloud
• Adopsi SaaS meledak (Salesforce, Slack, Jira, dll.)
• Pengembangan mobile-first memerlukan autentikasi stateless
• Microservices membutuhkan solusi identitas yang ringan dan scalable

#Memahami OAuth 2.0 dan SSO

#Apa itu OAuth 2.0?

OAuth 2.0 adalah kerangka kerja otorisasi, bukan protokol autentikasi. Perbedaan ini penting.

Otorisasi = "Apa yang boleh Anda lakukan?" Autentikasi = "Siapa Anda?"

OAuth 2.0 menjawab pertanyaan otorisasi. Ini memungkinkan pengguna memberikan izin aplikasi untuk mengakses sumber daya mereka tanpa berbagi kata sandi.

#Alur OAuth 2.0: Analogi Dunia Nyata

Bayangkan Anda di restoran dan ingin membayar dengan kartu kredit:

1. Anda menyerahkan kartu Anda kepada pelayan (bukan PIN Anda)
2. Pelayan membawanya ke pemroses pembayaran
3. Pemroses memverifikasi kartu dan menagihnya
4. Pelayan kembali dengan tanda terima (bukti transaksi)
5. Anda tidak pernah berbagi PIN Anda dengan pelayan

OAuth 2.0 bekerja serupa:

1. Pengguna mengklik "Login dengan SSO" di aplikasi
2. Aplikasi mengarahkan pengguna ke penyedia identitas (IdP)
3. IdP memverifikasi kredensial pengguna
4. IdP mengeluarkan kode otorisasi
5. Aplikasi menukar kode dengan token akses
6. Aplikasi menggunakan token untuk mengakses sumber daya pengguna

#Empat Pemain Kunci dalam OAuth 2.0

┌─────────────┐
│   Pemilik   │
│   Sumber    │
│   Daya      │
│  (Pengguna) │
└──────┬──────┘
       │
       │ 1. Memulai login
       ▼
┌─────────────────┐         ┌──────────────────┐
│  Aplikasi       │◄───────►│  Server           │
│  Klien          │ 2,3,4   │  Otorisasi (IdP) │
└─────────────────┘         └──────────────────┘
       │                            │
       │ 5. Token Akses             │
       │◄───────────────────────────┘
       │
       ▼
┌──────────────────┐
│  Server Sumber   │
│  Daya (API)      │
└──────────────────┘

Pemilik Sumber Daya: Pengguna yang datanya diakses Aplikasi Klien: Aplikasi Anda yang meminta akses Server Otorisasi: Penyedia identitas (IdP) yang memverifikasi identitas Server Sumber Daya: API atau layanan yang menyimpan data pengguna

#Konsep IAM: Blok Bangunan

#Realm

Realm adalah pengelompokan logis pengguna, aplikasi, dan kebijakan. Pikirkan ini sebagai namespace untuk identitas.

Contoh: Perusahaan mungkin memiliki:

• Realm produksi (untuk aplikasi menghadap pelanggan)
• Realm staging (untuk pengujian)
• Realm internal (untuk aplikasi karyawan)

Setiap realm memiliki:

• Direktori pengguna
• Aplikasi
• Kebijakan
• Kunci penandatanganan token

Contoh Konfigurasi Realm

Copy

realm:
  name: production
  enabled: true
  users:
    - id: user123
      username: alice@company.com
      email: alice@company.com
  applications:
    - clientId: web-app
      redirectUris:
        - https://app.company.com/callback
    - clientId: mobile-app
      redirectUris:
        - com.company.app://callback
  policies:
    - name: require-mfa
      enabled: true

#Klaim

Klaim adalah pernyataan tentang pengguna. Mereka adalah pasangan kunci-nilai yang disertakan dalam token yang menggambarkan siapa pengguna dan apa yang boleh mereka lakukan.

Klaim standar:

• sub (subject): Pengenal pengguna unik
• iss (issuer): Siapa yang mengeluarkan token
• aud (audience): Siapa token itu untuk
• exp (expiration): Kapan token kedaluwarsa
• iat (issued at): Kapan token dibuat

Klaim khusus:

• department: "Engineering"
• role: "Senior Engineer"
• team: "Platform"
• permissions: ["read:logs", "write:config"]

{
  "sub": "user123",
  "iss": "https://idp.company.com",
  "aud": "web-app",
  "exp": 1708108800,
  "iat": 1708022400,
  "email": "alice@company.com",
  "department": "Engineering",
  "role": "Senior Engineer",
  "permissions": ["read:logs", "write:config", "deploy:staging"]
}

#Token: Mata Uang Autentikasi Modern

Token adalah inti dari OAuth 2.0. Mereka adalah kredensial yang ditandatangani secara kriptografis yang membuktikan identitas dan otorisasi.

Token Akses: Token jangka pendek yang digunakan untuk mengakses API

• Biasanya kedaluwarsa dalam 15 menit hingga 1 jam
• Disertakan dalam setiap permintaan API
• Jika dikompromikan, jendela kerusakan terbatas

Token Refresh: Token jangka panjang yang digunakan untuk mendapatkan token akses baru

• Biasanya kedaluwarsa dalam hari atau minggu
• Disimpan dengan aman (cookie httpOnly atau penyimpanan aman)
• Tidak pernah dikirim ke API, hanya ke server otorisasi

Token ID: Berisi informasi identitas pengguna (OpenID Connect)

• Mencakup klaim tentang pengguna
• Digunakan untuk autentikasi, bukan otorisasi
• Tidak boleh digunakan untuk mengakses API

// 1. Pengguna masuk, menerima kode otorisasi
const authCode = "auth_code_xyz";
 
// 2. Tukar kode dengan token
const tokenResponse = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret_xyz",
    redirect_uri: "https://app.company.com/callback"
  })
});
 
// 3. Respons berisi token
const { access_token, refresh_token, id_token, expires_in } = 
  await tokenResponse.json();
 
// 4. Gunakan token akses untuk panggilan API
const apiResponse = await fetch("https://api.company.com/user", {
  headers: {
    Authorization: `Bearer ${access_token}`
  }
});

#Kerberos: Alternatif Berbasis Tiket

Kerberos sering disebutkan bersama OAuth 2.0, tetapi secara fundamental berbeda. Memahami perbedaannya membantu Anda memilih alat yang tepat.

#Cara Kerja Kerberos

Kerberos menggunakan sistem berbasis tiket bukan token:

1. Pengguna mengautentikasi ke server Kerberos dengan kata sandi mereka
2. Server Kerberos mengeluarkan Ticket Granting Ticket (TGT)
3. Pengguna menggunakan TGT untuk meminta tiket layanan untuk aplikasi tertentu
4. Pengguna menyajikan tiket layanan untuk mengakses aplikasi
5. Aplikasi memverifikasi tiket dengan server Kerberos

Kata Sandi Pengguna
     │
     ▼
┌──────────────────┐
│ Server Kerberos  │
│ (KDC)            │
└──────────────────┘
     │
     │ Ticket Granting Ticket (TGT)
     ▼
Cache Pengguna
     │
     ├─► Minta Tiket Layanan untuk App A
     │        │
     │        ▼
     │   ┌──────────────────┐
     │   │ Server Kerberos  │
     │   └──────────────────┘
     │        │
     │        │ Tiket Layanan
     │        ▼
     └─► App A (Verifikasi dengan KDC)

#Kerberos vs OAuth 2.0

#Kompatibilitas LDAP dengan SSO Modern

Salah satu kekhawatiran terbesar selama migrasi: "Bagaimana dengan infrastruktur LDAP kami yang ada?"

Kabar baiknya: Sistem SSO modern mempertahankan kompatibilitas LDAP melalui jembatan dan konektor.

#LDAP sebagai Penyimpan Pengguna

Banyak sistem SSO dapat menggunakan LDAP sebagai direktori pengguna backend:

sso:
  name: company-sso
  userStore:
    type: ldap
    connection:
      url: ldap://ldap.company.com:389
      baseDn: dc=company,dc=com
      bindDn: cn=admin,dc=company,dc=com
    userMapping:
      username: uid
      email: mail
      displayName: cn
      groups: memberOf

Cara kerjanya:

1. Pengguna masuk ke portal SSO
2. SSO menanyakan direktori LDAP untuk kredensial pengguna
3. SSO memverifikasi kata sandi terhadap LDAP
4. SSO mengeluarkan token OAuth
5. Aplikasi menggunakan token OAuth (bukan LDAP secara langsung)

#Proxy LDAP untuk Aplikasi Legacy

Untuk aplikasi yang hanya memahami LDAP, sistem SSO dapat bertindak sebagai proxy LDAP:

Aplikasi Legacy
    │
    │ Kueri LDAP
    ▼
┌──────────────────┐
│ Sistem SSO       │
│ (Proxy LDAP)     │
└──────────────────┘
    │
    │ Kueri LDAP
    ▼
┌──────────────────┐
│ Direktori LDAP   │
└──────────────────┘

Ini memungkinkan aplikasi legacy terus bekerja sambil Anda bermigrasi ke OAuth 2.0 untuk layanan baru.

#OpenID Connect: Autentikasi di Atas OAuth 2.0

OAuth 2.0 menangani otorisasi, tetapi bagaimana dengan autentikasi? Di situlah OpenID Connect (OIDC) masuk.

OIDC adalah lapisan tipis di atas OAuth 2.0 yang menambahkan autentikasi. Ini memperkenalkan token ID, yang berisi klaim tentang identitas pengguna.

#OAuth 2.0 vs OpenID Connect

// OAuth 2.0: Dapatkan token akses untuk memanggil API
const response = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret"
  })
});
 
const { access_token } = await response.json();
// Gunakan access_token untuk memanggil API

// OIDC: Dapatkan token akses DAN id_token
const response = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret",
    scope: "openid profile email" // Scope OIDC
  })
});
 
const { access_token, id_token } = await response.json();
// id_token berisi informasi identitas pengguna
// access_token digunakan untuk memanggil API

#Implementasi Praktis: Membangun Integrasi SSO

#Langkah 1: Daftarkan Aplikasi Anda

Pertama, daftarkan aplikasi Anda dengan penyedia SSO:

application:
  name: my-web-app
  clientId: my-web-app-prod
  clientSecret: ${OAUTH_CLIENT_SECRET}
  redirectUris:
    - https://app.company.com/auth/callback
    - https://app.company.com/auth/callback/mobile
  allowedScopes:
    - openid
    - profile
    - email
    - offline_access
  tokenEndpointAuthMethod: client_secret_basic
  accessTokenLifespan: 3600
  refreshTokenLifespan: 604800

#Langkah 2: Implementasikan Alur Login

import { generateRandomString, generateCodeChallenge } from './crypto';
 
export function initiateLogin() {
  // Hasilkan parameter PKCE untuk keamanan
  const codeVerifier = generateRandomString(128);
  const codeChallenge = generateCodeChallenge(codeVerifier);
  const state = generateRandomString(32);
  
  // Simpan untuk verifikasi nanti
  sessionStorage.setItem('oauth_state', state);
  sessionStorage.setItem('oauth_code_verifier', codeVerifier);
  
  // Bangun URL otorisasi
  const params = new URLSearchParams({
    client_id: 'my-web-app-prod',
    redirect_uri: 'https://app.company.com/auth/callback',
    response_type: 'code',
    scope: 'openid profile email offline_access',
    state: state,
    code_challenge: codeChallenge,
    code_challenge_method: 'S256'
  });
  
  // Arahkan ke penyedia SSO
  window.location.href = `https://idp.company.com/authorize?${params}`;
}

#Langkah 3: Tangani Callback

export async function handleCallback(code: string, state: string) {
  // Verifikasi parameter state
  const storedState = sessionStorage.getItem('oauth_state');
  if (state !== storedState) {
    throw new Error('State mismatch - kemungkinan serangan CSRF');
  }
  
  const codeVerifier = sessionStorage.getItem('oauth_code_verifier');
  
  // Tukar kode dengan token
  const response = await fetch('https://idp.company.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code: code,
      client_id: 'my-web-app-prod',
      client_secret: process.env.OAUTH_CLIENT_SECRET,
      redirect_uri: 'https://app.company.com/auth/callback',
      code_verifier: codeVerifier
    })
  });
  
  const { access_token, refresh_token, id_token } = await response.json();
  
  // Simpan token dengan aman
  sessionStorage.setItem('access_token', access_token);
  // Simpan token refresh di cookie httpOnly (server-side)
  await fetch('/api/auth/store-refresh-token', {
    method: 'POST',
    body: JSON.stringify({ refresh_token })
  });
  
  // Dekode dan verifikasi token ID
  const user = decodeIdToken(id_token);
  return user;
}

#Langkah 4: Gunakan Token Akses untuk Panggilan API

export async function fetchUserData() {
  const accessToken = sessionStorage.getItem('access_token');
  
  const response = await fetch('https://api.company.com/user', {
    headers: {
      Authorization: `Bearer ${accessToken}`
    }
  });
  
  if (response.status === 401) {
    // Token kedaluwarsa, segarkan
    await refreshAccessToken();
    return fetchUserData(); // Coba lagi
  }
  
  return response.json();
}
 
async function refreshAccessToken() {
  const response = await fetch('/api/auth/refresh', {
    method: 'POST'
  });
  
  const { access_token } = await response.json();
  sessionStorage.setItem('access_token', access_token);
}

#Kesalahan Umum dan Jebakan

#Kesalahan 1: Menyimpan Token Akses di localStorage

Masalahnya:

// Rentan terhadap serangan XSS
localStorage.setItem('access_token', token);

Mengapa berbahaya: JavaScript apa pun di halaman (termasuk skrip berbahaya dari kerentanan XSS) dapat membaca localStorage.

Solusinya:

// Simpan di cookie httpOnly (hanya server-side)
// Server menetapkan: Set-Cookie: access_token=...; HttpOnly; Secure; SameSite=Strict

#Kesalahan 2: Tidak Memvalidasi Token ID

Masalahnya:

// Mempercayai token tanpa verifikasi
const user = JSON.parse(atob(idToken.split('.')[1]));

Mengapa berbahaya: Siapa pun dapat membuat JWT palsu. Anda harus memverifikasi tanda tangan.

Solusinya:

import jwt from 'jsonwebtoken';
 
const publicKey = await fetchIdpPublicKey();
const decoded = jwt.verify(idToken, publicKey, {
  algorithms: ['RS256'],
  issuer: 'https://idp.company.com',
  audience: 'my-web-app-prod'
});

#Kesalahan 3: Mengabaikan Kedaluwarsa Token

Masalahnya:

// Menggunakan token kedaluwarsa
const token = sessionStorage.getItem('access_token');
// Tidak ada pemeriksaan kedaluwarsa

Solusinya:

function isTokenExpired(token: string): boolean {
  const decoded = jwt.decode(token) as any;
  return decoded.exp * 1000 < Date.now();
}
 
if (isTokenExpired(accessToken)) {
  await refreshAccessToken();
}

#Kesalahan 4: Tidak Menggunakan PKCE untuk SPA

Masalahnya:

// Alur kode otorisasi tanpa PKCE
const params = new URLSearchParams({
  client_id: 'my-app',
  redirect_uri: 'https://app.company.com/callback',
  response_type: 'code'
  // Hilang code_challenge
});

Mengapa berbahaya: Tanpa PKCE, kode otorisasi dapat disadap dan digunakan oleh penyerang.

Solusinya:

// Selalu gunakan PKCE untuk SPA
const codeChallenge = generateCodeChallenge(codeVerifier);
const params = new URLSearchParams({
  client_id: 'my-app',
  redirect_uri: 'https://app.company.com/callback',
  response_type: 'code',
  code_challenge: codeChallenge,
  code_challenge_method: 'S256'
});

#Praktik Terbaik untuk Produksi

#1. Gunakan PKCE untuk Semua Klien Publik

PKCE (Proof Key for Code Exchange) melindungi terhadap serangan intersepsi kode otorisasi.

function generateCodeChallenge(codeVerifier: string): string {
  const hash = crypto.createHash('sha256').update(codeVerifier).digest();
  return base64url(hash);
}
 
// Selalu sertakan dalam permintaan otorisasi
const codeChallenge = generateCodeChallenge(codeVerifier);

#2. Implementasikan Rotasi Token

Token refresh harus dirotasi pada setiap penggunaan untuk membatasi paparan:

async function refreshAccessToken(refreshToken: string) {
  const response = await fetch('https://idp.company.com/token', {
    method: 'POST',
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      refresh_token: refreshToken,
      client_id: 'my-app',
      client_secret: process.env.OAUTH_CLIENT_SECRET
    })
  });
  
  const { access_token, refresh_token: newRefreshToken } = 
    await response.json();
  
  // Simpan token refresh baru (yang lama tidak valid)
  await storeRefreshToken(newRefreshToken);
  
  return access_token;
}

#3. Implementasikan Logout yang Tepat

Logout harus membatalkan token di klien dan server:

async function logout() {
  // Hapus token klien
  sessionStorage.removeItem('access_token');
  
  // Batalkan token refresh di server
  await fetch('/api/auth/logout', {
    method: 'POST'
  });
  
  // Arahkan ke endpoint logout SSO
  window.location.href = 'https://idp.company.com/logout?' + 
    new URLSearchParams({
      post_logout_redirect_uri: 'https://app.company.com'
    });
}

#4. Pantau dan Beri Peringatan pada Aktivitas Mencurigakan

monitoring:
  alerts:
    - name: multiple-failed-logins
      condition: failed_login_attempts > 5 in 5m
      action: lock_account
    - name: token-reuse-detected
      condition: same_refresh_token_used_twice
      action: invalidate_all_tokens
    - name: unusual-location
      condition: login_from_new_country
      action: require_mfa

#5. Gunakan Token Akses Jangka Pendek

Pertahankan masa pakai token akses pendek (15-60 menit) untuk membatasi kerusakan jika dikompromikan:

tokenPolicy:
  accessToken:
    lifetime: 900 # 15 menit
    refreshable: false
  refreshToken:
    lifetime: 604800 # 7 hari
    rotateOnUse: true

#Kapan TIDAK Menggunakan OAuth 2.0 / SSO

#Skenario 1: Sistem Internal Sangat Sensitif

Untuk sistem dengan persyaratan keamanan ekstrem (transaksi keuangan, kesehatan), pertimbangkan lapisan tambahan:

• Persyaratan autentikasi multi-faktor (MFA)
• Kunci keamanan perangkat keras
• Autentikasi berbasis sertifikat
• Segmentasi jaringan

OAuth 2.0 masih sesuai, tetapi dengan kebijakan yang lebih ketat.

#Skenario 2: Sistem Legacy Tanpa Dukungan HTTP

Jika Anda memiliki sistem yang hanya mendukung LDAP atau Kerberos dan tidak dapat diperbarui:

• Pertahankan LDAP/Kerberos untuk sistem tersebut
• Gunakan jembatan SSO untuk aplikasi baru
• Rencanakan migrasi bertahap

#Skenario 3: Aplikasi Offline-First

Aplikasi yang harus bekerja tanpa konektivitas jaringan:

• Gunakan autentikasi lokal
• Sinkronkan data identitas saat online
• Pertimbangkan pendekatan hybrid

#Skenario 4: Komunikasi Mesin-ke-Mesin (M2M)

Untuk autentikasi layanan-ke-layanan, alur kredensial klien OAuth 2.0 sesuai, tetapi pertimbangkan:

• Mutual TLS (mTLS) untuk keamanan tambahan
• Integrasi service mesh
• Kebijakan rotasi kunci API

#Pola Arsitektur untuk SSO Modern

#Pola 1: SSO Terpusat dengan Beberapa Realm

┌─────────────────────────────────────────┐
│         Sistem SSO Pusat                │
├─────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐      │
│ │ Realm        │ │ Realm        │      │
│ │ Produksi     │ │ Staging      │      │
│ └──────────────┘ └──────────────┘      │
│ ┌──────────────┐ ┌──────────────┐      │
│ │ Realm        │ │ Realm        │      │
│ │ Internal     │ │ Mitra        │      │
│ └──────────────┘ └──────────────┘      │
└─────────────────────────────────────────┘
         │              │
    ┌────┴──────────────┴────┐
    │                        │
    ▼                        ▼
┌─────────────┐      ┌──────────────┐
│ Aplikasi    │      │ Aplikasi     │
│ Web         │      │ Mobile       │
└─────────────┘      └──────────────┘

#Pola 2: SSO Terfederasi Lintas Organisasi

┌──────────────────────┐      ┌──────────────────────┐
│  SSO Perusahaan A    │      │  SSO Perusahaan B    │
│  (IdP)               │      │  (IdP)               │
└──────────────────────┘      └──────────────────────┘
         │                             │
         └─────────────┬───────────────┘
                       │
                ┌──────▼──────┐
                │ Broker      │
                │ Federasi    │
                └──────┬──────┘
                       │
         ┌─────────────┴─────────────┐
         │                           │
         ▼                           ▼
    ┌─────────┐              ┌──────────┐
    │ Aplikasi│              │ Aplikasi │
    │ A       │              │ B        │
    └─────────┘              └──────────┘

#Strategi Migrasi: Dari LDAP ke OAuth 2.0

#Fase 1: Penilaian (Minggu 1-2)

• Inventaris semua aplikasi menggunakan LDAP/AD
• Kategorikan berdasarkan kritikalitas dan kompleksitas
• Identifikasi ketergantungan

#Fase 2: Pilot (Minggu 3-6)

• Terapkan sistem SSO di staging
• Migrasikan 2-3 aplikasi non-kritis
• Uji dengan subset pengguna
• Kumpulkan umpan balik

#Fase 3: Peluncuran Bertahap (Minggu 7-16)

• Migrasikan aplikasi dalam batch
• Pertahankan proxy LDAP untuk aplikasi legacy
• Pantau masalah
• Sediakan pelatihan pengguna

#Fase 4: Penghentian (Minggu 17+)

• Verifikasi semua aplikasi bermigrasi
• Nonaktifkan proxy LDAP
• Arsipkan infrastruktur LDAP
• Dokumentasikan pelajaran yang dipelajari

migration:
  phase1:
    duration: 2 weeks
    tasks:
      - audit_applications
      - assess_complexity
      - plan_rollout
  phase2:
    duration: 4 weeks
    pilot_apps:
      - internal-wiki
      - status-page
  phase3:
    duration: 10 weeks
    batches:
      - batch1: [jira, confluence, slack]
      - batch2: [github, gitlab, npm-registry]
      - batch3: [custom-apps]
  phase4:
    duration: ongoing
    tasks:
      - monitor_stability
      - optimize_performance
      - decommission_ldap

#Kesimpulan

Pergeseran dari LDAP dan Active Directory ke OAuth 2.0 dan SSO mewakili lebih dari sekadar peningkatan teknologi—ini adalah evolusi arsitektur yang didorong oleh cara kita bekerja hari ini.

Poin-poin kunci:

• LDAP/AD dirancang untuk jaringan korporat terpercaya; mereka tidak scalable ke cloud dan tim terdistribusi
• OAuth 2.0 menyediakan otorisasi stateless yang scalable; OpenID Connect menambahkan autentikasi di atasnya
• Token (akses, refresh, ID) adalah mata uang autentikasi modern
• Kerberos tetap berharga untuk lingkungan on-premises tetapi tidak cocok untuk arsitektur cloud-native
• Kompatibilitas LDAP dapat dipertahankan selama migrasi melalui jembatan dan proxy
• Praktik keamanan lebih penting dari sebelumnya: PKCE, rotasi token, masa pakai pendek, logout yang tepat

Mulai dengan program pilot, pelajari dari penggunaan dunia nyata, dan migrasikan secara bertahap. Investasi dalam infrastruktur identitas modern memberikan dividen dalam keamanan, skalabilitas, dan pengalaman pengguna.

Langkah berikutnya Anda: Evaluasi solusi SSO untuk kebutuhan spesifik organisasi Anda, mempertimbangkan faktor-faktor seperti infrastruktur yang ada, persyaratan kepatuhan, dan keahlian tim.