IF Notes

Autentikasi dan Otorisasi API

4 min read

Back to IF4031 Arsitektur Aplikasi Terdistribusi

Topic

Questions/Cues

  • Bagaimana alur autentikasi web HTML?

  • Apa itu Session ID & Cookie?

  • Beda Random ID vs Rich Token?

  • Apa itu OAuth 2.0?

  • Bagaimana alur autentikasi REST API?

  • Apa itu JWT?

  • Apa saja komponen JWT?

  • Bagaimana token dikirim ke server?

Reference Points

  • Slides IF4031 Hal 21-28

Autentikasi Antarmuka Web (HTML)

Alur autentikasi tradisional pada web berbasis HTML umumnya menggunakan cookies dan sessions.

  1. Login: Pengguna mengirimkan username dan password.

  2. Verifikasi & Pembuatan Sesi: Server memverifikasi kredensial. Jika valid, server membuat sebuah session (catatan di database server) dan menghasilkan sebuah Session ID yang unik.

  3. Pengiriman Cookie: Server mengirimkan Session ID ini kembali ke browser dalam bentuk cookie.

  4. Request Berikutnya: Untuk setiap request selanjutnya, browser akan secara otomatis menyertakan cookie tersebut. Server menggunakan Session ID dari cookie untuk mencari data sesi dan mengidentifikasi pengguna.

Random ID vs. Rich Token

  • Random Unique ID: Session ID adalah string acak yang tidak bermakna. Server perlu melakukan query ke database pada setiap request untuk mendapatkan informasi pengguna. Ini aman tetapi bisa menjadi bottleneck.

  • Rich Token: Informasi pengguna (seperti user ID, role, waktu kedaluwarsa) disematkan langsung di dalam token itu sendiri. Server tidak perlu query ke database, cukup memverifikasi token. Namun, token ini harus diamankan dengan tanda tangan digital (signature) agar tidak bisa dipalsukan.

Autentikasi Antarmuka RESTful

Untuk API, terutama yang diakses oleh aplikasi non-browser (seperti aplikasi mobile), standar yang umum digunakan adalah OAuth 2.0.

OAuth 2.0

OAuth adalah standar otorisasi, bukan autentikasi. Ia mendefinisikan alur bagaimana sebuah aplikasi (klien) bisa mendapatkan izin untuk mengakses resource milik seorang pengguna tanpa harus mengetahui password pengguna tersebut. Hasil akhir dari alur OAuth adalah sebuah Access Token.

Alur Umum dengan OAuth

  1. Aplikasi Klien meminta otorisasi dari pengguna dan mengarahkannya ke Authorization Server.

  2. Pengguna login di Authorization Server dan menyetujui permintaan akses.

  3. Authorization Server mengembalikan sebuah token ke Aplikasi Klien.

  4. Aplikasi Klien menggunakan token ini untuk mengakses Resource Server (API sebenarnya).

JSON Web Token (JWT)

JWT adalah format standar untuk membuat access token yang bersifat self-contained atau rich token. Token JWT terlihat seperti string panjang yang acak, tetapi sebenarnya terdiri dari tiga bagian yang dipisahkan oleh titik (.), di-encode menggunakan Base64Url.

Komponen JWT

  1. Header: Berisi metadata tentang token, seperti algoritma signature yang digunakan (alg).

  2. Payload: Berisi data sebenarnya, yang disebut claims. Contohnya sub (subject/user ID), name (nama pengguna), dan exp (waktu kedaluwarsa).

  3. Signature: Dihasilkan dengan menggabungkan header dan payload, lalu menandatanganinya dengan sebuah secret key yang hanya diketahui oleh server. Ini digunakan untuk memverifikasi bahwa token tersebut asli dan tidak diubah di tengah jalan.

Pengiriman Token

Klien umumnya mengirimkan access token (seperti JWT) ke server pada setiap request melalui HTTP header Authorization dengan skema Bearer.

Authorization: Bearer <token_jwt_panjang_disini>

Summary

Autentikasi API telah berevolusi dari mekanisme berbasis sesi dan cookie yang umum di web HTML, menjadi alur otorisasi berbasis token yang distandarisasi oleh OAuth 2.0. Dalam sistem modern, Authorization Server mengeluarkan sebuah Access Token, seringkali dalam format JSON Web Token (JWT), setelah pengguna memberikan persetujuan. JWT ini adalah sebuah rich token yang berisi informasi pengguna dan diverifikasi menggunakan signature digital, yang kemudian dikirim oleh klien pada setiap request di header Authorization: Bearer untuk mengakses resource yang dilindungi.

Graph View

Backlinks