Identitas Terfederasi: SAML, OAuth, dan OpenID Connect

Dalam perusahaan modern, karyawan perlu mengakses puluhan aplikasi — aplikasi cloud, alat SaaS, portal mitra, dan sistem internal — yang masing-masing mungkin dikelola oleh organisasi yang berbeda. Membuat dan mengelola akun terpisah untuk setiap aplikasi tidak aman (menyebabkan kredensial berlebihan) dan tidak efisien. Identitas terfederasi mengatasi masalah ini dengan memungkinkan Penyedia Identitas (IdP) — sumber identitas yang tepercaya dan berwenang — mengautentikasi pengguna serta membagikan identitas yang telah diautentikasi tersebut kepada Penyedia Layanan (SP) di berbagai batas organisasi. Pengguna cukup melakukan autentikasi sekali untuk memperoleh akses ke banyak sistem tanpa memasukkan kembali kredensial.

Single Sign-On (SSO) memungkinkan pengguna melakukan autentikasi sekali dan mengakses beberapa aplikasi dalam satu sesi tanpa perlu melakukan autentikasi ulang. Pengguna masuk ke Penyedia Identitas (Active Directory perusahaan, Okta, Azure AD), menerima token sesi atau pernyataan, lalu memberikan token tersebut kepada setiap Penyedia Layanan yang dikunjungi. SSO meningkatkan keamanan dengan mengurangi jumlah kata sandi yang harus dikelola pengguna (sehingga mengurangi penggunaan ulang kata sandi), memungkinkan penerapan kebijakan autentikasi secara terpusat, dan memungkinkan pencabutan akses segera di semua aplikasi yang terintegrasi ketika akun dinonaktifkan pada tingkat IdP.

SAML (Bahasa Markah Pernyataan Keamanan) 2.0 adalah standar terbuka berbasis XML untuk bertukar data autentikasi dan otorisasi antara Penyedia Identitas dan Penyedia Layanan. Alur SAML adalah sebagai berikut: (1) pengguna mengakses Penyedia Layanan (misalnya Salesforce), (2) SP mengarahkan pengguna ke Penyedia Identitas (misalnya Okta), (3) pengguna melakukan autentikasi di IdP, (4) IdP menerbitkan Pernyataan SAML XML bertanda tangan yang berisi identitas dan atribut pengguna, (5) pernyataan tersebut dikembalikan kepada SP, (6) SP memvalidasi tanda tangan pernyataan menggunakan kunci publik IdP dan memberikan akses. SAML banyak digunakan untuk SSO perusahaan pada aplikasi web.

Tiga pihak berpartisipasi dalam federasi SAML. Principal adalah pengguna (atau sistem) yang meminta akses — pihak ini memulai proses autentikasi. Penyedia Identitas (IdP) adalah sumber identitas berwenang yang mengautentikasi principal dan menerbitkan pernyataan — contohnya Microsoft Azure AD, Okta, Ping Identity, dan ADFS. Penyedia Layanan (SP) menggunakan pernyataan tersebut dan memberikan akses berdasarkan isinya — contohnya Salesforce, Google Workspace, AWS, dan aplikasi apa pun yang mendukung SAML. SP dan IdP membangun kepercayaan terlebih dahulu dengan bertukar metadata yang berisi URL titik akhir dan sertifikat penandatanganan satu sama lain.

OAuth 2.0 adalah kerangka otorisasi (bukan protokol autentikasi) yang memungkinkan aplikasi pihak ketiga mengakses sumber daya atas nama pengguna tanpa membuka kredensial pengguna. Contoh penggunaan yang umum adalah: “Izinkan aplikasi pengedit foto ini mengakses Google Photos Anda.” OAuth 2.0 memperkenalkan empat peran: Pemilik Sumber Daya (pengguna), Client (aplikasi pihak ketiga), Server Otorisasi (menerbitkan token), dan Server Sumber Daya (menyediakan sumber daya yang dilindungi). Pengguna memberikan otorisasi kepada client, yang kemudian menerima token akses untuk diberikan kepada server sumber daya — tanpa pernah memerlukan kata sandi pengguna yang sebenarnya.

Alur Kode Otorisasi adalah alur OAuth 2.0 yang paling aman untuk aplikasi web. Alurnya adalah sebagai berikut: (1) Client mengarahkan pengguna ke Server Otorisasi dengan menyertakan scope yang diminta; (2) Pengguna melakukan autentikasi dan memberikan persetujuan di Server Otorisasi; (3) Server Otorisasi mengarahkan pengguna kembali dengan kode otorisasi yang berumur singkat; (4) Client menukar kode tersebut dengan token akses (dan, jika diperlukan, token penyegaran) melalui panggilan antars server menggunakan kredensial client; (5) Client menggunakan token akses untuk memanggil Server Sumber Daya. Pertukaran kode berlangsung di sisi server, sehingga token akses tidak terekspos dalam riwayat peramban atau catatan.

OpenID Connect (OIDC) adalah lapisan autentikasi yang dibangun di atas OAuth 2.0. OAuth hanya menyediakan otorisasi (token akses membuktikan tindakan yang dapat dilakukan client); OIDC menambahkan autentikasi (token ID membuktikan identitas pengguna). OIDC menambahkan scope openid ke alur OAuth dan mengembalikan Token ID JWT (JSON Web Token) bertanda tangan bersama token akses. Token ID berisi klaim (nama, email, sub [pengenal subjek]) yang mengidentifikasi pengguna. OIDC kini menjadi protokol dominan untuk SSO yang ditujukan kepada konsumen — semua tombol “Masuk dengan Google/Apple/Microsoft” menggunakan OIDC.

JSON Web Token (JWT) adalah format ringkas yang aman digunakan dalam URL untuk merepresentasikan klaim di antara berbagai pihak. JWT memiliki tiga bagian yang dikodekan dalam base64url dan dipisahkan oleh titik: Header (algoritme dan jenis token), Payload (klaim: iss, sub, aud, exp, iat, dan klaim khusus), serta Signature (tanda tangan kriptografis yang memverifikasi integritas token). JWT bersifat mandiri — Server Sumber Daya dapat memverifikasinya tanpa menghubungi kembali Server Otorisasi, sehingga meningkatkan kinerja dan memungkinkan arsitektur tanpa status. Persyaratan keamanan yang penting: selalu verifikasi tanda tangan JWT dan periksa klaim exp (masa berlaku) serta aud (audiens).

Memahami kapan setiap standar diterapkan sangat penting untuk ujian Security+. SAML 2.0: SSO perusahaan untuk aplikasi web, alur berbasis peramban, dan pernyataan XML. Bersifat lama, tetapi digunakan secara luas di perusahaan. OAuth 2.0: otorisasi API — memberikan akses terbatas kepada aplikasi pihak ketiga untuk menggunakan sumber daya. Tidak mengautentikasi pengguna secara langsung. OIDC: autentikasi konsumen dan perusahaan modern (SSO) yang dibangun di atas OAuth 2.0. Mengembalikan token ID JWT yang mengidentifikasi pengguna. Dalam praktiknya, lingkungan perusahaan sering menggunakan SAML untuk SSO aplikasi dan OIDC untuk autentikasi API/perangkat seluler. Lingkungan cloud-native modern lebih memilih OIDC daripada SAML karena format JSON/JWT dan dukungan perangkat selulernya yang lebih baik.

Sistem identitas terfederasi memperkenalkan vektor serangan tertentu. Serangan pemutaran ulang pernyataan: penyerang mencegat pernyataan SAML lalu menggunakannya kembali untuk memperoleh akses. Mitigasinya adalah menggunakan masa berlaku pernyataan yang singkat dan ID pernyataan yang hanya dapat digunakan sekali. Pembungkusan tanda tangan XML (XSW): dalam SAML, penyerang terkadang dapat memanipulasi XML bertanda tangan untuk mengubah klaim, sementara tanda tangan pada konten asli tetap valid. Kebingungan algoritme JWT: jika server menerima algoritme RS256 (asimetris) dan HS256 (simetris), penyerang dapat memalsukan JWT dengan menggunakan kunci publik server sebagai rahasia HMAC untuk HS256. Selalu validasi bahwa header algoritme sesuai dengan algoritme yang diharapkan. Pengarah ulang terbuka: URI pengalihan OAuth harus dicocokkan secara tepat untuk mencegah pencurian token melalui pengalihan ke situs yang dikendalikan penyerang.

Federasi identitas perusahaan sering memerlukan sinkronisasi data identitas pengguna di antara berbagai sistem. SCIM (Manajemen Identitas Lintas Domain Sistem) adalah standar API REST untuk mengotomatiskan penyediaan dan pencabutan penyediaan pengguna antara Penyedia Identitas dan Penyedia Layanan yang terhubung. Ketika karyawan baru ditambahkan ke Azure AD (IdP), SCIM secara otomatis membuat akun mereka di Salesforce, Slack, GitHub, dan aplikasi lain yang kompatibel dengan SCIM. Ketika karyawan tersebut diberhentikan, SCIM menonaktifkan semua akun secara bersamaan — menutup celah waktu ketika akun yatim dapat dieksploitasi. SCIM melengkapi protokol SSO (SAML/OIDC) dengan menangani pengelolaan siklus hidup yang tidak dicakup oleh protokol SSO.

Dalam pelajaran ini, Anda telah mempelajari bahwa SAML 2.0 menggunakan pernyataan XML untuk SSO perusahaan berbasis peramban; OAuth 2.0 adalah kerangka otorisasi untuk pendelegasian akses API; OpenID Connect menambahkan autentikasi (token ID JWT) di atas OAuth; dan SCIM mengotomatiskan pengelolaan siklus hidup identitas di berbagai sistem terfederasi. Kursus Autentikasi dan Otorisasi ini telah selesai — selanjutnya kita akan membahas Dasar-Dasar Keamanan Jaringan.