Post Detail

Membangun aplikasi pada platform apapun tidak bisa dilepaskan dari faktor otentikasi dan otorisasi, kecuali aplikasi tersebut hanya digunakan untuk keperluan sangat terbatas dan mungkin tidak berada di lingkungan yang terkoneksi dengan jaringan. Tulisan ini membahas sedikit pengenalan terkait materi otentikasi serta otorisasi dan bagaimana developer bisa menggunakan otentikasi dan otorisasi tersebut sebagai bagian dari aplikasi yang mereka bangun. Otentikasi dan otorisasi merupakan materi yang sangat kompleks dan merupakan bagian dari keamanan suatu sistem. Artikel ini mengkhususkan pada pengenalan otentikasi serta dan delegasi otorisasi menggunakan OAuth2 serta JWT.

Membangun aplikasi pada platform apapun tidak bisa dilepaskan dari faktor otentikasi dan otorisasi, kecuali aplikasi tersebut hanya digunakan untuk keperluan sangat terbatas dan mungkin tidak berada di lingkungan yang terkoneksi dengan jaringan. Tulisan ini membahas sedikit pengenalan terkait materi otentikasi serta otorisasi dan bagaimana developer bisa menggunakan otentikasi dan otorisasi tersebut sebagai bagian dari aplikasi yang mereka bangun. Otentikasi dan otorisasi merupakan materi yang sangat kompleks dan merupakan bagian dari keamanan suatu sistem. Artikel ini mengkhususkan pada pengenalan otentikasi serta dan delegasi otorisasi menggunakan OAuth2 serta JWT.

Otentikasi dan Otorisasi: Apakah Keduanya Berbeda?

Sebelum masuk ke materi utama, mari kita lihat terminologi yang terkait karena masih banyak terjadi kebingungan dalam hal terminologi ini. Otentikasi, berasal dari bahasa Yunani "authentikos", merupakan aksi untuk mengkonfirmasi / mem-verifikasi identitas menggunakan kredensial tertentu. Dalam konteks hubungan klien-server, jika verifikasi berhasil, maka klien akan mendapatkan token tertentu yang akan selalu dipakai untuk permintaan-permintaan berikutnya ke server. Terkait dengan otentikasi, terdapat protokol untuk otentikasi. Protokol merupakan seperangkat aturan yang dipahami bersama untuk komunikasi antar pihak yang berkomunikasi. Beberapa contoh protokol otentikasi diantaranya adalah OpenID, LDAP, Kerberos, SAML, RADIUS, dan lain-lain.

Setelah proses otentikasi, baru kemudian bisa digunakan protokol maupun framework otorisasi. Otorisasi merupakan digunakan untuk menentukan akses terhadap suatu sumber daya. Suatu sumber daya bisa saja mengijinkan akses ke pemakai anonim (paling sederhana) atau dengan berbagai macam tingkatan akses. Pada lingkungan Internet, otorisasi ini memungkinkan suatu aplikasi untuk mendapatkan otorisasi berupa semua atau sebagian atribut dari pemakai meskipun pemakai tersebut tidak mempunyai account pada aplikasi yang sedang diakses. Atribut tersebut bisa diperolah dari pendelegasian otorisasi dari aplikasi lain. Contoh sederhana adalah pemakai Google yang sudah login ke Google (sudah terotentikasi oleh Google) bisa menggunakan atribut-atributnya di Google untuk otentikasi dan otorisasi di aplikasi lain (misalnya di API.AI - http://api.ai). Setelah login menggunakan "Sign in with Google", pemakai bisa menggunakan kredensialnya di account Google di dalam aplikasi API.AI. OAuth2 merupakan protokol atau framework untuk keperluan otorisasi ini. Contoh lainnya adalah OpenID Connect yang merupakan framework delegasi otorisasi yang dibangun menggunakan OAuth2 di atas protokol otentikasi OpenID.

Masalah yang Akan Dipecahkan

Saat aplikasi sudah besar atau saat membangun aplikasi yang memang dimaksudkan untuk diakses oleh banyak (sekali) pemakai, masalah otentikasi dan otorisasi ini muncul. Bayangkan, bagaimana jika kita mempunyai akses ke 10 aplikasi berbasis Internet yang saling terpisah satu sama lain? Hal yang harus dipastikan adalah pemakai harus mempunyai akses ke 10 aplikasi tersebut dan padad 10 aplikasi tersebut, pemakai akan mengisikan kredensial serta atribut yang sama. Selain muncul masalah redundansi, terdapat juga berbagai macam kerepotan karena harus mengingat kredensial pada 10 aplikasi tersebut. Protokol otentikasi serta framework untuk otorisasi digunakan untuk menangani masalah tersebut: pemakai cukup mempunyai kredensial di satu aplikasi dan jika diperlukan, kredensial tersebut bisa digunakan di aplikasi lainnya (dengan ijin dari pemakai).

SSO (Single Sign-On)

SSO merupakan istilah lain yang terkait dengan masalah yang akan dipecahkan di atas. Meskipun demikian, istilah SSO kadang membingungkan karena ada beberapa pengertian dan keterkaitan. SSO sering digunakan untuk umbrella term untuk segala akses tunggal ke banyak sumber daya. Selain itu ada yang mendefinisikan SSO sebagai akses sekali login untuk mengakses ke lebih dari sumber daya dalam satu domain organisasi yang sama (misalnya aaa.domain.com, bbb.domain.com, dan seterusnya). Istilah untuk ini juga sering disebut Enterprise SSO. Selain itu ada Federated Identity yang digunakan untuk mengacu pada identitas / kredensial pemakai yang tersimpan pada suatu penyedia identitas (identity provider). SSO merupakan subset dari Federated Identity.

OAuth2

Memahami Oauth2

OAuth2 merupakan perkembangan dari OAuth 1. Secara resmi, OAuth2 adalah versi yang sekarang aktif sehingga penyebutan OAuth saat ini juga mengacu ke OAuth2. Informasi tentang pengembangan OAuth2 bisa diperoleh di website esminya yaitu di http://oauth.net. Definisi yang terdapat pada website tersebut adalah sebagai berikut:

OAuth is an open protocol to allow secure authorization in a simple and standard method from the Web, mobile, and desktop application.

OAuth adalan protokol terbuka yang memungkinkan otorisasi aman dengan metode standar dan sederhana dari aplikasi Web, mobile, maupun desktop.

OAuth tidak mempunyai lapisan otentikasi. Ruang lingkup penggunaannya adalah otorisasi. OAuth memungkinkan server untuk mendelegasikan akses yang aman bagi pihak ketiga untuk menggunakan sumber daya terbatas dengan ijin dari pemilik sumber daya.

Proses untuk mengembangkan OAuth dimulai sekitar bulan November 2016 oleh Blaine Cook, Chris Messina, Larry Halff, dan Eran Hammer. Hasil pengembangan ini adalah OAuth 1.0 yang dirilis sebagai standar RFC

5849. Pada tanggal 23 April 2009, masalah "session fixation security flaw" untuk OAuth 1.0 diumumkan. Untuk menutupi flaw tersebut, dirilis OAuth 1.0a.

Spesifikasi yang dikembangkan saat ini adalah OAuth2 (RFC 6749). OAuth2 ini diimplementasikan secara luas oleh berbagai vendor besar seperti Google, Facebook, dan Microsoft sehingga dengan mempunyai account pada vendor-vendor tersebut, kita bisa menggunakan kredensial kita ke berbagai aplikasi lain.

Cara Kerja OAuth2

Secara umum, cara kerja dari OAuth2 tidak rumit. Ada beberapa pihak yang terlibat disini:

1. Pemakai, kita sebut sebagai P
2. Aplikasi yang akan diakses oleh pemakai, kita sebut sebagai A
3. Server tempat kredensial pemakai berada (Twitter, Facebook, Google), kita sebut sebagai S. Proses kerja OAuth2 kurang lebih sebagai berikut:
4. P mengakses A.
5. A memerlukan kredensial dan atribut terbatas dari P dan menanyakan ke P apakah akan mengakses menggunakan account yang ada di S.
6. P menyetujui akses ke A menggunakan kredensial di S.
7. A mengirimkan persetujuan itu ke S.
8. S memverifikasi ke P (mungkin termasuk mengisikan user/password).
9. Setelah otentifikasi terverifikasi, S mengirimkan token ke A
10. A konfirmasi akses ke P dan P bisa menggunakan aplikasi A.

Dari sudut pandang developer, saat akan mengimplementasikan sistem OAuth2 ini ada 2 hal yang harus diperhatikan yaitu registrasi dan proses otorisasi. Terkait dengan dua proses itu, ada beberapa peran yang muncul dalam OAuth2:

1. Aplikasi yang sedang dibangun
2. Server untuk otorisasi
3. Server untuk sumber daya
4. Pemilik sumber daya. Registrasi:
5. Developer melaukan registrasi aplikasi ke ID Provider (Twitter, Facebook, Google). Registrasi ini biasanya melibatkan informasi dasar tentang aplikasi tersebut serta callback beruapa redirect URI untuk redirect setelah selesai otorisasi.
6. Setelah selesai registrasi Client ID dan Client Secret diberikan untuk aplikasi tersebut. Proses Otorisasi:
7. Buat login link / login button yang me-redirect ke server yang menyediakan otorisasi. Data yang dikirim terdiri atas kode, client ID, redirect URL, scope, dan state.
8. Server otorisasi akan memeriksa apakah client ID dikenal atau tidak. Jika dikenal, server akan menanyakan ke pemakai apakah sumber daya boleh didelegasikan ke aplikasi pihak ketiga. Jika diperbolehkan, server akan mengembalikan return code dan state.
9. Aplikasi akan memerika code dan state dan akan melakukan pertukaran code dengan server.
10. Server akan mengembalikan hasil berupa token dan expired time. Token ini yang akan digunakan oleh aplikasi.

JWT (JSON Web Tokens)

Memahami JWT

JWT merupakan spesifikasi yang dirancang untuk keperluan otentikasi dan pertukaran pesan yang aman. Informasi tentang perkembangan JWT bisa diperoleh di http://jwt.io. JWT merupakan spesifikasi standar dan bisa diperoleh di RFC 7519. Definisi resmi dari JWT adalah sebagai berikut:

JSON Web Tokens (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verfied and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA

JSON Web Tokens (JWT) adalah standar terbuka (RFC 7519) yang mendefinisikan cara yang kompak dan bisa dilihat pada isinya untuk mentransmisikan informasi secara aman antar berbagai pihak sebagai obyek JSON. Informasi ini bisa diverifikasi dan dipercaya karena ditandatangani secara digital. JWT bisa ditandatangani menggunakan algoritma rahasia (HMAC) atau pasangan kunci publik/privat menggunakan RSA.

Cara Kerja JWT

Pesan yang akan dikirimkan akan diserialisasikan dalam bentuk obyek JSON. Struktur JWT terdiri atas 3 bagian, dipisahkan oleh tanda titik (.): xxx.yyy.zzz. Berikut ini adalah penjelasan masing-masing.

Header (xxx)

{ "typ": "JWT", "alg": "HS256" }

Payload (yyy)

Merupakan JWT claims, bisa berupa 3 claims: registered, public, dan private claims. Registered, terdiri atas:

1. iss: issuer dari token
2. sub: subject dari token
3. aud: audience dari token.
4. exp: waktu expired dari token, harus lebih dari tanggal sekarang.
5. nbf: waktu sebelum JWT diterima untuk diproses.
6. iat: waktu JWT dikeluarkan
7. jti: identifier unik untuk JWT. Public, bisa didefinisikan sekehendak hati atau mengikuti IANA di http://www.iana.org/assignments/jwt/jwt.xhtml. Private, merupakan claim yang bersifat custom dan merupakan kesepakatan antar pihak yang menerima dan yang mengirimkan.

Signature (zzz)

Berisi header + payload + secret pass, dienkripsi menggunakan algoritma yang terdapat pada header (nilai dari alg).

Pustaka Terkait JWT

JWT sudah diimplementasikan oleh banyak peranti pengembangan. Beberapa diantaranya bisa dilihat di http://jwt.io/#libraries.

OAuth2 dan Spesifikasi Terkait

Beberapa spesifikasi yang terkait, diantaranya adalah:

1. OAuth2 dan JWT: JWT bisa digunakan sebagai token untuk pertukaran, otentikasi client (JWT profile), dan access token (RFC 7800).
2. OAuth2 dan OpenID Connect: OpenID Connect merupakan protokol otentikasi dan otorisasi di atas OpenID dan OAuth2 menggunakan token ID yang bisa dibangun menggunakan JWT.
3. OAuth2 dan Gluu (http://gluu.org): Gluu server merupakan IAM (Identity Access Management) untuk mengelola identitas dan sumber daya menggunakan OAuth2, SAML, OpenID Connect, UMA, dan lain-lain.

Sumber : https://refactory.id/post/3-memahami-oauth2-dan-jwt-untuk-delegasi-otorisasi