Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

OAuth 2.0 - Yang Baik, Yang Buruk & Yang Jelek

by
Length:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Zadip (you can also view the original English article)

Di dunia yang didominasi oleh media sosial, sulit untuk tidak menemukan aplikasi klien yang Anda gunakan untuk mengakses sumber daya terbatas di beberapa server lain, misalnya, Anda mungkin telah menggunakan aplikasi berbasis web (seperti NY Times) untuk berbagi artikel berita yang menarik di dinding Facebook Anda atau tweet tentang hal itu. Atau, Anda mungkin telah menggunakan aplikasi iPhone Quora yang mengakses profil Facebook atau Google+ Anda dan menyesuaikan hasilnya berdasarkan data profil Anda, seperti menyarankan untuk menambahkan/mengundang pengguna lain ke Quora, berdasarkan daftar teman Anda. Pertanyaannya adalah, bagaimana aplikasi ini mendapatkan akses ke akun Facebook, Twitter, atau Google+ Anda dan bagaimana mereka dapat mengakses data rahasia Anda? Sebelum mereka dapat melakukannya, mereka harus menyajikan beberapa bentuk kredensial otentikasi dan otorisasi hibah ke server sumber daya.


Pengantar OAuth 2.0

OAuth sering digambarkan sebagai kunci valet untuk web.

Sekarang, akan sangat tidak keren untuk membagikan kredensial Facebook atau Google Anda dengan aplikasi klien pihak ketiga yang hanya perlu diketahui tentang Teman Anda, karena itu tidak hanya memberikan akses tak terbatas dan tidak diinginkan ke akun Anda, tetapi juga memiliki kelemahan yang melekat terkait dengan kata sandi. Di sinilah OAuth ikut bermain, karena menguraikan kerangka akses-delegasi/otorisasi yang dapat digunakan tanpa perlu berbagi kata sandi. Untuk alasan ini, OAuth sering digambarkan sebagai kunci valet untuk web. Hal ini dapat dianggap sebagai kunci khusus yang memungkinkan akses ke fitur terbatas dan untuk jangka waktu terbatas tanpa memberikan kendali penuh, seperti kunci valet untuk mobil memungkinkan petugas parkir untuk mengemudikan mobil untuk jarak pendek, memblokir akses ke bagasi dan ponsel on-board.

Namun, OAuth bukanlah konsep baru, tetapi standarisasi dan kebijaksanaan gabungan dari banyak protokol yang mapan. Yang juga patut dicatat adalah bahwa OAuth tidak hanya terbatas pada aplikasi media sosial, tetapi menyediakan cara standar untuk berbagi informasi secara aman di antara berbagai jenis aplikasi yang mengekspos API mereka ke aplikasi lain. OAuth 2.0 memiliki prosa yang sepenuhnya baru dan tidak kompatibel dengan spesifikasi pendahulunya. Setelah mengatakan itu, akan lebih baik untuk terlebih dahulu mencakup beberapa kosakata dasar OAuth2.0 sebelum menyelam ke rincian lebih lanjut.

  • Resource Owner : Suatu entitas yang mampu memberikan akses ke sumber daya yang dilindungi. Sebagian besar waktu, itu adalah pengguna akhir.
  • Client : Aplikasi yang membuat permintaan sumber daya yang dilindungi atas nama pemilik sumber daya dan dengan otorisasinya. Ini bisa berupa aplikasi berbasis server, ponsel (asli) atau desktop.
  • Resource Server : Server yang menghosting sumber daya yang dilindungi, mampu menerima dan menanggapi permintaan sumber daya yang dilindungi.
  • Authorization Server : Server mengeluarkan hibah/token akses ke klien setelah berhasil mengautentikasi pemilik sumber daya dan memperoleh otorisasi.
  • Access Token: Token akses adalah kredensial yang disajikan oleh klien ke server sumber daya untuk mengakses sumber daya yang dilindungi. Ini biasanya string yang terdiri dari ruang lingkup khusus, umur dan atribut akses lainnya dan itu sendiri dapat berisi informasi otorisasi dengan cara yang dapat diverifikasi.
  • Refresh Token : Meskipun tidak diwajibkan oleh spesifikasi, token akses idealnya memiliki waktu kedaluwarsa yang dapat berlangsung dari beberapa menit hingga beberapa jam. Setelah token akses kedaluwarsa, klien dapat meminta server otorisasi untuk menerbitkan token akses baru menggunakan token penyegaran yang dikeluarkan oleh server otorisasi.

Apa yang Salah Dengan OAuth 1.0?

Kelemahan utama OAuth 1.0 adalah kompleksitas inheren yang diperlukan untuk menerapkan spesifikasi.

Tidak ada yang benar-benar! Twitter masih berfungsi dengan baik dengan OAuth 1.0 dan baru saja mulai mendukung sebagian kecil dari spesifikasi 2.0. OAuth 1.0 merupakan spek pemikiran yang baik dan memungkinkan pertukaran informasi rahasia secara aman tanpa biaya tambahan yang dikenakan oleh SSL. Alasan mengapa kita perlu merubah sebagian besar didasarkan pada kompleksitas yang dihadapi dalam mengimplementasikan spesifikasi. Berikut adalah beberapa area di mana OAuth 1.0 gagal mengesankan:

  • Signing Every Request : Setelah klien menghasilkan tanda tangan pada setiap permintaan API dan memvalidasi mereka di server setiap kali permintaan diterima, terbukti menjadi kemunduran besar bagi pengembang, karena mereka harus mengurai, menyandikan dan menyortir parameter sebelum membuat permintaan. OAuth 2.0 menghapus kerumitan ini hanya dengan mengirim token melalui SSL, memecahkan masalah yang sama di tingkat jaringan. Tidak ada tanda tangan yang diperlukan dengan OAuth 2.0.
  • Addressing Native Applications : Dengan evolusi aplikasi asli untuk perangkat seluler, aliran berbasis web OAuth 1.0 tampaknya tidak efisien, mengharuskan penggunaan agen pengguna seperti Peramban Web. OAuth 2.0 telah mengakomodasi lebih banyak aliran yang secara khusus sesuai untuk aplikasi asli.
  • Clear Separation of Roles : OAuth 2.0 memberikan pemisahan peran yang sangat dibutuhkan untuk server otorisasi yang mengautentikasi dan mengesahkan klien, dan server sumber daya yang menangani panggilan API untuk mengakses sumber daya yang dibatasi.

OAuth 2.0 dalam Kedalaman

Sebelum memulai protokol, klien harus mendaftar dengan server otorisasi dengan menyediakan jenis kliennya, URL pengalihannya (di mana ia ingin server otorisasi untuk mengalihkan ke setelah pemilik sumber daya memberikan atau menolak akses) dan informasi lain yang diperlukan oleh server dan pada gilirannya, diberikan pengenal klien (client_id) dan rahasia klien (client_secret). Proses ini dikenal sebagai Pendaftaran Klien. Setelah mendaftar, klien dapat mengadopsi salah satu alur berikut untuk berinteraksi dengan server.

Berbagai Aliran OAuth

OAuth 2.0 membawa sekitar lima aliran baru ke meja dan memberikan pengembang fleksibilitas untuk menerapkan salah satunya, tergantung pada jenis klien yang terlibat:

  • User-Agent Flow : Cocok untuk klien yang biasanya diterapkan di agen pengguna (misalnya, klien yang berjalan di dalam browser web) menggunakan bahasa scripting seperti JavaScript. Sebagian besar digunakan oleh aplikasi asli untuk seluler atau desktop, memanfaatkan browser yang tertanam atau eksternal sebagai agen pengguna untuk otorisasi dan menggunakan otorisasi Implicit Grant.
  • Web Server Flow : Ini menggunakan hibah Kode Otorisasi dan merupakan aliran berbasis pengalihan yang memerlukan interaksi dengan agen pengguna akhir pengguna. Dengan demikian, ini paling cocok untuk klien yang merupakan bagian dari aplikasi berbasis web-server, yang biasanya diakses melalui browser web.
  • Username and Password Flow : Digunakan hanya ketika ada kepercayaan tinggi antara klien dan pemilik sumber daya dan ketika arus lainnya tidak layak, karena melibatkan transfer kredensial pemilik sumber daya. Contoh klien dapat menjadi sistem operasi perangkat atau aplikasi yang sangat istimewa. Ini juga dapat digunakan untuk memigrasikan klien yang ada menggunakan skema Autentikasi Dasar atau Integrasi HTTP ke OAuth dengan mengonversi kredensial yang disimpan ke token akses.
  • Assertion Flow: Klien Anda dapat menyajikan pernyataan seperti Pernyataan SAML ke server otorisasi sebagai pertukaran untuk token akses.
  • Client Credentials Flow : OAuth terutama digunakan untuk akses yang didelegasikan, tetapi ada beberapa kasus ketika klien memiliki sumber daya atau sudah diberi akses yang didelegasikan di luar aliran OAuth yang khas. Di sini Anda hanya bertukar kredensial klien untuk token akses.

Mendiskusikan setiap aliran secara mendetail akan berada di luar cakupan artikel ini dan saya lebih baik merekomendasikan membaca spec untuk informasi aliran mendalam. Tetapi untuk merasakan apa yang terjadi, mari kita gali lebih dalam salah satu aliran yang paling banyak digunakan dan didukung: Web Server Flow.

Alur Server Web

Karena ini adalah aliran berbasis pengalihan, klien harus dapat berinteraksi dengan agen pengguna pemilik sumber daya (yang dalam banyak kasus adalah browser web) dan karenanya biasanya cocok untuk aplikasi web. Diagram di bawah ini adalah pandangan mata burung tentang bagaimana pengguna akhir (atau pemilik sumber daya) menggunakan aplikasi klien (aplikasi berbasis web-server dalam kasus ini) untuk mengotentikasi dan mengotorisasi dengan server otorisasi, untuk mengakses sumber daya yang dilindungi oleh server sumber daya.

webserverflow

Autentikasi & Otorisasi Klien

Klien, atas nama pemilik sumber daya, memulai aliran dengan mengalihkan ke titik akhir otorisasi dengan parameter response_type sebagai code, pengidentifikasi klien, yang diperoleh selama pendaftaran klien, URL pengalihan, lingkup yang diminta (opsional) dan lokal keadaan (jika ada). Untuk memahami cara kerjanya, inilah tangkapan layar tentang bagaimana permintaan/tanggapan umum akan terlihat seperti:

step1Request

Ini biasanya menghadirkan pemilik sumber daya dengan antarmuka web, tempat pemilik dapat mengautentikasi dan memeriksa apa yang dapat dilakukan semua izin yang dapat digunakan aplikasi klien atas nama pemilik.

allowAccess

Dengan asumsi bahwa pemilik sumber daya memberikan akses ke klien, server otorisasi mengalihkan agen pengguna kembali ke klien menggunakan URL pengalihan yang diberikan sebelumnya, bersama dengan kode otorisasi seperti yang ditunjukkan oleh tanggapan di bawah ini.

step1Response

Menukan Otoritasi Kode untuk  Token

Klien kemudian memposting ke titik akhir otorisasi lain dan mengirimkan kode otorisasi yang diterima pada langkah sebelumnya, bersama dengan URL pengalihan, pengenal klien dan rahasianya, diperoleh selama pendaftaran klien dan parameter grant_type harus ditetapkan sebagai authorization_code.

step2Request

Server kemudian memvalidasi kode otorisasi dan memverifikasi bahwa URL pengalihan sama dengan di langkah sebelumnya. Jika berhasil, server membalas kembali dengan token akses dan secara opsional, token penyegaran.

step2Response

Meminta Sumber Daya Terbatas Menggunakan Token Akses

Klien sekarang dapat menggunakan API yang disediakan oleh implementasi dan dapat meminta sumber daya server untuk sumber daya terbatas dengan meneruskan token akses di header Otorisasi permintaan. Contoh permintaan CURL ke Google Blogger API untuk mendapatkan blog, mengingat pengenalnya, akan terlihat seperti ini:

Perhatikan bahwa kami telah menambahkan token Akses sebagai header Otorisasi dalam permintaan dan juga lolos token dengan menyertakannya dalam tanda kutip tunggal, karena token mungkin berisi karakter khusus. Perlu diingat bahwa keluar dari token akses hanya diperlukan saat menggunakan curl. Ini menghasilkan pengiriman permintaan berikut:

step3Request

Server sumber daya kemudian memverifikasi kredensial yang diteruskan (token akses) dan jika berhasil, membalas kembali dengan informasi yang diminta.

step3Response

Contoh-contoh ini adalah milik OAuth2.0 Playground dan khas untuk cara Google menerapkan spesifikasi. Perbedaan dapat diamati ketika mencoba aliran yang sama dengan penyedia lain (seperti Facebook atau Salesforce) dan ini adalah tempat masalah interoperabilitas merayap masuk, yang kita diskusikan sedikit kemudian.

Akses Token Refreshing

Meskipun tidak diwajibkan oleh spesifikasi, tetapi biasanya token akses hanya berumur pendek dan datang dengan waktu kedaluwarsa. Jadi ketika token akses kedaluwarsa, klien mengirim token penyegaran ke server otorisasi, bersama dengan identifier klien dan rahasianya, serta parameter grant_type sebagai refresh_token.

step4Request

Server otorisasi kemudian membalas kembali dengan nilai baru untuk token akses.

step4Response

Meskipun mekanisme memang ada untuk mencabut token pembaruan yang dikeluarkan, tetapi biasanya token penyegaran hidup selamanya dan harus dilindungi dan diperlakukan seperti nilai rahasia.


Apa yang Salah dengan OAuth 2.0?

Hal yang baik

Dengan tingkat adopsi, OAuth 2.0 jelas merupakan peningkatan dari pendahulunya yang misterius. Contoh-contoh komunitas pengembang yang goyah ketika mengimplementasikan tanda tangan 1.0 tidak diketahui. OAuth 2.0 juga menyediakan beberapa jenis hibah baru, yang dapat digunakan untuk mendukung banyak kasus penggunaan seperti aplikasi asli, tetapi USP dari spesifikasi ini adalah kesederhanaannya dari versi sebelumnya.

Bagian yang Buruk

Ada beberapa hal yang longgar dalam spesifikasi, karena gagal untuk menentukan dengan tepat beberapa komponen yang diperlukan atau meninggalkan mereka ke implementasi untuk memutuskan, seperti:

Ujung yang longgar dalam spesifikasi OAuth 2.0 cenderung menghasilkan berbagai macam implementasi yang tidak dapat dioperasikan.

  • Interoperabilitas: Menambahkan terlalu banyak titik ekstensi dalam spesifikasi menghasilkan implementasi yang tidak kompatibel satu sama lain, apa artinya Anda tidak dapat menulis kode generik yang menggunakan Endpoint Discovery untuk mengetahui tentang titik akhir yang disediakan oleh berbagai penerapan dan berinteraksi dengan mereka, Anda harus menulis potongan kode terpisah untuk Facebook, Google, Salesforce, dan sebagainya. Bahkan spec mengakui kegagalan ini sebagai penafian.
  • Short Lived Tokens: Spek tidak mengamanatkan umur dan lingkup token yang diterbitkan. Implementasinya gratis untuk memiliki token hidup selamanya. Meskipun sebagian besar implementasi memberi kita token akses yang berumur pendek dan token penyegaran, yang dapat digunakan untuk mendapatkan token akses baru.
  • Security: Spek hanya "merekomendasikan" penggunaan SSL/TLS saat mengirim token di plaintext melalui kawat. Meskipun, setiap implementasi utama telah menjadikannya sebagai persyaratan untuk memiliki endpoint otorisasi yang aman juga mengharuskan klien harus memiliki URL pengalihan aman, jika tidak maka akan terlalu mudah bagi penyerang untuk menguping komunikasi dan menguraikan token.

Ugly Spat

Butuh IETF sekitar 31 versi draft dan pengunduran diri dari penulis utama/pengembang Eran Hammer dari komite untuk akhirnya mempublikasikan spec. Eran memicu kontroversi dengan menyebut spesifikasi "protokol yang buruk dan kasus kematian oleh seribu luka". Menurutnya, penggunaan token pembawa (mengirim token melalui SSL tanpa menandatanganinya atau verifikasi lainnya) di atas pengguna tanda tangan (atau MAC-Token), digunakan dalam OAuth 1.0 untuk menandatangani permintaan, merupakan langkah yang buruk dan hasilnya pembagian kepentingan antara web dan komunitas perusahaan.


Keterangan Akhir

Spesifikasi pasti meninggalkan banyak titik ekstensi di tempat terbuka, menghasilkan implementasi yang memperkenalkan parameter mereka sendiri, selain apa yang sudah ditetapkan oleh spesifikasi, dan memastikan bahwa penerapan dari penyedia yang berbeda tidak dapat saling bertukar kerja. Tetapi dengan popularitas dan tingkat adopsi dari kerangka ini, dengan setiap pemain besar di kota (Google, Twitter, Facebook, Salesforce, Foursquare, Github, dll.) Menerapkan dan menyesuaikannya dengan cara yang sesuai dengan mereka, OAuth masih jauh dari kegagalan . Bahkan, aplikasi web apa pun yang berencana memaparkan API mereka ke aplikasi web lain harus mendukung beberapa bentuk otentikasi dan otorisasi dan OAuth cocok dengan tagihan di sini.

Untuk Bacaan Lebih Lanjut

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.