OAuth dan OpenID Connect: beda izin API dan login

OAuth dan OIDC digunakan untuk apa?

OAuth 2.0 mengatur pemberian izin akses; OpenID Connect (OIDC) menyediakan informasi identitas untuk login di atas OAuth. Keduanya sering muncul dalam satu integrasi, tetapi menerima token tidak otomatis membuktikan siapa penggunanya atau data apa yang boleh ia buka.

Aplikasi yang meminta akses disebut client. Server otorisasi menerbitkan token, sedangkan API tujuan memeriksa akses ke sumber daya. Dalam OIDC, penyedia identitas juga memberikan ID token kepada aplikasi.

Bedakan tiga jenis token

Jenis	Kegunaan
ID token	Memberi aplikasi informasi tentang autentikasi pengguna
Access token	Dipakai untuk mengakses API yang menjadi tujuannya, sesuai izin
Refresh token	Meminta access token baru, bila alur dan kebijakan mengizinkan

Jangan mengirim ID token sebagai pengganti access token ke API. Membaca isi JWT saja juga bukan validasi; API dan aplikasi perlu menjalankan pemeriksaan yang sesuai dengan jenis token dan protokolnya.

Contoh: portal pegawai dan kalender

Contoh fiktif: portal memakai OIDC untuk mengenali pegawai, kemudian meminta izin membaca kalender melalui OAuth. Pegawai yang berhasil login belum tentu menyetujui akses kalender. Jika izin ditolak, portal tetap perlu menjelaskan fitur mana yang tidak tersedia.

Tim membuat dua pengujian terpisah: akun yang sah dapat masuk, lalu fitur kalender hanya dapat membaca data yang diizinkan. Izin kalender tidak boleh sekaligus membuka dokumen atau menu admin. Catat hasil tiap pengujian, bukan hanya tangkapan layar tombol login.

Apa yang diperiksa saat integrasi?

• Untuk login interaktif baru, gunakan pustaka yang dipelihara dan alur authorization code dengan PKCE. PKCE mengikat penukaran kode ke transaksi yang memulainya; bukan pengganti seluruh validasi token.
• Daftarkan alamat callback secara tepat. Terapkan perlindungan CSRF dan pengikatan transaksi melalui mekanisme PKCE, state, atau nonce sesuai alur dan pustaka; jangan menonaktifkannya untuk menghilangkan error.
• Periksa penerbit (iss), penerima (aud), masa berlaku, keaslian token, dan nonce bila dikirim. Gunakan kunci serta algoritma yang dipercaya.
• Gunakan pasangan penerbit dan pengenal pengguna (iss dan sub) untuk pemetaan identitas OIDC. Jangan menggabungkan akun hanya karena alamat email yang diterima sama.

API tetap memeriksa tujuan token, lingkup izin (scope), dan izin terhadap objek. Batasi refresh token serta tangani pencabutannya sesuai protokol. Jangan menaruh token di URL, tiket bantuan, atau log umum.

Bukti sebelum fitur diterima

Uji token untuk aplikasi lain, token kedaluwarsa, pembatalan login, dan pencabutan izin dengan akun buatan. Tim perlu menunjukkan bahwa penolakan terjadi di server dan tidak memberikan data. Hindari alur lama yang meminta aplikasi mengumpulkan kata sandi pengguna untuk ditukar dengan token.

Lanjutkan ke sesi login dan token untuk perilaku setelah masuk, atau SAML SSO bila integrasi memakai assertion SAML.