Tugas otorisasi
Masalah otorisasi di lusinan layanan ditemui beberapa tahun yang lalu - pada awal “ era menggergaji monolit ”. Masalah ini telah diatasi dengan layanan baru bernama Auth. Dia membantu mengimplementasikan otentikasi tanpa batas di berbagai layanan dan memigrasi data pengguna ke database terpisah.
Layanan Auth memiliki tiga tugas utama:
- Titik tunggal otentikasi (SSO) untuk semua layanan sistem . Layanan tidak menyimpan kredensial, tetapi percayakan ini ke satu layanan khusus.
- Akses yang aman dan terperinci ke sumber daya . Aman karena kata sandi disimpan di satu tempat dan seaman mungkin. Terperinci, karena pemilik layanan dapat mengonfigurasi akses ke sumber daya yang mereka inginkan, berdasarkan data yang berasal dari layanan otentikasi.
- . , , .
Versi pertama Auth adalah bagian dari monolit. Ia menggunakan protokolnya sendiri untuk berkomunikasi dengan layanan. "Skema" seperti itu diperlukan pada saat itu, tetapi setelah beberapa tahun masalah pekerjaan muncul.
Auth adalah bagian dari monolit . Akibatnya, layanan terikat dengan siklus rilis, yang membuatnya tidak mungkin untuk pengembangan dan penerapan independen. Selain itu, Anda harus menerapkan seluruh monolit jika ingin menerapkan Auth, misalnya, saat menskalakan layanan.
Dodo IS bergantung pada Auth . Dalam implementasi lama, layanan eksternal memanggil Auth pada setiap tindakan pengguna untuk memvalidasi data tentangnya. Pengikatan yang ketat ini dapat menyebabkan seluruh Dodo IS berhenti berfungsi jika Auth macet karena suatu alasan.
Auth bergantung pada Redis... Selain itu, ini cukup kuat - kerusakan Redis akan menyebabkan jatuhnya Auth. Kami menggunakan Azure Redis, yang SLA-nya 99,9%. Artinya, layanan tersebut tidak dapat tersedia hingga 44 menit per bulan. Waktu henti seperti itu tidak diperbolehkan.
Implementasi Auth saat ini menggunakan protokol otentikasi sendiri tanpa bergantung pada standar . Di sebagian besar layanan kami, kami menggunakan C # (jika kami berbicara tentang backend) dan kami tidak memiliki masalah dengan pemeliharaan perpustakaan untuk protokol kami. Tetapi jika layanan di Python, Go atau Rust tiba-tiba muncul, pengembangan dan dukungan pustaka untuk bahasa-bahasa ini akan memakan waktu tambahan dan membawa kerumitan tambahan.
Autentikasi Saat Ini menggunakan skema Kontrol Akses Berbasis Peran yang didasarkan pada peran... Biasanya, peran tersebut diberikan akses penuh ke layanan tertentu, alih-alih terikat pada fungsionalitas tertentu. Misalnya, di restoran pizza ada wakil manajer yang dapat memimpin proyek tertentu: menyusun jadwal atau memperhitungkan bahan mentah. Tapi kami tidak memiliki hak atas komponen tertentu dari sistem. Anda harus memberikan akses penuh ke layanan tersebut sehingga karyawan dapat mengakses penjadwalan atau pengaturan komponen akuntansi apa pun.
Masalah mendorong kami untuk merancang dan menulis versi baru Auth. Di awal proyek, kami menghabiskan waktu 3 minggu hanya untuk mempelajari standar autentikasi dan otorisasi OAuth 2.0 dan OpenID Connect 1.0.
Catatan... Dilebih-lebihkan, artikel tersebut menceritakan kembali RFC, yang harus dibaca ulang beberapa kali untuk memahami apa yang terjadi di sekitarnya. Di sini saya mencoba melepaskan diri dari kerumitan ini dan menceritakan semuanya secara sederhana, terstruktur, singkat, dan tanpa menjelaskan hal-hal yang rumit, misalnya, karakter apa yang mungkin terkandung dalam respons layanan. Tidak seperti RFC, setelah membaca ini sekali, Anda dapat mengetahui semuanya. Saya harap artikel ini bermanfaat dan menghemat waktu ketika memilih solusi untuk mengimplementasikan layanan otentikasi, atau mungkin akan membuat seseorang memikirkan kebutuhannya.
Apa itu OAuth2.0?
Kami memutuskan untuk mulai mengembangkan Auth baru dengan memeriksa protokol dan teknologi yang tersedia. Standar otorisasi yang paling umum adalah kerangka kerja otorisasi OAuth2.0.
Standar tersebut diadopsi pada tahun 2012, dan selama 8 tahun protokol tersebut telah diubah dan ditambah. Ada begitu banyak RFC sehingga penulis protokol asli memutuskan untuk menulis OAuth 2.1, yang akan menggabungkan semua perubahan saat ini ke OAuth 2.0 dalam satu dokumen. Saat dia di tahap draft .
Versi OAuth saat ini dijelaskan di RFC 6749 . Kami akan menganalisisnya.
OAuth 2.0 adalah kerangka kerja otorisasi.
Ini menjelaskan bagaimana komunikasi antar layanan harus dilaksanakan untuk memastikan otorisasi yang aman. Banyak nuansa yang dijelaskan dengan cukup detail, misalnya, alur interaksi node satu sama lain, tetapi beberapa bergantung pada implementasi tertentu.
Fitur:
- Memisahkan entitas pengguna dan aplikasi yang meminta akses . Berkat pemisahan ini, kami dapat mengelola hak aplikasi secara terpisah dari hak pengguna.
- Alih-alih login dan kata sandi biasa, yang memiliki serangkaian hak dan masa pakai tertentu, kami mendapatkan akses ke sumber daya menggunakan string - token yang dibuat secara acak .
- Anda dapat mengeluarkan hak seakurat mungkin , berdasarkan keinginan Anda sendiri, dan bukan pada serangkaian hak yang telah ditentukan sebelumnya.
Mari kita lihat lebih dekat fitur-fiturnya.
Peran
OAuth 2.0 mendefinisikan empat peran:
- Pemilik sumber daya adalah entitas yang memiliki hak akses ke sumber daya yang dilindungi. Suatu entitas dapat menjadi pengguna akhir atau beberapa jenis sistem. Sumber daya yang dilindungi adalah titik akhir HTTP, yang bisa berupa apa saja: Titik akhir API, file di CDN, layanan web.
- Server sumber daya - server yang menyimpan sumber daya yang dilindungi yang aksesnya dimiliki oleh pemilik sumber daya.
- Klien . Ini adalah aplikasi yang meminta akses ke sumber daya yang dilindungi atas nama pemilik sumber daya dan dengan izinnya - dengan otorisasi.
- Server otorisasi - server yang mengeluarkan token kepada klien untuk mengakses sumber daya yang dilindungi setelah otorisasi yang berhasil dari pemilik sumber daya.
Setiap peserta dalam interaksi dapat menggabungkan beberapa peran. Misalnya, klien dapat menjadi pemilik sumber daya pada saat yang sama dan meminta akses ke sumber daya mereka sendiri. Mari pertimbangkan skema interaksi lebih lanjut.
Penting: klien harus terdaftar di layanan sebelumnya. Bagaimana cara melakukannya?
Pendaftaran klien
Anda memilih metode pendaftaran klien, misalnya, penemuan manual atau layanan, bergantung pada
Redirection URI - alamat tujuan pengiriman pemilik sumber daya setelah otorisasi berhasil. Selain otorisasi, alamat tersebut digunakan untuk mengonfirmasi bahwa layanan yang mengajukan otorisasi adalah yang diklaimnya.
Jenis klien - jenis klien yang menentukan bagaimana Anda berinteraksi dengannya. Jenis klien ditentukan oleh kemampuannya untuk menyimpan kredensial dengan aman untuk otorisasi - token. Oleh karena itu, hanya ada 2 jenis klien:
- Confidential — , . , web-, backend.
- Public — . , , .
Token di OAuth 2.0 adalah string yang tidak transparan bagi klien. Biasanya string terlihat seperti dibuat secara acak - formatnya tidak penting bagi klien. Token adalah kunci untuk mengakses sesuatu, misalnya, ke sumber daya yang dilindungi (token akses) atau ke token baru (segarkan Token).
Setiap token memiliki masa hidupnya sendiri . Tetapi token penyegaran harus memiliki lebih banyak, karena itu digunakan untuk mendapatkan token akses. Misalnya, jika masa pakai token akses sekitar satu jam, token penyegaran dapat dibiarkan aktif selama seminggu penuh.
Segarkan token bersifat opsional dan hanya tersedia untuk klien rahasia... Dengan menggunakan token opsional, dalam beberapa implementasi masa pakai token akses dibuat sangat lama, dan token penyegaran tidak digunakan sama sekali, agar tidak repot dengan pembaruan. Tapi ini tidak aman. Jika token akses telah disusupi, itu dapat diatur ulang dan layanan akan menerima token Akses baru menggunakan token penyegaran. Jika tidak ada token penyegaran, Anda harus melalui proses otorisasi lagi.
Token akses diberikan sekumpulan hak akses tertentu, yang diberikan kepada klien selama otorisasi. Mari kita lihat seperti apa tampilan izin di OAuth 2.0.
Hak akses
Hak akses diberikan kepada klien sebagai ruang lingkup. Scope adalah parameter yang terdiri dari string yang dipisahkan spasi - token-scope.
Setiap token cakupan mewakili hak khusus yang diberikan kepada klien. Misalnya, token cakupan
doc_read dapat memberikan akses baca ke dokumen di server sumber daya, dan employee akses ke fungsionalitas aplikasi hanya untuk karyawan perusahaan. Ruang lingkup akhir akan terlihat seperti ini: email doc_read employee.
Di OAuth 2.0, kami membuat token cakupan sendiri, menyesuaikannya agar sesuai dengan kebutuhan kami. Nama token cakupan hanya dibatasi oleh fantasi dan dua karakter ASCII -
"dan \.
Pada tahap pendaftaran klien, dalam pengaturan layanan otorisasi, klien diberi cakupan standar secara default. Tetapi klien dapat meminta dari server otorisasi lingkup selain yang standar. Bergantung pada kebijakan di server otorisasi dan pilihan pemilik sumber daya, cakupan yang dihasilkan mungkin terlihat sangat berbeda. Di masa mendatang, setelah memberi otorisasi pada klien, pemilik sumber daya dapat mengambil beberapa hak tanpa memberi otorisasi ulang pada layanan, tetapi untuk mengeluarkan izin tambahan, otorisasi ulang klien akan diperlukan.
Abstrak OAuth 2.0. Alur menggunakan token Access
Kami melihat peran, melihat jenis token, dan juga seperti apa cakupannya. Mari kita lihat aliran penyediaan akses ke layanan.
Di bawah ini adalah diagram abstrak (atau aliran) interaksi antar peserta. Semua langkah dalam diagram ini dilakukan secara ketat dari atas ke bawah. Mari kita analisis lebih detail.
- Klien mengirimkan permintaan untuk mengakses pemilik sumber daya yang diperlukan.
- Pemilik sumber daya memberikan kembali kepada klien sebuah pemberian otorisasi, yang mengonfirmasi identitas pemilik sumber daya dan haknya atas sumber daya yang klien minta aksesnya. Bergantung pada alirannya, ini bisa berupa token atau kredensial.
- Klien mengirimkan hibah otorisasi yang diperoleh pada langkah sebelumnya ke server otorisasi, mengharapkan token Akses darinya untuk mengakses sumber daya yang dilindungi.
- Server otorisasi memastikan bahwa pemberian otorisasi valid, dan kemudian mengirimkan token akses kembali ke klien.
- Setelah menerima token akses, klien meminta sumber daya yang dilindungi dari server sumber daya.
- Server sumber daya memastikan bahwa token akses sudah benar, dan kemudian memberikan akses ke sumber daya yang dilindungi.
Klien menerima persetujuan dari pemilik sumber daya, atas dasar itu dia diberikan akses ke sumber daya. Itu mudah. Akankah semudah kita menambahkan token penyegaran ke skema ini?
Abstrak OAuth 2.0. Alur menggunakan Segarkan token
Langkah pertama dan kedua dihilangkan dari diagram ini - langkah tersebut tidak berbeda dengan diagram alir abstrak di atas.
Skema lebih detail:
- Klien datang dengan pemberian otorisasi ke server otorisasi dan meminta untuk memberinya token akses dan token penyegaran.
- Authorization server , authorization grant access token refresh token.
- Client access token , — invalid token error.
- , authorization server refresh token access token .
- access token, refresh token, refresh token.
grant?
Grant adalah data yang mewakili otorisasi klien yang berhasil oleh pemilik sumber daya, digunakan oleh klien untuk mendapatkan token akses.
Misalnya, saat kami mengautentikasi dengan Google di suatu tempat, pemberitahuan muncul di depan mata kami. Dikatakan bahwa layanan ini dan itu ingin mengakses data tentang Anda atau sumber daya Anda (token cakupan yang diminta ditampilkan). Pemberitahuan ini disebut "Layar Persetujuan".
Pada saat kita mengklik "OK", hibah yang sama masuk ke database: data dicatat bahwa pengguna telah memberikan akses ini dan itu ke layanan ini dan itu. Klien menerima semacam pengenal otentikasi yang berhasil, seperti string, yang terkait dengan data dalam database.
Ada 4 + 1 cara untuk mendapatkan hibah - jenis hibah:
- Authorization code — confedencial — web-.
- Client credentials — confedential , , .
- Implicit — public-, redirection URI (, ), authorization code grant PKCE (Proof Key for Code Exchange — , , token , . — RFC 7636).
- Kredensial sandi pemilik sumber daya . Dalam keamanan OAuth 2.0 RFC 6819 , jenis hibah ini dianggap tidak dapat diandalkan. Jika sebelumnya diizinkan untuk digunakan hanya untuk migrasi layanan ke OAuth 2.0, saat ini itu tidak diizinkan untuk digunakan sama sekali.
- Otorisasi perangkat (ditambahkan di RFC 8628) - digunakan untuk memberi otorisasi perangkat yang mungkin tidak memiliki browser web, tetapi dapat bekerja melalui Internet. Misalnya, ini adalah aplikasi konsol, perangkat pintar, atau Smart TV.
Hanya kode otorisasi (dengan PKCE), kredensial klien , dan pemberian otorisasi perangkat yang dapat dianggap relevan , tetapi kami akan mempertimbangkan semuanya. Kami akan mempertimbangkan hibah untuk meningkatkan kompleksitas pemahaman.
Client credentials grant flow
Ini memiliki aliran paling sederhana, mengingatkan pada otorisasi reguler pada layanan apa pun. Ini dilakukan dengan menggunakan kredensial klien, yang merupakan id klien dan rahasia klien - analog dari login dan kata sandi untuk pengguna. Karena otentikasi memerlukan rahasia klien yang harus disimpan dengan tepat, hanya klien rahasia yang dapat menggunakan alur ini.
Skemanya sederhana: klien diautentikasi di server otorisasi dengan meneruskan id klien dan rahasia klien. Sebagai tanggapan, ia menerima token akses, yang dengannya ia sudah dapat mengakses layanan yang diperlukan.
Alur ini diperlukan saat klien mencoba mengakses sumber dayanya sendiri atau sumber daya yang sebelumnya telah disetujui dengan server otorisasi. Misalnya, layanan A perlu pergi ke layanan B dari waktu ke waktu dan memperbarui data di sana tentang jumlah restoran pizza di jaringan.
Alur kredensial sandi pemilik sumber daya
Menurut rekomendasi keamanan saat ini yang diuraikan dalam RFC ini, aliran ini tidak disarankan untuk digunakan sama sekali karena masalah keamanan yang jelas.
Dalam ilustrasi aliran ini, ada dua Klien, dan secara teori harus ada Klien dan Server Otorisasi.
Pemilik sumber daya mentransfer nama pengguna dan kata sandinya ke klien, misalnya, melalui formulir di klien. Klien, pada gilirannya, menggunakannya untuk mendapatkan token akses (dan, secara opsional, token penyegaran).
Ada masalah disini. Pemilik sumber daya hanya mengambil dan memberikan dalam bentuk yang jelas nama pengguna dan kata sandinya kepada klien, yang tidak aman. Awalnya dibuat hanya untuk klien yang Anda percayai atau mereka yang merupakan bagian dari sistem operasi. Kemudian, hanya diizinkan untuk migrasi dari login dan autentikasi sandi ke OAuth 2.0. Pedoman keselamatan saat ini melarang penggunaannya.
Kode otorisasi
Aliran paling umum saat ini. Sebagian besar digunakan untuk klien rahasia, tetapi dengan diperkenalkannya validasi tambahan dengan PKCE, ini juga dapat digunakan untuk klien publik.
Dalam aliran ini, interaksi antara klien dan pemilik sumber daya berjalan melalui agen pengguna (browser). Agen pengguna memiliki satu persyaratan: ia harus dapat bekerja dengan pengalihan HTTP. Tanpa ini, pemilik sumber daya tidak akan bisa masuk ke server otorisasi dan kembali dengan hibah.
Aliran ini lebih rumit dari yang sebelumnya, jadi kami akan menganalisisnya selangkah demi selangkah. Sebagai permulaan, mari kita bayangkan bahwa kita adalah pemilik sumber daya dan membuka halaman layanan pembelajaran online yang ingin menyimpan hasil pembelajaran ke cloud kita. Dia perlu mendapatkan akses ke sumber daya kita, misalnya, direktori tertentu di awan. Kami mengklik "Masuk" dan perjalanan melalui alur pemberian kode Otorisasi dimulai:
- Pada langkah pertama, klien mengalihkan pemilik sumber daya menggunakan agen pengguna ke halaman otentikasi server otorisasi. Di URI, ini menentukan ID klien dan URI pengalihan. URI pengalihan digunakan untuk memahami tempat mengembalikan pemilik sumber daya setelah otorisasi berhasil (pemilik sumber daya akan memberikan izin ke cakupan yang diminta oleh klien).
- user-agent, resource owner .
- Resource owner , consent screen .
- Resource owner user-agent URI, redirection URI. query- authorization code — , , resource owner .
- authorization code , access token ( refresh token, ).
- authorization code, , access token ( refresh token). .
Jika kita membayangkan kita menggantikan pemilik sumber daya, maka kita hanya melihat pengalihan ke server otorisasi, mengautentikasi, mengonfirmasi akses ke layar Persetujuan dan mengirim kita ke layanan yang sudah berjalan. Misalnya, kami melewati ini berkali-kali saat kami membuka layanan dengan akun Google, Facebook, atau Apple.
Aliran berikutnya dibangun di atas ini.
Hibah implisit
Ini adalah pengoptimalan alur pemberian kode Otorisasi untuk klien publik yang mengetahui cara bekerja dengan URI pengalihan. Misalnya, untuk aplikasi browser JavaScript, atau aplikasi seluler. Persyaratan untuk agen pengguna, yang berinteraksi dengan klien dan pemilik sumber daya, tetap ada: ia harus dapat bekerja dengan pengalihan HTTP.
Ada perbedaan utama antara kode otorisasi dan implisit: alih-alih menerima kode otorisasi dan token akses di dalamnya, kami segera menerima token akses setelah otorisasi yang berhasil dari pemilik sumber daya. Selain itu, rahasia klien tidak digunakan di sini untuk alasan keamanan - aplikasi dapat dibongkar dan diambil kembali. Keaslian hanya diperiksa oleh URI pengalihan.
Banyak langkah dari diagram ini mirip dengan langkah-langkah dari kode otorisasi, tetapi saya juga mengusulkan untuk menganalisisnya secara mendetail. Bayangkan aplikasi browser ingin menyimpan pengaturannya di repositori Git kita. Kami mengklik "Masuk ke GitHub" dan pada tahap ini aliran implisit dimulai:
- Klien menggunakan agen-pengguna dan pengalihan HTTP untuk mengarahkan pemilik sumber daya ke server otorisasi. Dalam parameter permintaan, ini meneruskan ID klien dan URI pengalihan yang diperlukan untuk mengautentikasi klien, lalu mengembalikan pemilik sumber daya kembali.
- Pemilik sumber daya diautentikasi dengan berkomunikasi melalui agen pengguna dengan server otorisasi. Pada saat yang sama, ini mengkonfirmasikan penerbitan hibah kepada klien, dengan ID klien siapa dia datang.
- grant ( «allow» consent screen), user-agent resource owner redirection URI. , URI fragment access token (URI fragment — , URI ‘#’).
- user-agent. User-agent redirection URI web-, access token . , , , CDN.
- Web- web- ( ), redirection URI, , .
- User-agent , , web-hosted client resource, access token.
- Agen pengguna token akses yang dihasilkan cukup mentransfer ke klien.
Ini adalah aliran yang kompleks. Ini memiliki sedikit kegunaan dalam skenario dunia nyata. Tetapi masih dapat ditemukan di proyek lama.
Otorisasi perangkat (RFC 8628)
Dari 2012 hingga 2019, banyak perangkat pintar muncul yang tidak nyaman untuk masuk. Misalnya, tidak nyaman untuk memasukkan nama pengguna dan sandi yang rumit di TV setiap kali Anda membuka sumber daya. Ini tidak mungkin dilakukan pada beberapa perangkat, seperti OS server tanpa antarmuka grafis. Pada Agustus 2019, aliran ini muncul hanya untuk skenario semacam itu.
Setidaknya ada 3 persyaratan untuk perangkat agar dapat bekerja dengan Aliran pemberian otorisasi Perangkat menjadi mungkin:
- Perangkat harus dapat membuat permintaan HTTPS keluar.
- Perangkat harus dapat menampilkan URI dan ID kepada pengguna.
- Setiap perangkat yang diotorisasi adalah milik pemilik sumber daya, yang, agar otorisasi berhasil, harus memiliki perangkat lain dengan browser untuk membuka URI yang ditentukan dan memasukkan kode yang ditentukan.
Mungkin skema tersebut tampak rumit karena banyaknya anak panah. Mari kita analisis langkah demi langkah, saat kita mengurai alur kompleks sebelumnya.
Katakanlah kita mencoba masuk ke layanan web menggunakan TV. Kami melihat tombol "Masuk sebagai perangkat" dan klik. Pada saat ini, aliran Perangkat kami dimulai:
- TV membuat permintaan ke server otorisasi, memberikan ID kliennya.
- Server otorisasi memverifikasi bahwa klien tersebut terdaftar dan memiliki jenis hibah yang sesuai.
- , Authorization server device code, user code verification URI. Device code — , .
- user code verification URI — resource owner. Redirection URI , QR- — .
- , user code verification URI, .
- resource owner. verification URI, user code, , scope . resource owner .
- Selama ini, perangkat (poin 3) melakukan polling ke server otorisasi tentang keberhasilannya. Perangkat sekali lagi pergi ke server otorisasi dengan kode perangkat dan ID klien dengan harapan otorisasi telah berlalu kali ini.
- Kali ini, ketika pemilik sumber daya telah mengonfirmasi transfer hak yang diperlukan untuk perangkat, server otorisasi mengembalikan token akses sebagai tanggapan atas permintaan (jika disediakan oleh pengaturan server dan token penyegaran). Dan dengan bantuan token, perangkat sudah dapat terus bekerja dengan sumber daya.
Terlepas dari kerumitan yang terlihat dengan panah, aliran ini juga cukup sederhana. Jika Anda perlu berinteraksi dengan perangkat (dan kami memiliki banyak perangkat: pelacak, kasir, etalase, dan perangkat lain), Anda harus menggunakan alur ini.
Bukan keluaran
Dalam artikel ini, saya telah menghilangkan banyak detail untuk membicarakan hal-hal terpenting dengan cara yang paling sederhana dan mudah diakses. Misalnya, jenis permintaan, bagaimana dan dalam bentuk apa untuk melewati parameter, karakter apa yang diperbolehkan sebagai nilai untuk itu.
Jika Anda ingin mendalami topik lebih detail, maka saya rekomendasikan di RFC 6749 (untuk OAuth 2.0) dan RFC 8628 (untuk Device Flow). Anda juga dapat memeriksa sumber daya OAuth untuk RFC terbaru .
Jika artikel itu berguna dan Anda ingin detail lebih lanjut - tulis di komentar, dan di artikel berikutnya saya akan berbicara tentang PKCE, protokol otentikasi OpenID Connect 1.0, implementasi server otentikasi kami dan banyak lagi.
Link yang berguna: