Cloudflare membangun OAuth bersama Claude dan membuka semua prompt

• Cloudflare mengumumkan framework provider OAuth 2.1 sebagai library TypeScript untuk Cloudflare Workers
• Sebagian besar implementasinya ditulis dengan bantuan Claude LLM dari Anthropic, lalu ditinjau dengan cermat oleh engineer keamanan Cloudflare
• Library ini menyediakan otomatisasi autentikasi untuk endpoint API dan penanganan manajemen token secara otomatis
• Mendukung fitur-fitur utama seperti standar OAuth terbaru dan PKCE, pendaftaran klien dinamis, serta pengaturan scope akses
• Menekankan desain keamanan seperti enkripsi end-to-end pada bagian-bagian penting dan refresh token sekali pakai

---

Pengenalan dan pentingnya framework provider OAuth 2.1 untuk Cloudflare Workers

Proyek open-source ini adalah library TypeScript yang dirancang agar server autentikasi OAuth 2.1 dapat diimplementasikan dengan mudah di lingkungan Cloudflare Workers.
Dibandingkan proyek sejenis lainnya, keunggulannya terletak pada skalabilitas dan integrasi mulus yang dioptimalkan untuk platform Cloudflare, serta desain yang berfokus pada keamanan
Fokus utamanya ada pada algoritme, kepatuhan terhadap standar protokol (RFC-8414, RFC-7591, dan lainnya), serta kejelasan struktur library
Secara khusus, library ini dirancang rinci untuk keamanan, seperti penyimpanan token dan nilai rahasia penting dalam bentuk hash, serta enkripsi end-to-end untuk props
Sebagai catatan, sebagian besar kode inti library dan dokumentasinya ditulis dengan kolaborasi Claude LLM, menunjukkan contoh pengembangan yang menarik

Fitur dan keunggulan utama

• Membungkus kode Worker dengan OAuthProvider untuk secara otomatis menambahkan fungsi autentikasi ke endpoint API
• Manajemen token (pembuatan, penyimpanan, verifikasi, pembuangan, dan sebagainya) ditangani secara otomatis, sehingga tidak perlu diimplementasikan sendiri
• Di dalam fetch handler, pengguna bisa langsung menerima informasi pengguna yang sudah diautentikasi sebagai parameter untuk digunakan
• Tidak ada batasan pada pengelolaan pengguna, autentikasi, maupun cara implementasi UI (developer bebas memilih struktur dan framework yang diinginkan)
• Repositori penyimpanan library ini hanya menyimpan informasi hash, dan tidak menyimpan secret seperti kunci rahasia itu sendiri

Inti cara penggunaan

• Instance OAuthProvider dapat diekspor sebagai entry point Worker untuk berperan sebagai fetch handler
• Dengan opsi apiRoute dan apiHandler, dapat ditentukan masing-masing bagian endpoint API yang memerlukan autentikasi dan handler aktualnya
• Jalur endpoint OAuth standar seperti authorizeEndpoint, tokenEndpoint, dan clientRegistrationEndpoint dapat didefinisikan
• Jika diperlukan, kebijakan seperti scope atau public client registration dapat dirinci lebih lanjut
• Melalui defaultHandler, permintaan di luar API maupun permintaan autentikasi yang gagal juga dapat ditangani secara fleksibel

Objek helper dan API

• env.OAUTH_PROVIDER dapat digunakan di dalam fetch handler untuk parsing permintaan terkait OAuth, mengambil informasi klien, menyelesaikan persetujuan, dan lainnya
• Dalam pemrosesan permintaan API, jika access token valid maka informasi props per pengguna dalam status telah diberi otorisasi dapat langsung diakses melalui ctx.props
• Pendaftaran klien, daftar authorization grant, serta penelusuran dan pencabutan grant untuk pengguna tertentu juga disediakan lewat API resmi

Token Exchange Callback

• Mendukung callback (tokenExchangeCallback) yang memungkinkan memperbarui nilai props secara dinamis saat token diterbitkan atau diperbarui
• Dapat mendukung skenario kompleks seperti pertukaran token tambahan yang terhubung dengan klien OAuth (upstream token exchange)
• Di dalam callback, perilaku kustom dapat diimplementasikan dengan mengembalikan accessTokenProps, newProps, accessTokenTTL, dan lainnya
• Melalui kustomisasi accessTokenTTL, waktu kedaluwarsa token dapat diselaraskan dengan sistem OAuth upstream
• Karena props dapat berisi informasi sensitif, seluruh nilai ini disimpan dalam keadaan terenkripsi end-to-end

Respons error kustom

• Dengan opsi onError, tindakan eksternal seperti mengirim notifikasi atau logging kustom saat terjadi error dapat dilakukan
• Jika Response dikembalikan secara langsung, respons error yang diberikan OAuthProvider kepada pengguna dapat dioverride ke bentuk yang diinginkan

Rincian desain terkait keamanan

Enkripsi end-to-end

• Data terkait token dan secret hanya disimpan sebagai hash, sementara informasi grant props disimpan dalam keadaan terenkripsi menggunakan token itu sendiri untuk meningkatkan kesiapan menghadapi insiden kebocoran
• userId, metadata, dan sejenisnya tidak dienkripsi agar dapat dicatat untuk kebutuhan audit dan pencabutan; bila perlu developer dapat menambahkan enkripsi sendiri

Desain refresh token sekali pakai

• Sesuai persyaratan OAuth 2.1 tentang kondisi "client binding atau sekali pakai", library ini memakai desain kompromi berupa maksimal 2 refresh token paralel yang diizinkan
• Dengan demikian, jika penyimpanan token baru gagal akibat gangguan jaringan atau sejenisnya, tersedia mekanisme pengaman agar token sebelumnya masih bisa digunakan sekali lagi

Proses pengembangan berbasis Claude

• Library ini dan sebagian besar dokumentasinya pertama-tama dibuat dengan memanfaatkan Anthropic Claude LLM, lalu direview cermat oleh engineer Cloudflare agar sesuai dengan RFC dan standar keamanan
• Pada awalnya ada sikap skeptis terhadap pembuatan kode oleh AI, tetapi pandangan itu berubah setelah melihat langsung peningkatan kualitas dan produktivitas
• Alur pengembangan, prompt Claude, serta proses perbaikan kode semuanya dibuka secara transparan melalui riwayat commit Git

Hal lainnya

• Wajib menerapkan binding Workers KV namespace (OAUTH_KV), lihat storage-schema.md
• Untuk seluruh API dan helper, lihat definisi interface OAuthHelpers
• Library ini saat ini masih dalam tahap beta/prarilis, sehingga API dapat berubah di masa mendatang

---

[GN⁺]

Komentar Hacker News

• Kutipan dari README. Pustaka ini (beserta dokumen skemanya) sebagian besar ditulis dengan bantuan model AI Claude dari Anthropic. Para engineer Cloudflare meninjaunya dengan sangat teliti dan memperhatikan keamanan serta kepatuhan terhadap standar. Bahkan dari hasil awal pun sudah ada banyak perbaikan, terutama dengan memberi prompt tambahan ke Claude dan meninjau hasilnya secara berulang. Di riwayat commit, kita bisa langsung melihat bagaimana Claude diberi prompt dan kode seperti apa yang dihasilkan. Awalnya ada sikap skeptis tradisional bahwa “LLM tidak seharusnya dibiarkan menulis pustaka autentikasi”. Bahkan sampai Januari 2025, saya sendiri sangat skeptis terhadap AI, dan menganggap LLM hanyalah semacam ‘generator rantai Markov yang mewah’, tidak mampu menghasilkan sesuatu yang benar-benar baru atau kode yang nyata. Proyek ini dimulai sekadar untuk iseng, tetapi saya terkejut karena kode yang keluar ternyata lumayan bagus. Memang tidak sempurna, tetapi ketika AI diminta memperbaiki, hasilnya benar-benar dibetulkan. Saya memeriksanya baris demi baris sambil membandingkan dengan berbagai RFC, lalu meninjaunya bersama para ahli keamanan. Saya berusaha menguji skeptisisme saya sendiri, tetapi hasilnya justru membuktikan bahwa saya yang salah. Riwayat commit, terutama commit-commit awal, wajib dilihat kalau ingin memahami proses ini

  • Saya memang berharap LLM bisa menghasilkan kode setingkat ini bila diberi prompt yang tepat oleh engineer berpengalaman. OAuth bukan teknologi baru, dan kemungkinan sudah ada banyak contoh open source serta berbagai implementasi lintas bahasa yang menjadi data latih. Tetapi saya masih skeptis terhadap klaim bahwa LLM akan memberi kontribusi revolusioner pada riset yang benar-benar baru, material science, ekonomi, penemuan, dan sebagainya. Itu adalah bidang yang benar-benar membutuhkan ‘kemampuan belajar secara real-time’, sementara LLM yang ada sekarang hanya menunjukkan kemampuan berdasarkan informasi lama yang sudah diketahuinya. Hasil yang berarti biasanya hanyalah contoh cherry-pick dalam lingkungan yang sangat terbatas. Jika ada engineer berpengalaman, saya rasa wajar bila kode baru bisa dihasilkan dari data masa lalu, tetapi saya tetap bertanya-tanya apakah beban lingkungan dan sosial dari adopsi LLM tidak berlebihan dibanding efisiensi nyatanya

  • Saya bingung dengan ungkapan “Saya memiliki pandangan yang sama dengan (@kentonv) sampai Januari 2025”, karena kentonv adalah pengguna lain. Apakah ini akun alternatif penulis sendiri, atau hanya salah ketik atau salah paham? Edit: saya kemudian sadar sebagian besar tulisan itu adalah kutipan dari README. Seandainya simbol > dan * dipakai untuk memperjelas kutipan, kebingungannya mungkin berkurang. Berikut tautan ke profil kentonv

  • “Saya menganggap LLM sebagai generator rantai Markov yang mewah” dan “Saya terkejut AI bisa menghasilkan kode yang lumayan bagus” bukan dua pendapat yang saling bertentangan. Saya merasa LLM memang sangat berguna, tetapi pada dasarnya tetap lebih dekat ke mesin pembangkit pola. Poin pentingnya adalah level itu ternyata sudah cukup, dan bisa jadi manusia pun secara struktural tidak terlalu berbeda

  • Akhir-akhir ini saya lebih skeptis daripada pro-AI, tetapi bagaimanapun saya tetap mencoba memasukkan AI ke workflow saya. Dalam praktiknya, menjelaskan sesuatu justru terasa lebih sulit, jadi sering kali lebih mudah dikerjakan sendiri. Tidak terlalu menyenangkan juga, tetapi karena ini alat “masa depan”, saya rasa bijak untuk mempelajarinya. Menurut saya tooling AI yang sesungguhnya masih berada di tahap awal. Saya tetap tertarik melihat contoh-contoh UX yang menarik ke depannya

  • Ada petunjuk untuk langsung melihat riwayat commit tentang bagaimana Claude diberi prompt di awal dan bagaimana kode benar-benar dihasilkan. Disediakan tautan langsung ke halaman commit pertama. Instruksinya banyak yang jelas dan spesifik, dan contoh commit 1, contoh commit 2, dan lainnya juga layak dilihat

• Kutipan dari commit isu di commit Cloudflare workers-oauth-provider. Claude membuat bug pada commit sebelumnya, lalu beberapa kali dicoba diperbaiki lewat prompt tetapi terus gagal. Pada akhirnya manusia yang memperbaikinya langsung, dan bahkan mendokumentasikan isu spesifikasi OAuth 2.1 di README. Pengalaman seperti ini sangat relate dengan pengalaman pribadi saya dalam memakai AI. Sering terlihat bahwa AI melaju baik sampai setengah jalan, lalu kesulitan menyelesaikan sisanya

  • Saya menyoroti bahwa AI sering mampu mengerjakan hingga tengah jalan, tetapi sekali membuat kesalahan, setelah itu semuanya bisa rusak. Saat menemukan kesalahan, kita harus segera menulis ulang prompt dari awal percakapan dan memulai lagi. Setelah sekali salah, hasil berikutnya cenderung terus salah meskipun sudah dicoba diluruskan. Karena itu, semua hal perlu dijelaskan dengan jelas dalam pesan awal yang benar agar hasil dari awal tidak mengulang kesalahan yang sama

  • Untuk mengurangi masalah seperti ini, akan sangat membantu jika ada test atau spec yang jelas lalu AI diminta menyelesaikannya. Beberapa bulan lalu, AI masih butuh waktu lama untuk memecahkan puzzle spesifikasi seperti ini, dan hasilnya juga kualitasnya lebih rendah daripada jawaban cepat. Tetapi belakangan performa model meningkat pesat sehingga pekerjaan seperti ini jadi cukup menarik, dan kegunaannya naik dalam kasus yang bisa dispesifikasikan. Secara pribadi saya merasa sonnet 3.7 adalah lompatan besar dibanding 3.5, dan Gemini 2.5 Pro lebih mengesankan lagi. sonnet 4 membuat lebih sedikit kesalahan, tetapi dari sudut pandang software engineering (merapikan requirement, mengeksplorasi solusi teknis, mendesain arsitektur, menulis user story dan spesifikasi, serta menulis kode), AI tetap harus diarahkan dengan baik untuk menghasilkan output berkualitas. Selain itu, efeknya makin maksimal jika kita menambahkan contoh yang bagus ke dalam konteks AI. Belakangan saat membuat aplikasi dengan OpenAI Realtime API, awalnya saya gagal total, tetapi setelah menambahkan dua halaman dokumentasi dan satu proyek demo ke workspace, saya langsung mendapat hasil yang diinginkan (meski dalam kasus saya API-nya sebenarnya harus dipakai dengan cara berbeda)

  • Pada commit baris 163–172, saya menemukan klaim yang jelas-jelas tidak sesuai fakta atau bisa ditafsirkan berbeda tergantung implementasi A/S (authorization server). Authorization server milik Auth0 punya pengaturan “leeway” dengan mempertimbangkan kondisi jaringan, tetapi beberapa authorization server lain jauh lebih ketat. Karena detail desain berbeda di tiap implementasi, saya rasa peluang LLM untuk mengimplementasikan ini dengan aman hanya berdasarkan standar (RFC) dan open source publik pada akhirnya tetap membutuhkan tingkat supervisi manusia yang setara dengan membuatnya sendiri

  • Saya penasaran dengan hasil riset jangka panjang tentang apakah alat berbasis LLM benar-benar menghemat tenaga kerja yang dibutuhkan, atau hanya memberi ilusi produktivitas

  • Dari pengalaman seperti ini, saya melihat alat AI sebenarnya tidak benar-benar memahami sesuatu, melainkan menghasilkan output emergent dari kumpulan data pola yang sangat besar

• Masa depan AI coding kemungkinan bukan fantasi ala LinkedIn/X bahwa software engineer akan hilang dan pebisnis tinggal menekan tombol lalu semuanya selesai, melainkan engineer terampil menggunakan AI untuk membuat sebagian kode lalu meninjaunya dan mengujinya dengan cermat. Pertanyaan yang benar-benar penting adalah: “Apakah kentonv bisa membuat pustaka ini lebih cepat sendirian tanpa AI?”

  • Membuat pustaka ini bersama AI memakan waktu beberapa hari. Jika dikerjakan sendiri secara manual, kemungkinan akan butuh beberapa minggu, mungkin bahkan beberapa bulan. Namun ini adalah kasus yang sangat ideal. Hal ini bisa terjadi karena ada standar yang jelas, spesifikasi API yang jelas, dan platform yang sudah dikenal dengan baik. Saat mencoba memakai AI untuk mengubah Workers Runtime itu sendiri, penghematan waktunya tidak terlalu terasa. Namun untuk codebase orang lain yang tidak saya kenal, AI benar-benar sangat membantu. Sekarang jadi lebih mudah masuk ke “ruang eksplorasi” codebase yang asing dan kompleks; dulu saya mungkin akan menghindarinya, sekarang saya bisa lebih mudah membuat perubahan yang saya butuhkan sendiri

  • Untuk pertanyaan apakah akan lebih cepat bila dibuat sendiri tanpa AI, saya cukup yakin jawabannya tidak. Dengan alat yang kita miliki sekarang dan know-how yang terus membaik, dalam 3–6 bulan ke depan coding solusi baru secara langsung dengan AI kemungkinan akan menjadi lebih cepat. Namun saya rasa penting untuk punya codebase yang terdokumentasi baik, strukturnya jelas, dan memiliki feedback loop cepat (lint/unit test yang bagus). Kita sedang bergerak ke arah itu

  • Dari pengalaman saya, jika AI membuatkan sebagian kode, kita tetap harus melakukan review dan testing yang sangat teliti, dan proses ini justru <i>lebih lambat</i> daripada menulis sendiri. Jadi pada tahap sekarang AI belum banyak membantu. Seperti pepatah bahwa asisten yang salah lebih buruk daripada tidak punya asisten, saat ini AI masih seperti “asisten yang buruk” itu

  • Jika strukturnya adalah “engineer berpengalaman membuat sebagian kode dengan AI lalu mengujinya dengan sangat teliti”, bukankah pada akhirnya kita hanya butuh 2 orang, bukan 20 kentonv? Apakah akan terus ada pekerjaan untuk 18 orang sisanya? Contoh dari penulis adalah proyek yang sulit secara teknis, tetapi saya penasaran apa yang akan berubah pada pengembangan aplikasi LoB yang lebih biasa-biasa saja

  • Jika engineer berpengalaman hanya melakukan review dan testing dengan teliti, lalu semua posisi junior developer digantikan AI, dari mana nantinya developer berpengalaman akan muncul? Saya tetap melihat ada nilai besar pada pekerjaan sederhana dan repetitif seperti itu

• Menarik melihat beragam sudut pandang dan opini seperti ini. Sebagai pemimpin di bidang keamanan internet, Cloudflare memperlihatkan upaya menghubungkan dunia dengan pendekatan ‘vibe coding’ yang baru, dan saya bersyukur untuk itu. Saya merasa prompt AI, kode, dan semacamnya memberi dorongan bagi developer lain untuk lebih bersemangat mengeksplorasi pemrograman. Bagi saya, vibe programming adalah sarana yang sangat berarti karena membantu saya keluar dari perasaan depresi dan memungkinkan saya coding dengan cara yang terasa akrab. Saya berharap pengalaman seperti ini juga membantu orang lain. Saya membayangkan generasi sekarang dan mendatang akan memakai pendekatan semacam ini. Namun, saya juga merasa kita perlu membahas bahwa pendekatan ini bisa berkaitan dengan kesehatan mental atau persoalan psikologis. Pada akhirnya alat-alat seperti ini adalah sarana bantu bagi manusia, dan kita perlu memikirkan bagaimana memakainya agar kita bisa tumbuh dengan semangat. Saya berharap lebih banyak contoh di dunia open source yang memperlihatkan bukan hanya kemampuan teknis, tetapi juga logika dan pendekatan proyek yang penuh pertimbangan. Sekali lagi pujian untuk Cloudflare

• Dikumpulkan beberapa contoh pertukaran prompt yang representatif. Dalam contoh transkrip prompt, bahkan biaya riilnya (total $6.45) juga dibuka. Ada juga petunjuk ke materi seperti commit terkait 1, commit 2, dan lainnya. Mengejutkan bahwa informasi tentang pengalaman nyata workflow AI yang benar-benar baik (terutama dari para ahli) tidak banyak terlihat karena tenggelam oleh hype. Selain todo list, saya penasaran dengan contoh live coding yang nyata. Tulisan antirez dan tptacek juga tampaknya layak dilihat (contoh antirez, tulisan tptacek)

  • Saya tidak melacaknya secara persis, tetapi saya perkirakan biaya penggunaan Claude sekitar $50. Dibanding waktu yang berhasil dihemat, itu biaya yang nyaris tidak berarti

• Saya rasa “vibecoding” pada akhirnya tidak akan bertahan. Verifikasi dari programmer yang hebat dan perbaikan bug tetap dibutuhkan, dan ada bug yang tidak bisa diperbaiki AI. Pada akhirnya alat seperti ini hanyalah alat bantu untuk mempercepat orang yang memang sudah paham betul pekerjaannya. Untuk homepage yang benar-benar dasar mungkin iya, tetapi alat yang mengotomatiskan hal seperti itu sudah ada sejak bertahun-tahun lalu

  • Saat ini vibecoding paling cocok untuk pekerjaan dengan taruhan rendah. GUI, aplikasi CRUD, eksperimen sekali pakai, dan hal-hal yang memberi kekuatan baru bagi orang yang tidak punya banyak daya—di situlah kegunaannya tinggi. Kasus ini menurut saya bukan vibecoding, melainkan LLM-assisted coding

  • Dalam praktiknya, saya merasa istilah vibecoding sering dipakai seperti orang-orangan sawah untuk menyerang. Bukankah kebanyakan orang yang memakai kode hasil LLM lalu sedikit mengeditnya juga tetap bisa disebut vibe coding?

• Saya sangat berterima kasih karena OP membuka bukan hanya kode yang dihasilkan AI tetapi juga prompt-nya. Secara pribadi, saat mencoba mengembangkan kode non-web dengan LLM—terutama akhir-akhir ini implementasi .NET untuk merekayasa balik SAP ABAP dan menyesuaikan datanya ke Snowflake—saya terus bermasalah dengan halusinasi. Karena orang lain sering bercerita tentang banyak kisah sukses, saya mengira masalahnya ada pada prompt saya sendiri, tetapi setelah melihat contoh yang dibuka kali ini, saya sadar saya juga tidak terlalu jauh. Saya menilai alasan LLM tidak terlalu cocok untuk saya adalah karena masalah yang saya buat agak langka dan baru. Jika bukan target yang banyak dipelajari seperti kasus OAuth yang terbuka di GitHub, LLM kesulitan mengikutinya

• Kode yang repetitif seperti ini, yang sudah diimplementasikan ratusan kali, sangat cocok untuk AI. Seluruh kodenya sekitar 1200 baris saja, jadi skalanya kecil. Justru agak mengejutkan bahwa dengan AI pun tetap butuh lebih dari 2 hari

• Dalam beberapa bulan terakhir saya menjalankan proyek greenfield sendiri dengan Claude lewat Cursor, dan kesan saya adalah: pertama, produktivitas meningkat luar biasa. Kedua, saya jauh lebih lelah secara mental dibanding sebelumnya. Ketiga, dalam waktu singkat saja alat-alat ini mulai berkembang sangat cepat, dan dua efek tadi juga ikut makin kuat

  • Pengalaman saya sama persis, dan developer lain yang saya kenal juga demikian. LLM assisted coding memang sangat membantu meningkatkan produktivitas, tetapi konsumsi energinya juga jauh lebih besar. Rasanya bahkan aneh

  • Saya bertanya soal bagian “jadi lebih melelahkan” itu. Saya memakainya lebih seperti “pair programming” dengan agen saya (Devstral) dibanding cara lama, dan review kode jauh lebih mudah daripada harus mengetik seluruh kode sendiri. Dari sisi time wise ini keuntungan besar. Dalam vibe coding, konteks codebase hilang sehingga review di belakang dan hambatan masuk jadi jauh lebih besar. Sebaliknya, dalam pair programming konteks dibangun sambil berjalan, sehingga review terasa jauh lebih cepat

  • Saya justru kebalikannya. AI mengurus semua detail kecil yang merepotkan, jadi saya merasa jauh lebih lega. Saya jadi bebas fokus pada tujuan tingkat tinggi seperti arsitektur

• Cukup lucu rasanya melihat perusahaan seperti Cloudflare memunculkan error "Too Many Requests"

  • Saya juga begitu