Menggunakan metode kustom untuk mengautentikasi pengguna

Halaman ini menjelaskan cara mendukung autentikasi pengguna di Cloud Endpoints.

Untuk mengautentikasi pengguna, aplikasi klien harus mengirimkan Token Web JSON (JWT) di header otorisasi permintaan HTTP ke API backend Anda. Extensible Service Proxy (ESP) memvalidasi token atas nama API Anda, sehingga Anda tidak perlu menambahkan kode apa pun di API untuk memproses autentikasi. Namun, Anda perlu mengonfigurasi dokumen OpenAPI untuk mendukung metode autentikasi yang dipilih.

ESP memvalidasi JWT dengan cara yang berperforma tinggi menggunakan kunci publik penerbit JWT. ESP menyimpan kunci publik dalam cache selama lima menit. Selain itu, ESP meng-cache JWT yang divalidasi selama lima menit atau hingga JWT berakhir masa berlakunya, mana saja yang terjadi lebih dulu.

Sebelum memulai

  • Tambahkan kode autentikasi ke aplikasi klien Anda, dengan mengikuti dokumentasi penyedia autentikasi.

  • Saat aplikasi klien Anda mengirim permintaan HTTP, header otorisasi dalam permintaan harus berisi klaim JWT berikut:
    • iss (penerbit)
    • sub (subjek)
    • aud (audiens)
    • iat (diterbitkan pada)
    • exp (waktu habis masa berlaku)

Mengonfigurasi ESP untuk mendukung autentikasi klien

Anda harus memiliki objek persyaratan keamanan dan objek definisi keamanan dalam dokumen OpenAPI agar ESP dapat memvalidasi klaim dalam JWT yang ditandatangani.

Untuk mendukung autentikasi kustom:

  1. Tambahkan hal berikut ke definisi keamanan dalam dokumen OpenAPI Anda:

     securityDefinitions:
   your_custom_auth_id:
     authorizationUrl: ""
     flow: "implicit"
     type: "oauth2"
     # The value below should be unique
     x-google-issuer: "issuer of the token"
     x-google-jwks_uri: "url to the public key"
     # Optional. Replace YOUR-CLIENT-ID with your client ID
     x-google-audiences: "YOUR-CLIENT-ID"

  2. Tambahkan bagian keamanan di tingkat API untuk diterapkan ke seluruh API, atau di tingkat metode untuk diterapkan ke metode tertentu.

     security:
   - your_custom_auth_id: []

Anda dapat menentukan beberapa definisi keamanan dalam dokumen OpenAPI, tetapi setiap definisi harus memiliki penerbit yang berbeda. Jika Anda menggunakan bagian keamanan di API level dan di level metode, setelan level metode akan menggantikan setelan API level.

Kolom x-google-audiences tidak wajib diisi. ESP menerima semua JWT dengan nama layanan backend dalam bentuk https://SERVICE_NAME dalam klaim aud. Untuk mengizinkan client ID tambahan mengakses layanan backend, Anda dapat menentukan client ID yang diizinkan di kolom x-google-audiences menggunakan nilai yang dipisahkan koma. ESP kemudian menerima JWT dengan salah satu client ID yang ditentukan dalam klaim aud.

ESP mendukung dua format kunci publik asimetris yang ditentukan oleh ekstensi OpenAPI x-google-jwks_uri:

  • Format kumpulan JWK. Contoh: 
    x-google-jwks_uri: "https://YOUR_ACCOUNT_NAME.YOUR_AUTH_PROVIDER_URL/.well-known/jwks.json"
  • X509. Contoh: 
    x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"

Jika Anda menggunakan format kunci simetris, tetapkan x-google-jwks_uri ke URI file yang berisi string kunci yang dienkode base64url.

Jika Anda menghilangkan x-google-jwks_uri, ESP akan mengikuti protokol OpenID Connect Discovery untuk menemukan URI JWKS secara otomatis untuk penyedia OpenID tertentu. ESP akan membuat permintaan ke x-google-issuer/.well-known/openid-configuration, menguraikan respons JSON, dan membaca URI JWKS dari kolom jwks_uri tingkat atas.

Perhatikan bahwa menghilangkan x-google-jwks_uri akan menghasilkan waktu cold start yang lebih tinggi, karena ESP harus melakukan panggilan jarak jauh tambahan saat memulai. Oleh karena itu, sebaiknya hapus kolom ini jika URI JWKS sering berubah. Sebagian besar penyedia OpenID bersertifikasi (seperti Google, Auth0, dan Okta) memiliki URI JWKS yang stabil.

Anda juga dapat menyesuaikan lokasi JWT dengan menambahkan x-google-extensions. Untuk mengetahui detailnya, lihat ekstensi openAPI.

Melakukan panggilan yang diautentikasi ke Endpoints API

Saat Anda mengirim permintaan menggunakan token autentikasi, demi keamanan, sebaiknya tempatkan token di header Authorization:Bearer. Misalnya:

curl -H "Authorization: Bearer ${TOKEN}" "${ENDPOINTS_HOST}/echo"

Di sini, ENDPOINTS_HOST dan TOKEN adalah variabel lingkungan yang masing-masing berisi nama host API dan token autentikasi Anda. Lihat Membuat permintaan yang diautentikasi ke Endpoints API. untuk mengetahui contoh kode yang mengirim permintaan menggunakan header Authorization:Bearer.

Jika tidak dapat menggunakan header saat mengirim permintaan, Anda dapat menempatkan token autentikasi dalam parameter kueri yang disebut access_token. Contoh:

curl "${ENDPOINTS_HOST}/echo?access_token=${TOKEN}"

Menerima hasil yang diautentikasi di API Anda

ESP biasanya meneruskan semua header yang diterimanya. Namun, header ini akan mengganti header Authorization asli saat alamat backend ditentukan oleh x-google-backend dalam spesifikasi OpenAPI atau BackendRule dalam konfigurasi layanan gRPC.

ESP akan mengirimkan hasil autentikasi di X-Endpoint-API-UserInfo ke API backend. Sebaiknya gunakan header ini, bukan header Authorization asli. Header ini adalah string yang dienkode oleh base64url objek JSON. Format objek JSON berbeda antara ESPv2 dan ESP. Untuk ESPv2, objek JSON sama persis dengan payload JWT asli. Untuk ESP, objek JSON menggunakan nama kolom yang berbeda dan menempatkan payload JWT asli di kolom claims. Lihat Menangani JWT di layanan backend untuk mengetahui informasi selengkapnya tentang formatnya.

Langkah selanjutnya