Open ID Connect
Di bagian ini, kami akan memberikan beberapa informasi latar belakang utama tentang OpenID Connect yang akan membantu Anda memahami beberapa kerentanan yang akan kami bahas. Jika Anda baru mengenal OAuth dan OpenID Connect secara khusus, sebaiknya baca bagian ini sebelum mencoba menyelesaikan lab berbasis OpenID kami.
What is OpenID Connect?
OpenID Connect memperluas protokol OAuth untuk memberikan identitas khusus dan lapisan otentikasi yang berada di atas implementasi OAuth dasar. Ia menambahkan beberapa fungsionalitas sederhana yang memungkinkan dukungan yang lebih baik untuk kasus penggunaan otentikasi OAuth.
OAuth pada awalnya tidak dirancang dengan mempertimbangkan otentikasi; itu dimaksudkan untuk menjadi sarana pendelegasian otorisasi untuk sumber daya tertentu antar aplikasi. Namun, banyak situs web mulai menyesuaikan OAuth untuk digunakan sebagai mekanisme autentikasi. Untuk mencapai hal ini, mereka biasanya meminta akses baca ke beberapa data pengguna dasar dan, jika mereka diberikan akses ini, diasumsikan bahwa pengguna mengautentikasi diri mereka sendiri di sisi penyedia OAuth.
Mekanisme autentikasi OAuth biasa ini jauh dari ideal. Sebagai permulaan, aplikasi klien tidak memiliki cara untuk mengetahui kapan, di mana, atau bagaimana pengguna diautentikasi. Karena masing-masing implementasi ini adalah semacam solusi khusus, juga tidak ada cara standar untuk meminta data pengguna untuk tujuan ini. Untuk mendukung OAuth dengan benar, aplikasi klien harus mengonfigurasi mekanisme OAuth terpisah untuk setiap penyedia, masing-masing dengan titik akhir berbeda, kumpulan cakupan unik, dan sebagainya.
OpenID Connect memecahkan banyak masalah ini dengan menambahkan fitur standar terkait identitas agar autentikasi melalui OAuth berfungsi dengan cara yang lebih andal dan seragam.
How does OpenID Connect work?
OpenID Connect slot dengan rapi ke dalam aliran OAuth normal. Dari perspektif aplikasi klien, perbedaan utamanya adalah adanya rangkaian cakupan standar tambahan yang sama untuk semua penyedia, dan jenis respons tambahan: id_token.
OpenID Connect roles
Peran OpenID Connect pada dasarnya sama seperti untuk OAuth standar. Perbedaan utamanya adalah spesifikasinya menggunakan terminologi yang sedikit berbeda.
- Relying party - Aplikasi yang meminta otentikasi pengguna. Ini identik dengan aplikasi klien OAuth.
- Pengguna akhir - Pengguna yang diautentikasi. Ini identik dengan pemilik sumber daya OAuth.
- Penyedia OpenID - Layanan OAuth yang dikonfigurasi untuk mendukung OpenID Connect.
OpenID Connect claims and scopes
Istilah "claim" mengacu pada pasangan kunci: nilai yang mewakili informasi tentang pengguna di server sumber daya. Salah satu contoh klaim bisa jadi "family_name": "Montoya".
Tidak seperti OAuth dasar, yang cakupannya unik untuk setiap penyedia, semua layanan OpenID Connect menggunakan rangkaian cakupan yang identik. Untuk menggunakan OpenID Connect, aplikasi klien harus menentukan cakupan openid dalam permintaan otorisasi. Mereka kemudian dapat menyertakan satu atau beberapa cakupan standar lainnya:
profile
email
address
phone
Setiap cakupan ini sesuai dengan akses baca untuk subset klaim tentang pengguna yang ditentukan dalam spesifikasi OpenID. Misalnya, meminta profil openid cakupan akan memberi aplikasi klien akses baca ke serangkaian klaim yang terkait dengan identitas pengguna, seperti family_name, given_name, birth_date, dan seterusnya.
ID Token
Tambahan utama lainnya yang disediakan oleh OpenID Connect adalah tipe respons id_token. Ini mengembalikan token web JSON (JWT) yang ditandatangani dengan tanda tangan web JSON (JWS). Muatan JWT berisi daftar klaim berdasarkan cakupan yang awalnya diminta. Ini juga berisi informasi tentang bagaimana dan kapan pengguna terakhir kali diautentikasi oleh layanan OAuth. Aplikasi klien dapat menggunakan ini untuk memutuskan apakah pengguna telah cukup diautentikasi atau tidak.
Manfaat utama menggunakan id_token adalah berkurangnya jumlah permintaan yang perlu dikirim antara aplikasi klien dan layanan OAuth, yang dapat memberikan kinerja yang lebih baik secara keseluruhan. Alih-alih harus mendapatkan token akses dan kemudian meminta data pengguna secara terpisah, token ID yang berisi data ini dikirim ke aplikasi klien segera setelah pengguna mengautentikasi dirinya sendiri.
Daripada hanya mengandalkan saluran tepercaya, seperti yang terjadi di OAuth dasar, integritas data yang dikirimkan dalam token ID didasarkan pada tanda tangan kriptografi JWT. Untuk alasan ini, penggunaan token ID dapat membantu melindungi dari beberapa serangan man-in-the-middle. Namun, mengingat kunci kriptografi untuk verifikasi tanda tangan dikirimkan melalui saluran jaringan yang sama (biasanya diekspos di /.well-known/jwks.json), beberapa serangan masih mungkin dilakukan.
Perhatikan bahwa beberapa jenis tanggapan didukung oleh OAuth, jadi sangat dapat diterima untuk aplikasi klien untuk mengirim permintaan otorisasi dengan jenis tanggapan OAuth dasar dan jenis tanggapan id_token OpenID Connect:
response_type = id_token token
response_type = id_token code
Dalam kasus ini, baik token ID maupun kode atau token akses akan dikirim ke aplikasi klien pada saat yang bersamaan.
Mengidentifikasi OpenID Connect
Jika OpenID connect secara aktif digunakan oleh aplikasi klien, ini harus terlihat jelas dari permintaan otorisasi. Cara paling mudah untuk memeriksa adalah dengan mencari cakupan openid wajib.
Meskipun proses masuk pada awalnya tidak tampak menggunakan OpenID Connect, tetap ada baiknya untuk memeriksa apakah layanan OAuth mendukungnya. Anda cukup mencoba menambahkan cakupan openid atau mengubah jenis respons ke id_token dan mengamati apakah ini menghasilkan kesalahan.
Seperti OAuth dasar, sebaiknya lihat dokumentasi penyedia OAuth untuk melihat apakah ada informasi yang berguna tentang dukungan OpenID Connect mereka. Anda juga dapat mengakses file konfigurasi dari endpoint standar /.well-known/openid-configuration.
Kerentanan OpenID Connect
Spesifikasi OpenID Connect jauh lebih ketat daripada spesifikasi OAuth dasar, yang berarti secara umum potensi penerapan unik dengan kerentanan mencolok lebih kecil. Meskipun demikian, karena ini hanya lapisan yang berada di atas OAuth, aplikasi klien atau layanan OAuth mungkin masih rentan terhadap beberapa serangan berbasis OAuth yang telah kita lihat sebelumnya.
Di bagian ini, kita akan melihat beberapa kerentanan tambahan yang mungkin diperkenalkan oleh beberapa fitur tambahan OpenID Connect.
Unprotected dynamic client registration
Spesifikasi OpenID menguraikan cara standar untuk mengizinkan aplikasi klien mendaftar dengan penyedia OpenID. Jika pendaftaran klien dinamis didukung, aplikasi klien dapat mendaftar sendiri dengan mengirimkan permintaan POST ke titik akhir khusus / pendaftaran. Nama titik akhir ini biasanya tersedia di file konfigurasi dan dokumentasi.
Di badan permintaan, aplikasi klien mengirimkan informasi penting tentang dirinya sendiri dalam format JSON. Misalnya, sering kali diperlukan untuk menyertakan larik URI pengalihan yang masuk daftar putih. Itu juga dapat mengirimkan berbagai informasi tambahan, seperti nama titik akhir yang ingin mereka ungkapkan, nama untuk aplikasi mereka, dan sebagainya. Permintaan pendaftaran biasanya terlihat seperti ini:
POST /openid/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: oauth-authorization-server.com
Authorization: Bearer ab12cd34ef56gh89
{
"application_type": "web",
"redirect_uris": [
"https://client-app.com/callback",
"https://client-app.com/callback2"
],
"client_name": "My Application",
"logo_uri": "https://client-app.com/logo.png",
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client-app.com/my_public_keys.jwks",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC-HS256",
…
}
Penyedia OpenID harus mewajibkan aplikasi klien untuk mengautentikasi dirinya sendiri. Pada contoh di atas, mereka menggunakan token pembawa HTTP. Namun, beberapa penyedia akan mengizinkan pendaftaran klien dinamis tanpa otentikasi apa pun, yang memungkinkan penyerang untuk mendaftarkan aplikasi klien jahat mereka sendiri. Ini dapat memiliki berbagai konsekuensi tergantung pada bagaimana nilai properti yang dapat dikontrol penyerang ini digunakan.
Misalnya, Anda mungkin telah memperhatikan bahwa beberapa properti ini dapat disediakan sebagai URI. Jika salah satu dari ini diakses oleh penyedia OpenID, ini berpotensi menyebabkan kerentanan SSRF orde kedua kecuali ada langkah keamanan tambahan.
Komentar
Posting Komentar