Belajar A2A - Authentication & Security

#Pendahuluan

Di episode 8 kalian bisa mengirim data terstruktur antar agent dengan rapi. Namun ada pertanyaan yang belum kita jawab: apakah semua orang boleh memanggil agent kita? Sebuah agent yang mengekspos endpoint JSON-RPC tanpa autentikasi hanyalah pintu terbuka — siapapun bisa mengirim task, membaca hasil, atau menghabiskan kuota LLM. Episode ini menutup celah itu.

Roadmap episode ini: kita mulai dari mengapa autentikasi di level agent penting, lalu membedah field authentication pada Agent Card, alur OAuth 2.1, alternatif API key dan JWT, dan terakhir signed agent card untuk membangun trust antar agent.

#Mengapa Autentikasi di Level Agent Penting

Ingat kembali prinsip agent yang opaque dari episode 2: agent adalah layanan peer yang hanya berkomunikasi lewat task lifecycle. Karena internalnya tersembunyi, akses masuk hanya bisa dikontrol dari luar — dan itu artinya autentikasi harus menjadi bagian dari protokol itu sendiri, bukan kebijakan acak di tiap server.

Autentikasi di level agent juga memungkinkan authorization berbasis capabilities. Agent yang membaca data internal bisa membatasi siapa yang boleh mengirim task tertentu; agent publik bisa membedakan klien internal dan eksternal. Untuk itulah Agent Card membawa deklarasi autentikasi — sehingga calon client tahu persis cara "masuk" sebelum mengirim satu pun request.

#Field authentication di Agent Card

Spesifikasi A2A menempatkan kebutuhan autentikasi pada field authentication di Agent Card. Field ini berisi daftar schemes — masing-masing mendeskripsikan satu mekanisme yang didukung server:

{
  "agentName": "Analisis Lead",
  "url": "https://lead-agent.example.com/",
  "authentication": {
    "schemes": [
      {
        "type": "oauth2",
        "name": "oauth-vendor",
        "credentialFormat": "bearer",
        "authorizationServer": {
          "url": "https://auth.example.com/.well-known/oauth-authorization-server"
        }
      },
      {
        "type": "apiKey",
        "name": "api-key",
        "location": "header",
        "in": "Authorization"
      }
    ]
  }
}

Client membaca daftar ini untuk menentukan mekanisme yang bisa dipakainya. Tiga tipe yang paling umum: oauth2 dengan alur penuh, apiKey untuk token statis, dan jwt untuk token yang ditandatangani dan memuat klaim.

#Alur OAuth 2.1

Untuk agent enterprise, OAuth 2.1 adalah pilihan utama. Dibanding OAuth 2.0, versi 2.1 menghapus beberapa jalan pintas yang rawan salah pakai — misalnya alur authorization code hanya lewat PKCE — dan itulah yang diadopsi ekosistem A2A.

Alurnya ringkas:

1. Discover. Client mengambil Agent Card dan menemukan skema oauth2 beserta URL authorizationServer.
2. Metadata. Client membuka URL tersebut untuk mendapat endpoint token, audience yang didukung, dan parameter tambahan.
3. Dapatkan token. Untuk interaksi antar layanan (tanpa user), alur yang tepat adalah client credentials: client menukar client_id dan rahasianya dengan access token.
4. Kirim task. Setiap request JSON-RPC membawa token, biasanya di header Authorization dengan format Bearer.

curl -X POST https://lead-agent.example.com/ \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer TOKEN_AKSES" \
  -d '{"jsonrpc":"2.0","id":1,"method":"message/send","params":{"message":{"role":"user","parts":[{"kind":"text","text":"Analisis lead"}]}}}'

Keuntungan utama OAuth adalah delegasi dan rotasi. Token bisa diberi masa hidup pendek, dirotasi otomatis, dan dicabut tanpa menyentuh kredensial statis di banyak server. Inilah pilihan yang tepat ketika agent dipanggil oleh banyak orchestrator lintas tim.

#API Key dan JWT

Tidak semua kasus butuh OAuth. Untuk integrasi sederhana antar agent internal, API key lebih ringan: client mengirim satu string statis, server mencocokkannya dengan penyimpanan key miliknya. Skema apiKey di Agent Card memberitahu client di mana key ditaruh — umumnya header Authorization atau X-API-Key.

JWT berada di tengah-tengah: server memverifikasi tanda tangan token dengan kunci publik, tanpa perlu menyimpan sesi atau mencocokkan key per client. Klaim di dalam token — misalnya tenant atau level akses — bisa langsung dibaca server untuk authorization.

Apapun mekanismenya, aturan praktisnya sama: selalu HTTPS. Token yang lewat HTTP polos sama saja dengan token yang dipajang di depan umum.

#Signed Agent Card: Verifikasi Identitas & Integritas

Autentikasi menjawab "siapa kamu", tapi belum menjawab "apakah kartu yang kamu pegang benar-benar milikmu". A2A v1.0 menjawab ini dengan signed agent card — penandatanganan kartu sehingga client bisa memverifikasi identitas dan integritas capabilities sebelum mempercayai isinya.

Kartu yang ditandatangani membawa objek security dengan signedCard, berisi signature dan kunci verifikasi dalam format JWKS:

{
  "agentName": "Analisis Lead",
  "version": "1.0.0",
  "security": {
    "signedCard": {
      "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImsyMDI2Iiwi",
      "signingKey": {
        "jwks": {
          "keys": [
            { "kty": "EC", "crv": "P-256", "kid": "kunci-2026", "x": "AZ...", "y": "Yz..." }
          ]
        }
      }
    }
  }
}

Saat mendownload kartu di discovery (episode 3), client melakukan verifikasi berjenjang:

1. Ambil signature dan kunci signingKey dari field security.
2. Verifikasi signature terhadap konten kartu dengan kunci publik dari JWKS.
3. Jika tanda tangan valid, kartu dianggap datang dari pemilik kunci — isi capabilities bisa dipercaya.
4. Cocokkan identitas yang diharapkan, misalnya domain atau organisasi partner.

Model trust yang terbentuk adalah agent-to-agent: setiap agent memverifikasi lawan bicaranya secara langsung, tanpa butuh otoritas pusat. Inilah yang memungkinkan jaringan dengan ratusan organisasi — seperti ekosistem 150+ partner di bawah Linux Foundation — saling percaya tanpa satu titik kontrol tunggal.

#Penutup

Episode 9 mengunci akses ke agent kalian: field authentication di Agent Card mendeklarasikan mekanisme yang didukung — OAuth 2.1 untuk delegasi dan rotasi token, API key untuk integrasi ringan, JWT untuk token stateless pembawa klaim. Dan signed agent card di A2A v1.0 memberi verifikasi identitas serta integritas capabilities lewat tanda tangan digital, membangun trust langsung antar agent.

Inti yang harus dibawa pulang:

• Autentikasi agent dimulai dari deklarasi field authentication pada Agent Card dengan daftar schemes.
• OAuth 2.1 dipakai untuk skenario enterprise: discovery metadata, client credentials, token bearer di header Authorization.
• API key untuk integrasi internal yang sederhana; JWT untuk distribusi besar dengan klaim bawaan.
• Selalu HTTPS dan rotasi kredensial; token pendek masa hidupnya lebih aman.
• Signed agent card memverifikasi tanda tangan dengan JWKS, dan trust dibangun melalui distribusi kunci publik yang terkontrol.

Autentikasi menyelesaikan satu masalah, tapi membuka pertanyaan baru di lingkungan enterprise: bagaimana satu agent yang sama melayani banyak klien dengan konteks dan isolasi berbeda, dan bagaimana dua agent dengan versi protokol berbeda tetap bisa berkomunikasi. Di episode 10 kita membahas Multi-tenancy & Version Negotiation (v1.0). Sampai jumpa!