Mengapa OAuth v2 Memiliki Akses dan Refresh Token?


654

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:


463

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)


14
Catchdave benar tetapi saya pikir saya akan menambahkan bahwa hal-hal telah berevolusi sejak balasan awalnya. Penggunaan SSL sekarang opsional (ini mungkin masih diperdebatkan ketika catchdave menjawab). Misalnya, token MAC (saat ini sedang dikembangkan), memberikan kemampuan untuk menandatangani permintaan dengan kunci pribadi sehingga SSL tidak diperlukan. Segarkan token menjadi sangat penting karena Anda ingin memiliki token mac yang berumur pendek.
AlexGad

54
"Segarkan token, jika dikompromikan, tidak berguna karena penyerang memerlukan id dan rahasia klien selain token penyegaran untuk mendapatkan token akses." Tetapi id dan rahasia klien juga disimpan di perangkat, bukan? Jadi penyerang dengan akses ke perangkat bisa mendapatkannya. Lalu mengapa? Di sini, github.com/auth0/lock/wiki/Using-a-Refresh-Token , Ada tertulis bahwa kehilangan token Refresh berarti, ia dapat meminta sebanyak token auth sesuai keinginannya, mungkin tidak ada dalam skenario Google, tetapi bagaimana jika saya menerapkan server oauth2 saya sendiri?
Jamsheed Kamarudeen

42
"Penyerang membutuhkan id klien dan rahasia selain token penyegaran untuk mendapatkan token akses" : lalu apa perbedaan antara menggunakan token penyegaran dan hanya mengundurkan diri?
sp00m

34
Refresh token dapat digunakan oleh pihak ketiga yang dapat memperbarui token akses tanpa sepengetahuan kredensial pengguna.
Marek

27
@KevinWheeler Tidak, ID klien dan rahasia adalah kredensial untuk klien OAuth, bukan pengguna. Ketika berbicara tentang OAuth, "klien" biasanya server (misalnya server web stackoverflow) yang berinteraksi dengan server API sumber daya atau otorisasi (misalnya penyedia autentikasi facebook). Kredensial pengguna hanya diteruskan antara pengguna dan server API OAuth, dan tidak pernah diketahui klien. Rahasia klien hanya diteruskan dari klien ke server API OAuth, dan tidak pernah diketahui pengguna.
Kerinduan mesin

551

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.

  1. Jendela". Kerangka waktu antara peristiwa "pengguna mencabut akses" dan "akses dijamin akan dicabut".

  2. Komplikasi dari logika Klien.

    tanpa token penyegaran

    • kirim permintaan API dengan token akses
    • jika token akses tidak valid, gagal dan minta pengguna untuk mengautentikasi ulang

    dengan token penyegaran

    • kirim permintaan API dengan token akses
    • Jika token akses tidak valid, coba perbarui menggunakan token refresh
    • jika permintaan segarkan berlalu, perbarui token akses dan kirim kembali permintaan API awal
    • Jika permintaan penyegaran gagal, minta pengguna untuk mengautentikasi ulang

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.


4
@RomannImankulov Jika saya memahaminya dengan benar menyegarkan token, kita dapat menyimpan ke db dan menghapusnya kapan saja kita ingin mencabut akses, jadi mengapa tidak menyimpan token akses itu sendiri?
kosnkov

30
@kosnkov versi singkat dari postingan saya adalah, jika Anda menyimpan token akses di database, Anda menekan database pada setiap permintaan ke API Anda (yang mungkin atau mungkin tidak menjadi masalah dalam kasus khusus Anda). Jika Anda menyimpan token penyegaran dan menjaga token akses "mandiri", Anda menekan database hanya ketika klien memutuskan untuk me-refresh token akses.
Roman Imankulov

5
Secara pribadi saya tidak suka pendekatan ini tidak memukul database untuk mendapatkan kinerja jika itu akan membahayakan keamanan (bahkan jika hanya untuk rentang waktu jendela). Seseorang harus dapat segera mencabut access_token jika perlu karena hampir selalu kita berurusan dengan informasi pengguna yang sensitif (jika tidak, kita mungkin tidak akan menggunakan OAuth sejak awal). Saya ingin tahu pendekatan mana yang digunakan perusahaan besar seperti Facebook dan Google.
Tiago

1
Saya tidak sepenuhnya mengerti mengapa kita harus memiliki "jendela terbuka" untuk beberapa waktu. Mengapa kita tidak bisa mengirim permintaan ke server sumber daya untuk tidak menerima token akses untuk pengguna ini? Juga apakah saya benar bahwa Anda tidak dapat memiliki perilaku token penyegaran ketika Anda tidak memiliki rahasia klien untuk menandatangani token? Jadi pada dasarnya Anda tidak dapat menggunakan token penyegaran dari perangkat lunak di perangkat klien js, aplikasi desktop seluler dll.
Igor Čordaš

1
@PSIXO server sumber daya tidak memiliki toko tetap selain database dan mungkin cache lokal. Oleh karena itu, satu-satunya cara ia dapat memeriksa apakah token dicabut adalah dengan memukul database, yang mana seluruh proses ini mencoba untuk menghindari. Mengenai pertanyaan kedua Anda, Anda salah. Jika Anda memiliki token penyegaran, Anda dapat meminta token akses baru.
bernie

199

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.

  1. 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.

  2. 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.

  3. 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.


@laalaguer Apakah Anda memiliki beberapa kebijakan berbutir halus seperti misalnya: Jangan mencabut token ketika alamat IP pengguna diubah (ketika ponsel terputus dari WiFi dan terhubung ke jaringan 3G / 4G)?
svlada

65
Ini adalah beberapa kebijakan dan gagasan hebat, tetapi saya tidak melihat apa pun dalam jawaban Anda yang secara inheren mengharuskan penggunaan token penyegaran. Semua fitur ini dapat diimplementasikan hanya dengan token akses.
Evert

12
@ Sebaliknya, salah satu manfaat menggunakan token akses dan penyegaran adalah bahwa token akses dapat berumur pendek dan karenanya tidak terlalu banyak kompromi keamanan untuk mempercayai mereka tanpa syarat tanpa memeriksa dengan server yang awalnya mengeluarkannya. Ini dapat memungkinkan Anda untuk skala infrastruktur Anda sehingga bagian yang tidak kritis dapat mempercayai informasi yang disimpan dalam token (ditandatangani) tanpa akses langsung ke informasi akun pengguna.
Avi Cherry

7
@ Avi Cherry - Ya, token akses dapat berumur pendek, dan juga dapat di-refresh jika pengguna masih dianggap valid. Tidak memerlukan token penyegaran untuk melakukan itu.
Rick Jolly

10
Saya percaya jawaban ini mengasumsikan bahwa kita tidak pernah ingin server sumber daya untuk melakukan kontrol akses tingkat lanjut sendiri (mis. Memeriksa aktivitas IP terhadap berbagai database, dll), dan sebagai gantinya mereka hanya dapat mengandalkan verifikasi token akses dalam isolasi lengkap. Meskipun ini mungkin jelas pada skala (untuk alasan kinerja) itu jelas tidak jelas untuk semua orang di sini mengingat kebingungan dalam posting dan komentar lain. Ini adalah posting yang bagus dengan informasi yang bagus tetapi saya merasa sangat merindukan poin dari pertanyaan aslinya. Saya merekomendasikan setidaknya membuat asumsi tersebut secara eksplisit.
mentega

72

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.


16
Ini menarik karena dalam kasus Google ketika Anda meminta token penyegaran, Anda juga mengirim id klien dan rahasia klien. Jadi, Anda berkompromi setiap jam.
Rots

1
Alexander, sebenarnya semakin pendek ttl, semakin sering klien harus mendapatkan token akses baru (yang mengharuskan menggunakan kredensial klien). Jadi maksud saya sebenarnya 'lebih pendek' di sana. Saya akan menambahkan catatan untuk menjelaskan.
BT

2
"tujuan tunggal" - tidak mencuci. Membuat TTL dari token akses selama token refresh yang dibayangkan akan mencapai hal yang sama.
Rhubarb

8
Karena standar mengharuskan kredensial klien dikirim bersama dengan token penyegaran, premis dari jawaban ini benar-benar salah. "Karena token penyegaran biasanya merupakan kredensial tahan lama yang digunakan untuk meminta token akses tambahan ... klien HARUS mengautentikasi dengan server otorisasi." Lihat juga komentar oleh @Rots.
Kevin Christopher Henry

8
A) Saya pikir Anda sedang mencampur rahasia klien dan rahasia pengguna. Rahasia klien tidak pernah dikirim dari perangkat pengguna, hanya dari mengakses aplikasi backend ke data yang menyediakan aplikasi backend. B) Server oAuth yang memungkinkan pemberian kata sandi untuk Klien Publik (klien yang tidak bisa merahasiakan klien seperti aplikasi asli atau javascript) juga akan memberikan hibah penyegaran untuk klien publik tersebut, sehingga Anda tidak perlu kirim rahasia klien saat menyegarkan token Anda. C) Token penyegaran memberikan backend "hart-beat" kapan untuk memeriksa validitas pengguna!
Andreas Lundgren

55

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:

  • ID pengguna
  • Kata sandi pengguna
  • ID klien
  • Rahasia klien

Namun untuk mendapatkan token akses yang diperbarui, klien menggunakan informasi berikut:

  • ID klien
  • Rahasia klien
  • Token penyegaran

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 .


1
"Ini juga menunjukkan bahwa kehilangan token penyegaran tidak ada masalah karena ID klien dan rahasia tidak diketahui". Tetapi saya tidak membutuhkannya. Jika saya mendapat token penyegaran maka saya bisa meneruskannya ke server aplikasi Anda. Ia menambahkan client_id dan rahasia dan kemudian meneruskan ketiganya ke layanan OAuth. Apa gunanya?
3DFace

7
Server aplikasi tidak menyediakan cara untuk memasok token penyegaran sendiri, Anda tidak dapat memintanya untuk membuat token otentikasi baru dengan memberikan token penyegaran. Itu memperbarui token autentik itu sendiri ketika dibutuhkan, "di belakang layar".
Adversus

2
Perhatikan bahwa Anda memang membutuhkan rahasia klien untuk mendapatkan token penyegaran sejak awal. Anda mungkin berpikir tentang aliran otentikasi implisit, di mana Anda tidak memerlukan rahasia, tetapi token penyegaran tidak dikeluarkan atau digunakan dalam kasus itu.
Kevin Christopher Henry

@KevinChristopherHenry jenis ini menunjukkan bahwa untuk pengguna akhir hanya masuk ke situs web perusahaan XYZ.com token penyegaran tidak ada artinya untuk mendapatkan token akses baru untuk XYZ.com? Tetapi token penyegaran dapat berupa string yang tidak dapat ditebak - seperti panduan - disimpan dalam tabel yang dapat dilihat dengan sangat cepat. Sedangkan token akses bisa lebih lama dan lebih sulit untuk diindeks dalam database. Jadi penyegaran token BISA disimpan dan memiliki manfaat di sisi pengguna akhir. [walaupun karena pertanyaan ini berbicara tentang oauth2 mungkin ada jawaban tanpa layanan pihak ketiga yang bertindak atas nama seseorang tidak relevan]
Simon_Weaver

mengapa Anda tidak dapat melewati 'ID klien' + 'Rahasia klien' + 'token akses kedaluwarsa' untuk mendapatkan token akses baru?
Sayang

37

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/


Ini sepertinya tentang OpenID Connect dan otentikasi, jadi saya tidak melihat bagaimana ini menjawab pertanyaan, yaitu tentang motivasi untuk memiliki token refresh.
sleske

18

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?


2
"Refresh token memungkinkan klien hanya melakukan otentikasi ulang ..." adalah aspek penting di sini.
James

13

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.


4
Ini akan menjadi praktik buruk yang tidak biasa untuk menempatkan "klaim" seperti itu di token akses. Seperti yang dijelaskan dalam spesifikasi , token akses "biasanya tidak jelas ke klien". Apakah Anda memiliki contoh penyedia OAuth yang melakukan ini?
Kevin Christopher Henry

3
@heymega Ketika peran pengguna diturunkan dari ADMIN ke REGULAR_USER harapan adalah bahwa peran pengguna harus segera dicabut dan tidak ketika akses_token berakhir. Jadi, sepertinya memukul database pada setiap permintaan tidak bisa dihindari.
svlada

@svlada Saya membayangkan itu akan menjadi kasus di mana aplikasi menurunkan peringkat entitas dari ADMIN ke REGULAR_USER akan (dalam proses yang sama) juga perlu mencabut token yang sesuai. yaitu jika kita tahu klaim akan berubah, kami tidak menunggu kedaluwarsa, kami segera mencabutnya
e_i_pi

13

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.


1
Anda bisa mencabut token akses, yang akan membutuhkan login lagi untuk token akses lain atau menggunakan token refresh untuk mendapatkan token akses lain. Jika token penyegaran tidak valid, pengguna harus mengautentikasi ulang untuk mendapatkan token akses baru bersama dengan token penyegaran baru.
Atieh

10
Saya tidak setuju. Token akses dikeluarkan oleh server auth, ditandatangani dengan tanggal kedaluwarsa, dan dikirim ke klien. Ketika klien mengirim token itu ke server sumber daya, server sumber daya tidak menghubungi server auth untuk memverifikasi token; itu hanya melihat tanggal kedaluwarsa dalam token (ditandatangani dan tidak dirusak). Jadi, apa pun yang Anda lakukan di server auth untuk mencoba 'mencabut', server sumber daya tidak peduli. Beberapa orang menyebut logout klien sebagai pencabutan (yaitu klien menghapus token-nya) tetapi jika ini terminologi yang menyesatkan - kami ingin 'mencabut' token di server, bukan klien
bitcoder

1
Tidak mengatakan bahwa Anda tidak dapat menulis kode khusus untuk mengabaikan token tertentu (seperti di sini stackoverflow.com/questions/22708046/... ) tetapi melakukan itu mungkin melibatkan beberapa perjalanan jaringan dari server sumber daya ke server oauth / db setiap kali klien membuat sebuah panggilan. Anda menghindari panggilan itu dengan menggunakan token penyegaran sebagai gantinya, dan saya pikir lebih sesuai dengan apa yang dimaksudkan penulis asli.
bitcoder

13

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


2
sulit untuk mengikuti perbandingan ini karena pertanyaannya berbeda 1. "Selama 30 menit, berapa banyak peluang peretasan yang saya miliki terhadap kunci?" (bukankah saya memiliki kunci sebagai hacker pertama?) 2. "Selama 30 menit, berapa banyak peluang peretasan yang saya miliki terhadap kurir?". Apa yang dimaksud dengan "peluang peretasan"? Sebagai seorang hacker, bukankah saya memiliki kunci di tempat pertama?
Cesc

1
Kamu benar. Saya membuat perubahan
Sayang

4

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.


2
"dengan menggunakan tidak hanya refresh_token tetapi juga oleh client_id dan client_secret, yang tidak dimiliki peretas." 1. menganggap itu hanya token akses, maka bukankah hacker masih membutuhkan client_id dan client_secret? 2. jika seorang hacker adalah peretas yang baik maka ia dapat meretas client_id dan client_secret juga. Terlepas dari bagian itu, peretasan hal-hal tambahan seharusnya tidak menjadi masalah untuk perbandingan, karena jika sulit untuk diretas maka juga sulit untuk diretas untuk kasus hanya menggunakan token akses ... cerita pendek, Anda tidak membandingkan situasi yang sama. Anda mencampurkannya
Sayang

2

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.


Saya pikir ini adalah hal yang sangat penting :-) Ini juga - untuk beberapa derajat - jenis membatalkan argumen di sini auth0.com/docs/tokens/refresh-token/current#restrictions bahwaA 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.
Simon_Weaver

1

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.


0

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.


Ini sebenarnya tidak menyebutkan dari mana token penyegaran berasal. Saya berasumsi paragraf kedua harus mengatakan access token + refresh token?
Simon_Weaver
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.