Bagian 4.2 dari draft protokol OAuth 2.0 menunjukkan bahwa server otorisasi dapat mengembalikan keduanya access_token(yang digunakan untuk mengotentikasi diri sendiri dengan sumber daya) maupun refresh_token, yang digunakan murni untuk membuat yang baru access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Mengapa keduanya? Mengapa tidak membuat yang access_tokenterakhir selama refresh_tokendan tidak memiliki refresh_token?
Jawaban:
Gagasan penyegaran token adalah bahwa jika token akses dikompromikan, karena berumur pendek, penyerang memiliki jendela terbatas untuk menyalahgunakannya.
Segarkan token, jika dikompromikan, tidak berguna karena penyerang memerlukan id dan rahasia klien selain token penyegaran untuk mendapatkan token akses.
Karena itu , karena setiap panggilan ke server otorisasi dan server sumber daya dilakukan melalui SSL - termasuk id dan rahasia klien asli ketika mereka meminta token akses / penyegaran - saya tidak yakin bagaimana token akses itu lagi " kompromi "dari token penyegaran yang lama dan kombinasi clientid / rahasia.
Ini tentu saja berbeda dengan implementasi di mana Anda tidak mengontrol server sumber daya dan otorisasi.
Berikut ini adalah utas bagus yang berbicara tentang penggunaan token penyegaran: OAuth Archives .
Kutipan dari atas, berbicara tentang tujuan keamanan token penyegaran:
Segarkan token ... mengurangi risiko kebocoran access_token berumur panjang (parameter kueri dalam file log pada server sumber daya tidak aman, aplikasi server sumber daya beta atau kode buruk, klien JS SDK di situs non https yang menempatkan access_token dalam sebuah cookie, dll)
Tautan ke diskusi, yang disediakan oleh Catchdave, memiliki titik valid lain (asli, tautan mati) yang dibuat oleh Dick Hardt, yang saya yakin layak disebutkan di sini selain apa yang telah ditulis di atas:
Ingatan saya tentang token penyegaran adalah untuk keamanan dan pencabutan. <...>
pencabutan: jika token akses mandiri, otorisasi dapat dicabut dengan tidak mengeluarkan token akses baru. Sumber daya tidak perlu meminta server otorisasi untuk melihat apakah token akses itu valid. Ini menyederhanakan validasi token akses dan membuatnya lebih mudah untuk mengukur dan mendukung beberapa server otorisasi. Ada jendela waktu ketika token akses valid, tetapi otorisasi dicabut.
Memang, dalam situasi di mana Server Sumber Daya dan Server Otorisasi adalah entitas yang sama, dan di mana koneksi antara pengguna dan salah satu dari mereka (biasanya) sama-sama aman, tidak ada banyak akal untuk menjaga token penyegaran terpisah dari token akses.
Meskipun, seperti yang disebutkan dalam kutipan, peran token penyegaran lainnya adalah untuk memastikan token akses dapat dicabut kapan saja oleh Pengguna (misalnya, melalui antarmuka web di profil mereka) sambil menjaga agar sistem dapat diskalakan pada saat yang sama. .
Secara umum, token dapat berupa pengidentifikasi acak yang menunjuk ke catatan spesifik dalam database Server, atau mereka dapat berisi semua informasi dalam dirinya sendiri (tentu saja, informasi ini harus ditandatangani, dengan MAC , misalnya).
Bagaimana sistem dengan token akses yang berumur panjang harus bekerja
Server memungkinkan Klien untuk mendapatkan akses ke data Pengguna dalam set lingkup yang ditentukan sebelumnya dengan menerbitkan token. Karena kami ingin agar token tetap dapat dibatalkan, kita harus menyimpan dalam basis data token bersama dengan bendera "dicabut" sedang disetel atau tidak disetel (jika tidak, bagaimana Anda melakukannya dengan token yang berdiri sendiri?) Database dapat berisi sebanyak len(users) x len(registered clients) x len(scopes combination)catatan . Setiap permintaan API maka harus mengenai database. Meskipun cukup sepele untuk membuat query ke database seperti itu yang melakukan O (1), satu-satunya titik kegagalan itu sendiri dapat berdampak negatif pada skalabilitas dan kinerja sistem.
Bagaimana sistem dengan token refresh yang berumur panjang dan token akses yang berumur pendek harus bekerja
Di sini kami mengeluarkan dua kunci: token penyegaran acak dengan catatan terkait dalam database, dan token akses mandiri yang ditandatangani, yang berisi antara lain bidang cap waktu kedaluwarsa.
Karena token aksesnya mandiri, kami tidak perlu menekan database sama sekali untuk memeriksa validitasnya. Yang harus kita lakukan adalah memecahkan kode token dan memvalidasi tanda tangan dan cap waktu.
Meskipun demikian, kami masih harus menyimpan basis data token penyegaran, tetapi jumlah permintaan ke basis data ini secara umum ditentukan oleh umur token akses (semakin lama umur, semakin rendah laju akses).
Untuk mencabut akses Klien dari Pengguna tertentu, kami harus menandai token penyegaran terkait sebagai "dicabut" (atau menghapusnya sepenuhnya) dan berhenti mengeluarkan token akses baru. Namun jelas bahwa ada jendela di mana token refresh telah dicabut, tetapi token aksesnya mungkin masih valid.
Pengorbanan
Refresh token sebagian menghilangkan SPoF (Titik Kegagalan Tunggal) dari database Access Token, namun mereka memiliki beberapa kelemahan yang jelas.
Jendela". Kerangka waktu antara peristiwa "pengguna mencabut akses" dan "akses dijamin akan dicabut".
Komplikasi dari logika Klien.
tanpa token penyegaran
dengan token penyegaran
Saya harap jawaban ini masuk akal dan membantu seseorang untuk membuat keputusan yang lebih bijaksana. Saya ingin mencatat juga bahwa beberapa penyedia OAuth2 terkenal, termasuk github dan foursquare mengadopsi protokol tanpa token penyegaran, dan sepertinya senang dengan itu.
Terlepas dari semua jawaban hebat di atas, saya sebagai mahasiswa master dan programmer keamanan yang sebelumnya bekerja di eBay ketika saya melihat perlindungan pembeli dan penipuan, dapat mengatakan untuk memisahkan token akses dan token penyegaran memiliki keseimbangan terbaik antara melecehkan pengguna yang sering menggunakan nama pengguna. / masukan kata sandi dan tetap memegang otoritas untuk mencabut akses ke potensi penyalahgunaan layanan Anda.
Pikirkan skenario seperti ini. Anda mengeluarkan pengguna token akses 3600 detik dan menyegarkan token lebih lama dari satu hari.
Pengguna adalah pengguna yang baik , ia ada di rumah dan mendapatkan on / off belanja situs web Anda dan mencari di iPhone-nya. Alamat IP-nya tidak berubah dan memiliki beban yang sangat rendah di server Anda. Seperti 3-5 permintaan halaman setiap menit. Saat 3600 detik pada token aksesnya selesai, ia memerlukan yang baru dengan token penyegaran. Kami, di sisi server, memeriksa riwayat aktivitas dan alamat IP-nya, berpikir ia adalah manusia dan berperilaku sendiri. Kami memberinya token akses baru untuk terus menggunakan layanan kami. Pengguna tidak perlu memasukkan lagi nama pengguna / kata sandi sampai ia mencapai satu hari masa hidup token penyegaran itu sendiri.
Pengguna adalah pengguna yang ceroboh . Dia tinggal di New York, AS dan menutup program virusnya dan diretas oleh peretas di Polandia . Ketika peretas mendapatkan token akses dan menyegarkan token, ia mencoba menyamar sebagai pengguna dan menggunakan layanan kami. Tetapi setelah token akses singkat berakhir, ketika hacker mencoba untuk menyegarkan token akses, kami, di server, telah melihat perubahan IP dramatis dalam riwayat perilaku pengguna (hei, orang ini login di AS dan sekarang me-refresh akses di Polandia setelah hanya 3600-an ???). Kami menghentikan proses penyegaran, membatalkan token penyegaran itu sendiri dan meminta untuk memasukkan nama pengguna / kata sandi lagi.
Pengguna adalah pengguna jahat . Dia dimaksudkan untuk menyalahgunakan layanan kami dengan menelepon 1000 kali API kami setiap menit menggunakan robot. Dia bisa melakukannya hingga 3600 detik kemudian, ketika dia mencoba menyegarkan token akses, kami memperhatikan perilakunya dan berpikir dia mungkin bukan manusia. Kami menolak dan menghentikan proses penyegaran dan memintanya untuk memasukkan nama pengguna / kata sandi lagi. Ini berpotensi merusak aliran otomatis robotnya. Setidaknya membuatnya tidak nyaman.
Anda dapat melihat token penyegaran telah bertindak dengan sempurna ketika kami mencoba menyeimbangkan pekerjaan kami, pengalaman pengguna, dan potensi risiko token yang dicuri. Anjing jaga Anda di sisi server dapat memeriksa lebih dari perubahan IP, frekuensi panggilan api untuk menentukan apakah pengguna akan menjadi pengguna yang baik atau tidak.
Kata lain adalah Anda juga dapat mencoba membatasi kontrol kerusakan token / penyalahgunaan layanan yang dicuri dengan menerapkan pada setiap api panggil anjing penjaga IP dasar atau tindakan lainnya. Tapi ini mahal karena Anda harus membaca dan menulis catatan tentang pengguna dan akan memperlambat respons server Anda.
Tidak satu pun dari jawaban ini sampai ke inti alasan token penyegaran ada. Jelas, Anda selalu bisa mendapatkan pasangan akses-token / refresh-token baru dengan mengirimkan kredensial klien Anda ke server auth - itulah cara Anda mendapatkannya di tempat pertama.
Jadi tujuan utama token penyegaran adalah untuk membatasi penggunaan kredensial klien yang dikirim melalui kawat ke layanan auth. Semakin pendek ttl dari token akses, semakin sering kredensial klien harus digunakan untuk mendapatkan token akses baru, dan oleh karena itu semakin banyak peluang yang dimiliki penyerang untuk mengkompromikan kredensial klien (walaupun ini mungkin akan sangat sulit jika enkripsi asimetris sedang digunakan untuk mengirim mereka). Jadi, jika Anda memiliki token penyegaran sekali pakai, Anda dapat membuat ttl token akses menjadi kecil secara sewenang-wenang tanpa mengorbankan kredensial klien.
Untuk menjernihkan kebingungan Anda harus memahami peran rahasia klien dan kata sandi pengguna , yang sangat berbeda.
The client adalah sebuah aplikasi / website / program / ..., didukung oleh server, yang ingin mengotentikasi sebuah pengguna dengan menggunakan layanan otentikasi pihak ketiga. Rahasia klien adalah string (acak) yang diketahui oleh klien ini dan server otentikasi. Menggunakan rahasia ini klien dapat mengidentifikasi dirinya dengan server otentikasi, menerima otorisasi untuk meminta token akses.
Untuk mendapatkan token akses awal dan menyegarkan token, yang diperlukan adalah:
Namun untuk mendapatkan token akses yang diperbarui, klien menggunakan informasi berikut:
Ini dengan jelas menunjukkan perbedaan: ketika menyegarkan, klien menerima otorisasi untuk menyegarkan token akses dengan menggunakan rahasia kliennya, dan dengan demikian dapat mengautentikasi ulang pengguna menggunakan token penyegaran sebagai ganti ID pengguna + kata sandi. Ini secara efektif mencegah pengguna dari harus memasukkan kembali kata sandinya.
Ini juga menunjukkan bahwa kehilangan token penyegaran tidak ada masalah karena ID klien dan rahasia tidak diketahui. Ini juga menunjukkan bahwa menjaga ID klien dan rahasia rahasia klien sangat penting .
Jawaban ini dari Justin Richer melalui daftar email badan standar OAuth 2. Ini diposting dengan seizinnya.
Masa pakai token penyegaran adalah hingga ke server otorisasi (AS) - mereka dapat kedaluwarsa, dicabut, dll. Perbedaan antara token penyegaran dan token akses adalah pemirsa: token penyegaran hanya kembali ke server otorisasi, token akses menuju ke server sumber daya (RS).
Selain itu, hanya mendapatkan token akses tidak berarti pengguna masuk. Bahkan, pengguna mungkin bahkan tidak ada lagi, yang sebenarnya adalah kasus penggunaan yang dimaksudkan dari token penyegaran. Menyegarkan token akses akan memberi Anda akses ke API atas nama pengguna, itu tidak akan memberi tahu Anda jika pengguna di sana.
OpenID Connect tidak hanya memberi Anda informasi pengguna dari token akses, tetapi juga memberi Anda token ID. Ini adalah bagian data terpisah yang diarahkan pada klien itu sendiri, bukan AS atau RS. Di OIDC, Anda hanya harus mempertimbangkan seseorang yang benar-benar "masuk" oleh protokol jika Anda bisa mendapatkan token ID baru. Menyegarkan rasanya tidak cukup.
Untuk informasi lebih lanjut silakan baca http://oauth.net/articles/authentication/
Klien dapat dikompromikan dalam banyak hal. Misalnya ponsel bisa dikloning. Memiliki token akses yang kedaluwarsa berarti bahwa klien dipaksa untuk mengautentikasi ulang ke server otorisasi. Selama otentikasi ulang, server otorisasi dapat memeriksa karakteristik lain (TKI melakukan manajemen akses adaptif).
Refresh token memungkinkan klien hanya melakukan otentikasi ulang, di mana ketika otorisasi ulang memaksa dialog dengan pengguna yang telah banyak diindikasikan, mereka lebih suka tidak melakukannya.
Segarkan token cocok pada dasarnya di tempat yang sama di mana situs web biasa mungkin memilih untuk mengautentikasi ulang pengguna secara berkala setelah sekitar satu jam atau lebih (misalnya situs perbankan). Ini tidak banyak digunakan saat ini karena sebagian besar situs web sosial tidak mengautentikasi ulang pengguna web, jadi mengapa mereka mengautentikasi ulang klien?
Mengapa tidak membuat access_token bertahan selama refresh_token dan tidak memiliki refresh_token?
Selain jawaban bagus yang diberikan orang lain, ada alasan lain mengapa menggunakan token penyegaran dan hubungannya dengan klaim.
Setiap token berisi klaim yang dapat mencakup apa pun dari nama pengguna, peran mereka atau penyedia yang membuat klaim. Saat token di-refresh, klaim ini diperbarui.
Jika kita menyegarkan token lebih sering, kita jelas memberikan tekanan lebih pada layanan identitas kita namun kita mendapatkan klaim yang lebih akurat dan terbaru.
Untuk lebih menyederhanakan jawaban BT: Gunakan token penyegaran ketika Anda biasanya tidak ingin pengguna harus mengetikkan kredensial lagi, tetapi masih ingin kekuatan untuk dapat mencabut izin (dengan mencabut token penyegaran)
Anda tidak dapat mencabut token akses, hanya token refresh.
Jawaban ini telah disatukan oleh bantuan dua pengembang senior (John Brayton dan David Jennes).
Alasan utama untuk menggunakan token penyegaran adalah untuk mengurangi permukaan serangan.
Misalkan tidak ada kunci penyegaran dan mari kita lihat contoh ini:
Sebuah bangunan memiliki 80 pintu. Semua pintu dibuka dengan kunci yang sama. Kuncinya berubah setiap 30 menit. Di akhir 30 menit saya harus memberikan kunci lama kepada pembuat kunci dan mendapatkan kunci baru.
Jika saya peretas dan mendapatkan kunci Anda, maka pada akhir 30 menit, saya akan mengirimkannya ke pembuat kunci dan mendapatkan kunci baru. Saya akan dapat terus membuka semua pintu terlepas dari perubahan kunci.
Pertanyaan: Selama 30 menit, berapa banyak peluang peretasan yang saya miliki terhadap kunci? Saya memiliki 80 peluang peretasan, setiap kali Anda menggunakan kunci (anggap ini sebagai membuat permintaan jaringan dan melewati token akses untuk mengidentifikasi diri Anda). Jadi itu permukaan serangan 80X.
Sekarang mari kita lihat contoh yang sama tetapi kali ini mari kita asumsikan ada kunci penyegaran.
Sebuah bangunan memiliki 80 pintu. Semua pintu dibuka dengan kunci yang sama. Kuncinya berubah setiap 30 menit. Untuk mendapatkan kunci baru, saya tidak bisa melewati token akses lama. Saya hanya harus melewati kunci penyegaran.
Jika saya peretas dan mendapatkan kunci Anda, saya dapat menggunakannya selama 30 menit, tetapi pada akhir 30 menit mengirimkannya ke pembuat kunci tidak memiliki nilai. Jika saya melakukannya, maka pembuat kunci hanya akan mengatakan token penyegaran yang buruk ini. Untuk dapat memperpanjang hack saya, saya harus meretas kurir ke pembuat kunci. Kurir memiliki kunci berbeda (anggap ini sebagai token penyegaran).
Pertanyaan: Selama 30 menit, berapa banyak peluang peretasan yang saya miliki terhadap kunci refresh? 80? Tidak. Saya hanya punya 1 kesempatan meretas. Selama ini kurir berkomunikasi dengan pembuat kunci. Jadi itu permukaan serangan 1X. Saya memang memiliki 80 peluang peretasan melawan kunci, tetapi mereka tidak baik setelah 30 menit.
Server akan memverifikasi token akses berdasarkan kredensial dan penandatanganan (biasanya) JWT.
Bocor token akses buruk, tetapi begitu kadaluarsa tidak lagi berguna bagi penyerang. Kebocoran tanda penyegaran jauh lebih buruk, tetapi agaknya kemungkinan itu kecil. (Saya pikir ada ruang untuk mempertanyakan apakah kemungkinan token bocor jauh lebih rendah daripada kebocoran token akses, tapi itulah idenya.)
Poinnya adalah bahwa token akses ditambahkan ke setiap permintaan yang Anda buat, sedangkan token penyegaran hanya digunakan selama aliran penyegaran. Jadi, lebih sedikit peluang MITM melihat token tersebut.
Frekuensi membantu penyerang. Heartbleed - kelemahan keamanan potensial seperti di SSL, kelemahan keamanan potensial di klien, dan kelemahan keamanan potensial di server semua memungkinkan kebocoran.
Selain itu, jika server otorisasi terpisah dari server aplikasi yang memproses permintaan klien lain, maka server aplikasi tidak akan pernah melihat token penyegaran. Itu hanya akan melihat token akses yang tidak akan hidup lebih lama.
Kompartementalisasi baik untuk keamanan.
Terakhir tetapi tidak kalah penting lihat jawaban yang luar biasa ini
Apa token penyegaran BUKAN tentang?
Kemampuan untuk memperbarui / mencabut tingkat akses melalui token penyegaran adalah produk sampingan dari memilih untuk menggunakan token penyegaran, jika tidak token akses mandiri dapat dicabut atau tingkat aksesnya diubah ketika kedaluwarsa dan pengguna mendapat token baru
Anggap Anda membuat yang access_tokenterakhir sangat lama, dan tidak punya refresh_token, jadi dalam satu hari, peretas mendapatkan ini access_tokendan ia dapat mengakses semua sumber daya yang dilindungi!
Tetapi jika Anda punya refresh_token, access_tokenwaktu hidup pendek, sehingga peretas sulit untuk meretas Anda access_tokenkarena itu akan tidak valid setelah periode waktu yang singkat.
Access_tokenhanya dapat diambil kembali dengan menggunakan tidak hanya refresh_tokentetapi juga oleh client_iddan client_secret, yang tidak dimiliki oleh peretas.
Sementara token penyegaran dipertahankan oleh server Otorisasi. Token akses bersifat mandiri sehingga server sumber daya dapat memverifikasinya tanpa menyimpannya yang menghemat upaya pengambilan jika validasi. Poin lain yang hilang dalam diskusi adalah dari rfc6749 # halaman-55
"Misalnya, server otorisasi dapat menggunakan rotasi token penyegaran di mana token penyegaran baru dikeluarkan dengan setiap respons akses token penyegaran. Token penyegaran sebelumnya tidak valid tetapi dipertahankan oleh server otorisasi. Jika token penyegaran dikompromikan dan selanjutnya digunakan oleh baik penyerang dan klien yang sah, salah satunya akan memberikan token penyegaran yang tidak valid, yang akan memberi tahu server otorisasi pelanggaran tersebut. "
Saya pikir inti dari menggunakan token penyegaran adalah bahwa meskipun penyerang entah bagaimana berhasil mendapatkan penyegaran token, ID klien dan kombinasi rahasia. Dengan panggilan berikutnya untuk mendapatkan token akses baru dari penyerang dapat dilacak jika setiap permintaan untuk penyegaran menghasilkan token akses baru dan penyegaran token.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Mari kita pertimbangkan sebuah sistem di mana setiap pengguna ditautkan ke satu peran atau lebih dan setiap peran ditautkan dengan satu atau lebih hak akses. Informasi ini dapat di-cache untuk kinerja API yang lebih baik. Tetapi kemudian, mungkin ada perubahan dalam konfigurasi pengguna dan peran (misalnya akses baru dapat diberikan atau akses saat ini dapat dicabut) dan ini harus tercermin dalam cache.
Kami dapat menggunakan akses dan menyegarkan token untuk tujuan tersebut. Ketika API dipanggil dengan token akses, server sumber daya memeriksa cache untuk hak akses. JIKA ada hibah akses baru, itu tidak segera tercermin. Setelah token akses kedaluwarsa (katakan dalam 30 menit) dan klien menggunakan token refresh untuk menghasilkan token akses baru, cache dapat diperbarui dengan informasi hak akses hak akses pengguna yang diperbarui dari DB.
Dengan kata lain, kita dapat memindahkan operasi mahal dari setiap panggilan API menggunakan token akses ke acara pembuatan token akses menggunakan token penyegaran.
Pertama, klien mengautentikasi dengan server otorisasi dengan memberikan hibah otorisasi.
Kemudian, klien meminta server sumber daya untuk sumber daya yang dilindungi dengan memberikan token akses.
Server sumber daya memvalidasi token akses dan menyediakan sumber daya yang dilindungi.
Klien membuat permintaan sumber daya yang dilindungi ke server sumber daya dengan memberikan token akses, di mana server sumber daya memvalidasinya dan melayani permintaan, jika valid. Langkah ini terus berulang sampai token akses berakhir.
Jika token akses berakhir, klien mengautentikasi dengan server otorisasi dan meminta token akses baru dengan memberikan token penyegaran. Jika token akses tidak valid, server sumber daya mengirimkan kembali respons kesalahan token yang tidak valid ke klien.
Klien mengautentikasi dengan server otorisasi dengan memberikan token penyegaran.
Server otorisasi kemudian memvalidasi token penyegaran dengan mengotentikasi klien dan mengeluarkan token akses baru, jika valid.
access token + refresh token?