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 mengamankan API. OAuth2 adalah salah satu skema otorisasi dan autentikasi berbasis token dengan standar terbuka yang paling populer. OAuth 2.0 memungkinkan aplikasi klien mengakses API atas nama pengguna tanpa meminta pengguna mengungkapkan nama pengguna dan sandi mereka.

Apigee Edge memungkinkan developer membuat token akses dan/atau token refresh dengan menerapkan salah satu dari empat 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 waktu habis masa berlakunya sendiri, yang dapat ditetapkan dalam kebijakan OAuthv2.

Token refresh secara opsional dikeluarkan bersama dengan token akses dengan beberapa jenis pemberian izin. Token refresh digunakan untuk mendapatkan token akses baru yang valid setelah token akses asli tidak berlaku lagi atau dicabut. Waktu habis masa berlaku untuk token refresh juga dapat ditetapkan dalam kebijakan OAuthv2.

Antipola ini terkait dengan antipola menetapkan waktu habis masa berlaku yang lama untuk token OAuth.

Anti-pola

Tidak menyetel waktu habis masa berlaku untuk token refresh di kebijakan OAuthv2 akan menyebabkan akumulasi token OAuth dan peningkatan penggunaan ruang disk di node Cassandra.

Contoh kebijakan OAuthV2 berikut menunjukkan konfigurasi yang tidak ada 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 tidak ditetapkan.
  • Token refresh tetap ada di penyimpanan data (Cassandra) selamanya, sehingga menyebabkan akumulasi data.
  • 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 hingga 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, mungkin selama bertahun-tahun, untuk mendapatkan token akses. Hal ini dapat menimbulkan implikasi keamanan.
    • Baris di Cassandra yang berisi token refresh tidak akan pernah dihapus. Hal ini akan menyebabkan data terakumulasi di Cassandra.
  • Jika Anda tidak menggunakan token refresh untuk mendapatkan token akses baru, tetapi membuat token refresh dan token akses baru, token refresh yang lebih lama akan tetap ada di Cassandra. Akibatnya, token refresh akan terus terakumulasi di Cassandra, sehingga menambah pembengkakan, meningkatkan penggunaan disk, dan kompresi yang lebih berat, dan pada akhirnya akan menyebabkan latensi baca/tulis di Cassandra.

Praktik Terbaik

Gunakan waktu habis masa berlaku yang cukup rendah untuk token refresh dan akses. Lihat praktik terbaik untuk menetapkan waktu habis masa berlaku token refresh dan akses. Pastikan untuk menentukan konfigurasi masa berlaku untuk token akses dan token refresh dalam kebijakan. Lihat dokumentasi kebijakan OauthV2 untuk mengetahui detail selengkapnya tentang konfigurasi kebijakan.

Praktik terbaik khusus untuk pelanggan Edge untuk Private Cloud

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

Menentukan habis masa berlaku token refresh default

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

  1. Di node pemroses pesan, edit atau buat file penggantian 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 menetapkan masa berlaku token refresh default, jika tidak ada yang ditentukan dalam kebijakan, menjadi 1 jam. Anda dapat mengubah nilai default ini berdasarkan kebutuhan bisnis Anda.
  3. Mulai ulang layanan Message processor: 
    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 Apigee terbaru yang tersedia secara publik. Apigee terus 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 keyspace ini ditetapkan ke LeveledCompactionStrategy. Anda harus memeriksa bahwa 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 10 hari default ke nilai yang lebih rendah (seperti 3 hari) untuk memastikan penanda dihapus yang dibuat karena token dihapus dihapus dari penyimpanan data lebih cepat.

Bacaan lebih lanjut