Antipattern: Menetapkan waktu habis masa berlaku untuk token OAuth

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X. info

Apigee Edge menyediakan framework OAuth 2.0 untuk Google Cloud API aman. OAuth2 adalah salah satu otentikasi standar terbuka, berbasis token yang paling populer, dan skema otorisasi secara otomatis. Layanan ini memungkinkan aplikasi klien mengakses API atas nama pengguna tanpa mengharuskan pengguna untuk membocorkan nama pengguna dan {i>password<i} mereka.

Apigee Edge memungkinkan developer menghasilkan akses dan/atau token refresh dengan mengimplementasikan salah satu keempat jenis pemberian izin OAuth2 - kredensial klien, sandi, implisit, dan kode otorisasi - menggunakan kebijakan OAuthv2. Aplikasi klien menggunakan token akses untuk menggunakan API yang aman. Setiap token akses memiliki masa berlaku sendiri yang dapat ditetapkan dalam kebijakan OAuthv2.

Token refresh dikeluarkan secara opsional bersama dengan token akses dengan beberapa jenis pemberian izin. Muat Ulang token digunakan untuk memperoleh token akses baru yang valid setelah token akses asli kedaluwarsa atau telah dicabut. Waktu habis masa berlaku untuk token refresh juga dapat ditetapkan di kebijakan OAuthv2.

Anti-pola ini terkait dengan anti-pola dari menetapkan waktu kedaluwarsa yang lama untuk token OAuth.

Anti-pola

Menetapkan waktu habis masa berlaku untuk token refresh dalam kebijakan OAuthv2 menyebabkan akumulasi token OAuth dan meningkatkan penggunaan ruang {i>disk<i} pada node Cassandra.

Contoh kebijakan OAuthV2 berikut menunjukkan konfigurasi yang hilang untuk <RefreshTokenExpiresIn>: 

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <!--<RefreshTokenExpiresIn> is missing -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Dalam contoh di atas:

  • Token akses ditetapkan dengan waktu habis masa berlaku yang cukup rendah, yaitu 30 menit.
  • Masa berlaku token refresh belum ditetapkan.
  • Token refresh tetap ada di data store (Cassandra) selamanya, sehingga menyebabkan data terakumulasi.
  • Token refresh yang dibuat tanpa masa berlaku dapat digunakan tanpa batas waktu untuk membuat token akses.
  • Jika traffic ke API ini adalah 10 permintaan per detik, API ini dapat menghasilkan sebanyak 864.000 token dalam sehari.

Dampak

  • Jika token refresh dibuat tanpa masa berlaku, ada dua konsekuensi utama:
    • Token refresh dapat digunakan kapan saja pada masa mendatang, kemungkinan selama bertahun-tahun, untuk mendapatkan akses sebelumnya yang benar. Hal ini dapat memiliki implikasi keamanan.
    • Baris di Cassandra yang berisi token refresh tidak akan pernah dihapus. Ini akan menyebabkan data terakumulasi di Cassandra.
  • Jika Anda tidak menggunakan token refresh untuk mendapatkan token akses baru, tetapi sebagai gantinya membuat token pembaruan dan token akses, token pembaruan yang lama akan tetap berada di Cassandra. Oleh karena itu, muat ulang token akan terus terakumulasi di Cassandra, yang selanjutnya akan menjadi menggelembungkan, peningkatan penggunaan {i>disk<i}, dan pemadatan yang lebih berat, dan pada akhirnya akan menyebabkan operasi baca/tulis dan latensi di Cassandra.

Praktik Terbaik

Gunakan waktu habis masa berlaku yang rendah untuk token refresh dan akses. Lihat praktik terbaik untuk setelan kedaluwarsa waktu refresh dan token akses. Pastikan untuk menentukan konfigurasi masa berlaku untuk kedua akses dan token pembaruan di kebijakan. Lihat Dokumentasi kebijakan OauthV2 untuk detail lebih lanjut tentang konfigurasi kebijakan.

Praktik terbaik khusus untuk pelanggan Edge bagi pelanggan Private Cloud

Bagian ini menjelaskan praktik terbaik khusus untuk pelanggan Edge bagi pelanggan Private Cloud.

Menentukan akhir masa berlaku token refresh default

Secara default, jika masa berlaku token refresh tidak ditentukan dalam konfigurasi kebijakan, Edge membuat token refresh tanpa masa berlaku apa pun. Anda dapat mengganti perilaku ini dengan prosedur berikut:

  1. Pada node pemroses pesan, edit atau buat file pengganti konfigurasi $APIGEE_ROOT/customer/application/message-processor.properties. Pastikan file ini dapat dibaca oleh pengguna apigee.
  2. Tambahkan baris berikut ke file: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
     Tindakan ini akan menyetel masa berlaku token refresh default, jika tidak ada yang ditentukan dalam kebijakan, ke 1 jam. Anda dapat mengubah nilai default ini berdasarkan kebutuhan bisnis Anda.
  3. Mulai ulang layanan Pemroses pesan: 
    apigee-service edge-message-processor restart
  4. Ulangi langkah-langkah di atas di semua node pemroses pesan satu per satu.

Praktik terbaik di Cassandra

Coba upgrade ke versi terbaru Apigee yang tersedia untuk publik. Apigee berlanjut merilis perbaikan dan peningkatan yang terus meningkatkan dan mengoptimalkan pengelolaan token dalam Apigee. Di Apigee, token akses dan refresh disimpan di Cassandra dalam keyspace “kms”. Anda harus memastikan bahwa strategi pemadatan ini keyspace disetel ke LeveledCompactionStrategy. Anda harus memeriksa apakah indeks berikut tidak ada:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 dan
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Anda juga dapat mengurangi gc_grace_seconds dalam tabel kms.oauth_20_access_tokens dari jangka waktu default 10 hari ke (seperti 3 hari) untuk memastikan tombstone yang dihasilkan karena token yang dihapus dihapus dari penyimpanan data dengan lebih cepat.

Bacaan lebih lanjut