Haruskah aku mengetahui masa lalumu ?

Tentu saja, agar kau tau siapa aku sebenarnya., setelah itu lupakan lah..

– Dolen & Meong

Masa Lalu OAuth

OAuth/OAuth 2 berawal dari sebuah proses panjang agar bisa menjadi sebuah standar otorisasi.

Idenya berawal dari sebuah fitur keren yang mungkin dianggap remeh temeh di sebuah aplikasi.

Fiturnya berupa ketika kita mendaftar ke sebuah aplikasi dengan alamat email kita, kemudian ada fitur untuk menambahkan teman-teman kita dari address book email kita tadi atau dari email kita yang lain.

Contohnya, kalau ada yang masih sempat memakai www.friendster.com yang lama (yang layanan sosial seperti facebook), maka pasti akan ingat bahwa setelah mendaftar, maka ada pilihan untuk meng-invite teman-teman yang ada di address book teman kita yang ada di yahoomail.com, gmail.com, hotmail.com dan juga file csv.

Caranya adalah dengan menampilkan form login username dan password sesuai dengan pilihan alamat email yang kita inginkan agar address book nya di-invite.

Apa yang sebenarnya terjadi ?

Yang terjadi adalah:

Kita memasukkan username dan password ke aplikasi tersebut. Kemudian aplikasi akan menyimpan data tersebut untuk sementara agar dibantu untuk login menggunakan username dan password kita ke aplikasi layanan email yang kita pilih. Misalnya login ke yahoomail.com, gmail.com, hotmail.com, dll .

Setelah berhasil login, maka aplikasi tersebut akan membaca alamat-alamat email yang ada di address book kita, dan kemudian mengirimkan email invitation ke email-email tersebut.

Fitur ini keren dan banyak aplikasi yang menggunakannya juga.

Dengan fitur ini aplikasi bisa berkembang cepat dan banyak mendapatkan pengguna baru.

Tetapi apakah aman ?

Disinilah letak masalahnya.

Informasi username dan password yang kita informasikan melalui aplikasi tersebut rentan disalahgunakan.

Walaupun dalam “syarat dan ketentuan” nya, aplikasi tersebut berjanji untuk tidak menyalahgunakan informasi tersebut, tetapi siapa yang tahu di kemudian hari. Kita pun tidak tahu pasti bagaimana informasi rahasia kita tersebut diproses dan dipergunakan.

Walaupun kita yakin account kita di yahoomail.com, gmail.com, hotmail.com, dll mempunyai tingkat keamanan yang tinggi, tetapi kita tidak bisa memastikan tingkat keamanan dari aplikasi lain (third party application) yang menggunakan fitur keren diatas, yang berperan sebagai perantara login kita. Artinya kita mempercayakan informasi rahasia kita ke aplikasi yang tidak sepenuhnya kita percayai dan kita tidak yakin keamanannya.

Dan hal ini juga tentunya sangat berbahaya dan akan rentan bagi aplikasi yang account login kita berada di dalamnya. Berbahaya dari sisi data-data apa saja yang tersimpan, dan juga berbahaya bagi kredibilitas keamanan aplikasi login itu sendiri.

Orang akan bilang, ternyata gmail.com bisa dihack dengan cara Phising username dan password di aplikasi xxxx.com

atau kita bikin saja aplikasi palsu untuk mendapatkan data-data user gmail.com, yahoomail.com, dll, dengan menambahkan fitur baru form login melalui email atau account mereka yang sudah ada di sosial media lain

Hmmm, sangat beresiko kan !

Apakah reliable ?

Hal ini juga jadi masalah.

Mengutip dari Reliabiliti

Reliabiliti berkaitan dengan kemampuan sistem berperilaku/merespon dengan cara yang sama, stabil, dan konsisten, dan dapat diprediksi sepanjang waktu.

Aplikasi 3rd Party ini sangat bergantung kepada tampilan/API aplikasi lain untuk melakukan login dan mengakses data-data di aplikasi tersebut.

Kenapa tampilan ?, karena dahulu belum ada API yang dibuka oleh aplikasi login yahoomail.com, gmail.com, hotmail.com, sehingga harus melakukan login dengan cara web scraping , yaitu menganalisa sintaks HTML untuk login, dan mengisi formnya untuk bisa login.

Kenapa API ? karena setelah web scraping, ada kemudahan dari sisi aplikasi untuk menggunakan API yang disediakan oleh aplikasi yang menyediakan login.

Terus, pertanyaannya bagaimana kalau tampilan loginnya berubah ? atau API nya berubah ?

Tentu saja aplikasi 3rd Party ini akan kelabakan.

Bukan kewajiban yang mempunyai aplikasi login untuk memberitahukan setiap perubahan tampilan dan perubahan API yang dilakukan olehnya. Kewajiban aplikasi 3rd Party lah memastikan bahwa mereka akan menyesuaikan diri dan code nya setiap ada perubahan di aplikasi login.

Artinya aplikasi login dianggap tidak reliable lagi. Aplikasi login menjadi single point of failure ketika aplikasi lain mencoba mengakses tampilan/API aplikasi login.

Aplikasi login juga akan susah mengontrol informasi username/password yang berada di aplikasi pihak ketiga, ketika pengguna mengubah password nya di aplikasi login. Harus ada mekanisme yang membuat si aplikasi pihak ketiga tahu bahwa password (yang mungkin disimpan oleh aplikasi pihak ketiga) sudah tidak valid lagi.

Lalu apa yang dilakukan ?

Oleh karena aplikasi login menjadi pihak yang mungkin paling dirugikan atau yang paling berkepentingan dalam implementasi fitur keren diatas, maka masing-masing mereka mulai membuat protokol khusus ketika ada aplikasi lain yang ingin mengakses data-data pribadi yang membutuhkan login.

Twitter, Flickr, Gmail, Facebook mulai membuat versi masing-masing untuk protokol delegasi akses API untuk pihak ketiga (3rd party application) yang membutuhkan data-data di aplikasi mereka seperti untuk mengakses teman, address book, foto, timeline, tweet, dll.

Protokol yang berbeda untuk setiap aplikasi login ini membuat bingung juga aplikasi 3rd party, karena mereka harus mengikuti protokol yang berbeda walaupun hampir mirip. Yang mereka butuhkan adalah standar yang jelas untuk kasus ini.

Aplikasi login pun merasakan hal yang sama. Daripada membuat protokol khusus untuk setiap aplikasi, kenapa tidak membuat sebuah standar protokol untuk delegasi akses API untuk aplikasi pihak ketiga. Dengan standar yang disepakati bersama, maka implementasinya pun diharapkan akan lebih seragam dan memudahkan bagi aplikasi pihak ketiga.

Berawal dari OAuth discussion grup tahun 2007, akhirnya dibuatlah spesifikasi formal untuk OAuth 1.0 sebagai protokol standar untuk delegasi akses API untuk aplikasi pihak ketiga.

Protokol OAuth 1.0 dipublikasikan sebagai RFC 5849 pada April 2010.

Lalu dilanjutkan dengan OAuth 2.0 Framework yang dipublikasikan sebagai RFC 6749 pada Oktober 2012.