Langsung ke konten

Arsip

OAuth

5 artikel
Keamanan Siber 20 Sep 2026 5 min read

Pemeriksaan Audience JWT Menjaga Token di Batas Layanan yang Dituju

Pemeriksaan Audience JWT Menjaga Token di Batas Layanan yang Dituju Signature JSON Web Token yang valid membuktikan hal yang terbatas: byte token ditandatangani dengan key yang diterima verifier dan tidak diubah setelahnya tanpa membuat signature menjadi tidak valid. Hasil itu tidak menetapkan bahwa token diterbitkan untuk layanan yang sedang menerimanya. Perbedaan ini penting pada sistem tempat satu authority menerbitkan token bagi beberapa API, atau beberapa authority memakai key yang dapat dijangkau aplikasi melalui konfigurasi. Token dapat valid secara kriptografis tetapi berasal dari konteks keamanan yang berbeda. Claim iss dan aud memberi verifier input untuk menegakkan batas tersebut.

Keamanan Siber 20 Sep 2026 6 min read

DPoP Mengikat Access Token OAuth ke Kunci Client

DPoP Mengikat Access Token OAuth ke Kunci Client Bearer access token dapat digunakan oleh pihak mana pun yang memperoleh token tersebut dan mampu menyajikannya ke resource server. TLS melindungi token saat melewati koneksi yang diautentikasi dengan benar, tetapi tidak mengubah sifat bearer itu setelah token mencapai endpoint, log, process, browser context, atau lokasi penyimpanan lain. Demonstrating Proof of Possession (DPoP), yang ditetapkan dalam RFC 9449, menambahkan binding berbasis kunci pada layer application protocol. Client membuat asymmetric key pair lalu menandatangani DPoP proof JWT. Authorization server dapat mengikat access token yang diterbitkan ke public key yang direpresentasikan oleh proof tersebut. Resource server kemudian mewajibkan token sekaligus proof valid yang dibuat dengan private key pasangannya.

Keamanan Siber 19 Sep 2026 6 min read

DPoP Mengikat Token OAuth ke Kunci Client, Bukan ke Identitas Client

Bearer access token biasanya memberikan otorisasi kepada pihak mana pun yang dapat mempresentasikan nilainya ke resource server. Menyalin token karena itu dapat memindahkan otoritasnya dari client yang semula menerima token tersebut. OAuth 2.0 Demonstrating Proof of Possession, atau DPoP, mengubah sifat ini dengan mengikat token ke public key dan mewajibkan signed proof dari private key pasangannya saat token dipresentasikan. Binding tersebut mempersempit satu failure mode penting, tetapi tidak mengubah kunci menjadi identitas client universal. DPoP adalah mekanisme sender-constraining pada application layer. Jaminannya bergantung pada token binding, validasi proof, policy replay, TLS, dan keamanan konteks eksekusi client.

Keamanan Siber 19 Sep 2026 7 min read

Binding Sertifikat OAuth mTLS Memindahkan Bukti Token ke Koneksi TLS

Binding Sertifikat OAuth mTLS Memindahkan Bukti Token ke Koneksi TLS Sebuah OAuth access token dapat lolos dari seluruh pemeriksaan sintaks dan kriptografi di resource server tetapi tetap belum cukup untuk memperoleh akses. Pada token yang terikat sertifikat mutual TLS, server juga memerlukan bukti dari koneksi TLS: client yang membawa token harus memiliki private key yang sesuai dengan sertifikat yang diasosiasikan dengan token tersebut. Kondisi ini mengubah batas keamanan. Bearer token dapat digunakan oleh pihak yang memperoleh nilai token, dengan tetap tunduk pada pembatasan token lainnya. Token yang terikat sertifikat menambahkan syarat kepemilikan terpisah yang terhubung ke TLS client certificate. Token dan private key menjadi dua bagian dalam jalur otorisasi yang sama.

Keamanan Siber 10 Sep 2026 11 min read

Ikat Callback OAuth ke Login yang Memulainya

Callback OAuth dapat terlihat valid meskipun berasal dari interaksi browser yang salah. Authorization server mungkin telah menerbitkan code yang nyata, redirect URI mungkin benar, dan pertukaran code mungkin berhasil. Namun jika client tidak dapat menentukan apakah browser ini benar-benar memulai authorization flow tersebut, client dapat mengaitkan identitas eksternal atau authorization yang salah ke session saat ini. Ini adalah bentuk cross-site request forgery pada callback OAuth. Dalam login flow, salah satu konsekuensinya adalah login CSRF: korban dapat berakhir login ke client sebagai account yang terkait dengan orang lain. Detailnya berbeda antar-aplikasi, tetapi pertanyaan defensifnya tetap sama: apakah callback ini milik transaksi login yang dimulai user agent ini?