OAuth di dalam VPN: ruas mana yang masih memerlukan TLS

Perutean privat menentukan siapa yang mencapai server; aturan transport OAuth menentukan bagaimana setiap pesan bepergian. Peramban, server otorisasi, titik akhir token, dan server sumber daya semuanya dapat berada di belakang VPN yang sama dan tetap bertukar pesan melalui ruas yang berbeda. Setiap ruas memiliki persyaratan transportnya sendiri, dan VPN tidak melonggarkan satu pun. Batas VPN dan batas protokol adalah dua garis berbeda.

Keputusannya lebih mudah jika Anda berhenti bertanya apakah jaringan tepercaya dan mulai bertanya pertukaran mana yang melewati batas mana.

Putuskan per ruas, bukan per jaringan

Tuliskan titik akhir secara terpisah: titik akhir otorisasi, titik akhir token, URI pengalihan, URL server sumber daya, titik penghentian TLS, dan gerbang VPN. Lalu tandai pihak mana yang memulai setiap permintaan dan ke mana respons pergi.

VPN yang berakhir di gerbang mengenkripsi segmen sampai gerbang itu. Permintaan dapat berlanjut sebagai HTTP biasa di belakangnya, dan ruas yang tersisa itu tidak menjadi HTTPS karena segmen sebelumnya dienkripsi. Justru kelanjutan itulah ruas yang dipedulikan protokol. Mengenkripsi lompatan pertama tidak membuat lompatan kedua aman.

Transport juga membawa pemeriksaan identitas layanan. Peramban memvalidasi sertifikat untuk URL aplikasi; VPN tidak melakukan validasi itu atas nama peramban, dan tidak membuat titik akhir yang tidak tervalidasi menjadi dapat diterima. Sertifikat menamai titik akhir yang menurut klien sedang dipanggilnya. Terowongan ke gerbang tidak mengganti nama titik akhir itu atau memvalidasinya.

Respons otorisasi dan URI pengalihan

Praktik terbaik keamanan OAuth saat ini melarang pengiriman respons otorisasi melalui koneksi tanpa enkripsi. Itu mencakup pengalihan yang membawa kode otorisasi atau token kembali ke klien, bukan hanya permintaan awal.

Panduan yang sama tidak mengizinkan URI pengalihan HTTP, kecuali kasus loopback klien asli yang ditentukan. Nama host internal tidak menciptakan pengecualian baru, dan nama DNS yang hanya diselesaikan di dalam VPN tetap URL HTTP jika skemanya menyatakan demikian. Periksa skema pada URI yang terdaftar, bukan hanya nama host.

Daftarkan URI pengalihan HTTPS yang tepat pada server otorisasi dan biarkan validasi sertifikat tetap aktif di klien. Pintasan pengembangan yang menekan persyaratan HTTPS menghasilkan alur yang berperilaku berbeda dari konfigurasi produksi yang seharusnya dimodelkannya.

Titik akhir token dan permintaan token pembawa

Permintaan token membawa kredensial atau kode yang dapat ditukar dengan akses. Mengirimnya melalui ruas yang tidak terlindungi memaparkan materi yang nantinya akan dipercaya server sumber daya, meskipun jaringan di sekitarnya privat. Proksi yang dapat membaca permintaan juga dapat membaca kredensial yang dibawanya.

Untuk permintaan sumber daya dengan token pembawa, RFC 6750 memperlakukan TLS sebagai wajib diimplementasikan dan digunakan untuk spesifikasi itu. Menyebut subnet kantor tepercaya bukan pengecualian protokol umum yang dibutuhkan penerapan pembawa dalam teks biasa.

Gunakan URL titik akhir aman yang didokumentasikan untuk kedua ruas. Jika pustaka menolak memanggil titik akhir token HTTP, penolakan itu adalah spesifikasi yang bekerja, bukan bug konfigurasi untuk diakali. Catat URL itu dalam konfigurasi klien alih-alih menurunkannya saat runtime.

Di mana TLS berakhir dan apa yang tersisa

Jika TLS berakhir di frontend yang diotorisasi, sebutkan frontend itu dan tinjau jalur dari sana ke aplikasi. Frontend menjadi bertanggung jawab atas penerusan, kepercayaan, dan kerahasiaan pada segmen yang tersisa, dan arsitektur layanan yang didukung semestinya menjelaskan pengaturan itu.

VPN di tempat lain pada jalur tidak menyelesaikan tanggung jawab itu. VPN itu juga tidak memberi tahu apakah URL aplikasi yang dilihat peramban cocok dengan sertifikat yang disajikan frontend.

Untuk penerapan internal, catat titik penghentian dan identitas yang disajikannya. Frontend yang mengakhiri TLS dengan sertifikat untuk nama lain menciptakan peringatan peramban yang sering ditekan operator alih-alih diperbaiki.

Pengecualian loopback asli itu sempit

Pengecualian pengalihan loopback menyangkut panggilan balik pada perangkat pengguna sendiri, tempat klien dan peramban berbagi perangkat itu. Pengaturan itu milik panggilan balik pada satu perangkat, dan tidak memberi lisensi untuk melayani server otorisasi biasa atau API yang membawa token melalui HTTP ke subnet kantor.

Jaga pengecualian tetap terbatas pada jenis klien dan panggilan balik yang dijelaskannya. Menerapkannya pada aplikasi web, layanan internal bersama, atau URI pengalihan di host lain mengubah penerapan, bukan pengecualiannya.

Uji alur sebenarnya di setiap batas dan bandingkan dengan jenis klien. Pengalihan yang berfungsi tidak mengatakan apa pun tentang apakah setiap ruas yang membawa token menggunakan perlindungan yang diwajibkan, dan ikon VPN hijau tidak mengatakan apa pun tentang skema permintaan berikutnya.