Saya baru mulai bekerja dengan Google API dan OAuth2. Ketika klien mengotorisasi aplikasi saya, saya diberi "token penyegaran" dan "token akses" yang singkat. Sekarang setiap kali token akses kedaluwarsa, saya bisa POST token refresh saya ke Google dan mereka akan memberi saya token akses baru.

Pertanyaan saya adalah apa tujuan token akses yang kedaluwarsa? Mengapa tidak ada token akses yang tahan lama dan bukan token penyegaran?

Juga, apakah token penyegaran kadaluwarsa?

Lihat Menggunakan OAuth 2.0 untuk Mengakses Google APIs untuk info lebih lanjut tentang alur kerja Google OAuth2.

Ini sangat spesifik implementasi, tetapi ide umumnya adalah untuk memungkinkan penyedia untuk menerbitkan token akses jangka pendek dengan token refresh jangka panjang. Mengapa?

• Banyak penyedia mendukung token pembawa yang sangat lemah dari segi keamanan. Dengan membuat mereka berumur pendek dan membutuhkan penyegaran, mereka membatasi waktu penyerang dapat menyalahgunakan token yang dicuri.
• Penerapan skala besar tidak ingin melakukan pencarian basis data setiap panggilan API, jadi alih-alih mereka mengeluarkan token akses yang disandikan sendiri yang dapat diverifikasi dengan dekripsi. Namun, ini juga berarti tidak ada cara untuk mencabut token ini sehingga dikeluarkan untuk waktu yang singkat dan harus disegarkan.
• Token penyegaran membutuhkan otentikasi klien yang membuatnya lebih kuat. Berbeda dengan token akses di atas, biasanya diimplementasikan dengan pencarian basis data.

Beberapa skenario mungkin membantu menggambarkan tujuan akses dan menyegarkan token dan pertukaran teknik dalam merancang sistem Oauth2 (atau auth lain):

Skenario aplikasi web

Dalam skenario aplikasi web, Anda memiliki beberapa opsi:

1. jika Anda memiliki manajemen sesi Anda sendiri, simpan access_token dan refresh_token terhadap id sesi Anda dalam status sesi pada layanan status sesi Anda. Ketika sebuah halaman diminta oleh pengguna yang mengharuskan Anda untuk mengakses sumber daya gunakan access_token dan jika access_token telah kedaluwarsa gunakan refresh_token untuk mendapatkan yang baru.

Bayangkan seseorang berhasil membajak sesi Anda. Satu-satunya hal yang mungkin adalah meminta halaman Anda.

2. jika Anda tidak memiliki manajemen sesi, letakkan access_token dalam cookie dan gunakan itu sebagai sesi. Lalu, setiap kali pengguna meminta halaman dari server web Anda kirimkan access_token. Server aplikasi Anda dapat menyegarkan access_token jika perlu.

Membandingkan 1 dan 2:

Dalam 1, access_token dan refresh_token hanya melakukan perjalanan melalui kabel di jalan antara server otorisasi (google dalam kasus Anda) dan server aplikasi Anda. Ini akan dilakukan pada saluran yang aman. Seorang peretas dapat membajak sesi tersebut tetapi mereka hanya dapat berinteraksi dengan aplikasi web Anda. Di 2, peretas dapat mengambil akses_token dan membentuk permintaan mereka sendiri ke sumber daya yang telah diberikan akses kepada pengguna. Bahkan jika peretas menguasai access_token, mereka hanya akan memiliki jendela pendek di mana mereka dapat mengakses sumber daya.

Apapun itu, refresh_token dan clientid / secret hanya diketahui oleh server sehingga tidak mungkin dari browser web untuk mendapatkan akses jangka panjang.

Bayangkan Anda menerapkan oauth2 dan menetapkan batas waktu yang lama pada token akses:

Dalam 1) Tidak ada banyak perbedaan di sini antara token akses pendek dan panjang karena disembunyikan di server aplikasi. Dalam 2) seseorang bisa mendapatkan access_token di browser dan kemudian menggunakannya untuk secara langsung mengakses sumber daya pengguna untuk waktu yang lama.

Skenario seluler

Di ponsel, ada beberapa skenario yang saya ketahui:

1. Simpan clientid / rahasia di perangkat dan minta perangkat mengatur akses ke sumber daya pengguna.

2. Gunakan server aplikasi backend untuk menyimpan clientid / rahasia dan minta orkestrasi melakukannya. Gunakan access_token sebagai semacam kunci sesi dan berikan di antara klien dan server aplikasi.

Membandingkan 1 dan 2

In 1) Setelah Anda memiliki clientid / rahasia di perangkat mereka tidak lagi rahasia. Siapa pun dapat mendekompilasi dan kemudian mulai bertindak seolah-olah mereka adalah Anda, dengan izin dari pengguna tentu saja. Access_token dan refresh_token juga ada dalam memori dan dapat diakses pada perangkat yang dikompromikan yang berarti seseorang dapat bertindak sebagai aplikasi Anda tanpa pengguna memberikan kredensial mereka. Dalam skenario ini, panjang access_token tidak membuat perbedaan pada kemampuan meretas karena refresh_token berada di tempat yang sama dengan access_token. Dalam 2) clientid / rahasia atau token penyegaran dikompromikan. Di sini, lamanya kedaluwarsa access_token menentukan berapa lama seorang hacker dapat mengakses sumber daya pengguna, jika mereka mendapatkannya.

Panjang kedaluwarsa

Di sini tergantung pada apa yang Anda amankan dengan sistem auth Anda untuk berapa lama seharusnya kadaluwarsa access_token Anda. Jika itu sesuatu yang sangat berharga bagi pengguna itu harus pendek. Sesuatu yang kurang berharga, bisa lebih lama.

Beberapa orang seperti Google tidak kedaluwarsa pada refresh_token. Beberapa seperti stackflow lakukan. Keputusan tentang kedaluwarsa merupakan trade-off antara kemudahan dan keamanan pengguna. Panjang token penyegaran terkait dengan panjang pengembalian pengguna, yaitu mengatur penyegaran seberapa sering pengguna kembali ke aplikasi Anda. Jika token penyegaran tidak kedaluwarsa, satu-satunya cara mereka dicabut adalah dengan pencabutan eksplisit. Biasanya, masuk tidak mencabut.

Semoga postingan yang agak panjang bermanfaat.

Selain tanggapan lainnya:

Setelah diperoleh, Token Akses biasanya dikirim bersama dengan setiap permintaan dari Klien ke Server Sumberdaya yang dilindungi. Ini menimbulkan risiko untuk mencuri token akses dan replay (dengan asumsi tentu saja bahwa token akses adalah tipe "Bearer" (sebagaimana didefinisikan dalam RFC6750 awal).

Contoh risiko tersebut, dalam kehidupan nyata:

• Server Sumber Daya umumnya adalah server aplikasi terdistribusi dan biasanya memiliki tingkat keamanan yang lebih rendah dibandingkan dengan Server Otorisasi (konfigurasi SSL / TLS yang lebih rendah, pengerasan kurang, dll.). Server Otorisasi di sisi lain biasanya dianggap sebagai infrastruktur Keamanan kritis dan mengalami pengerasan yang lebih parah.

• Token Akses dapat muncul dalam jejak HTTP, log, dll. Yang dikumpulkan secara sah untuk tujuan diagnostik pada Server Sumber Daya atau klien. Jejak tersebut dapat dipertukarkan di tempat-tempat umum atau semi-publik (pelacak kutu, meja layanan, dll.).

• Aplikasi RS Backend dapat dialihdayakan ke pihak ketiga yang kurang lebih dapat dipercaya.

Refresh Token, di sisi lain, biasanya ditransmisikan hanya dua kali melalui kabel, dan selalu antara klien dan Server Otorisasi: sekali ketika diperoleh oleh klien, dan sekali ketika digunakan oleh klien selama penyegaran (secara efektif "berakhir" penyegaran sebelumnya token). Ini adalah kesempatan yang sangat terbatas untuk intersepsi dan pemutaran ulang.

Pemikiran terakhir, Segarkan Token menawarkan sedikit perlindungan, jika ada, terhadap klien yang dikompromikan.

Ini pada dasarnya adalah langkah pengamanan. Jika aplikasi Anda terganggu, penyerang hanya akan memiliki akses ke token akses berumur pendek dan tidak ada cara untuk menghasilkan yang baru.

Refresh token juga kedaluwarsa tetapi mereka seharusnya hidup lebih lama daripada token akses.