OAuth 2.0 dan OpenID Connect: Memahami Autentikasi dan Otorisasi Modern

1. Pendahuluan

Pernahkah Anda “Login dengan Google” atau “Login dengan Facebook” di sebuah aplikasi? Atau mungkin Anda pernah mengizinkan aplikasi pihak ketiga seperti Spotify untuk mengakses playlist Anda di layanan musik lain? Jika ya, Anda sudah berinteraksi langsung dengan OAuth 2.0 dan OpenID Connect (OIDC), dua protokol fundamental yang menggerakkan sebagian besar interaksi digital modern.

Di era aplikasi terdistribusi, microservices, dan API, mengelola identitas pengguna dan otorisasi akses menjadi sangat kompleks. Menggunakan username dan password tradisional untuk setiap layanan tidak hanya merepotkan pengguna, tetapi juga merupakan risiko keamanan besar. Bayangkan jika setiap aplikasi harus menyimpan kredensial login akun Google Anda! 😱 Tentu tidak aman, kan?

Di sinilah OAuth 2.0 dan OpenID Connect berperan penting. Mereka memungkinkan kita untuk membangun sistem yang aman, fleksibel, dan terintegrasi tanpa harus berbagi kredensial sensitif. Sebagai developer, memahami kedua protokol ini bukan lagi pilihan, melainkan keharusan untuk membangun aplikasi web yang robust dan secure.

Artikel ini akan membawa Anda menyelami dunia OAuth 2.0 dan OpenID Connect. Kita akan memahami:

Apa perbedaan fundamental antara autentikasi dan otorisasi.
Bagaimana OAuth 2.0 bekerja untuk delegasi otorisasi.
Bagaimana OpenID Connect menambahkan lapisan autentikasi di atas OAuth 2.0.
Kapan dan bagaimana menggunakan keduanya dalam proyek Anda.

Mari kita mulai!

2. Autentikasi vs. Otorisasi: Apa Bedanya?

Sebelum kita melangkah lebih jauh, mari kita bedakan dua konsep krusial yang sering tertukar: Autentikasi dan Otorisasi.

Autentikasi (Authentication)

🎯 Autentikasi adalah proses memverifikasi siapa Anda. Ini menjawab pertanyaan “Siapa Anda?”. Contoh paling umum adalah login menggunakan username dan password. Ketika Anda memasukkan kredensial, sistem akan memverifikasi apakah Anda benar-benar pengguna yang Anda klaim. Jika berhasil, Anda telah terautentikasi.

Analogi: Bayangkan Anda ingin masuk ke rumah Anda. Autentikasi adalah saat Anda menunjukkan KTP atau menggunakan sidik jari untuk membuktikan bahwa Anda adalah pemilik rumah tersebut.

Otorisasi (Authorization)

🎯 Otorisasi adalah proses menentukan apa yang boleh Anda lakukan setelah Anda terautentikasi. Ini menjawab pertanyaan “Apa yang boleh Anda akses atau lakukan?”. Setelah Anda login ke sebuah aplikasi (terautentikasi), otorisasi menentukan apakah Anda boleh melihat halaman admin, mengedit profil pengguna lain, atau menghapus data.

Analogi: Setelah Anda berhasil masuk ke rumah (terautentikasi), otorisasi adalah saat Anda tahu bahwa Anda boleh masuk ke dapur dan ruang tamu, tetapi tidak boleh masuk ke kamar tidur pribadi orang lain tanpa izin.

Poin Penting: Autentikasi harus terjadi sebelum otorisasi. Anda harus tahu siapa seseorang sebelum memutuskan apa yang boleh dia lakukan.

3. OAuth 2.0: Protokol Delegasi Otorisasi

OAuth 2.0 (Open Authorization) adalah standar industri untuk delegasi otorisasi. Ingat, OAuth 2.0 BUKAN untuk autentikasi (meskipun sering disalahpahami demikian). Ini adalah protokol yang memungkinkan aplikasi pihak ketiga mendapatkan akses terbatas ke resource pengguna di layanan HTTP, tanpa perlu tahu kredensial pengguna.

📌 Konsep Utama dalam OAuth 2.0

Ada empat peran utama dalam alur OAuth 2.0:

Resource Owner: Pengguna akhir yang memiliki data atau resource yang ingin diakses (misalnya, Anda yang punya foto di Google Photos).
Client (Aplikasi Klien): Aplikasi pihak ketiga yang ingin mengakses resource dari Resource Owner (misalnya, aplikasi editor foto yang ingin mengedit foto Anda di Google Photos).
Authorization Server: Server yang mengautentikasi Resource Owner dan mengeluarkan token akses ke Client setelah Resource Owner memberikan persetujuan.
Resource Server: Server yang menyimpan resource yang dilindungi dan dapat menerima permintaan dari Client yang memiliki token akses yang valid (misalnya, Google Photos API).

Analogi Sederhana: Bayangkan Anda ingin seorang teman (Client) mengambilkan buku dari perpustakaan pribadi Anda (Resource Server). Anda tidak ingin memberikan kunci rumah (kredensial) Anda. Jadi, Anda memberikan surat kuasa khusus (Access Token) kepada teman Anda yang hanya mengizinkan dia masuk ke ruang kerja Anda dan mengambil buku tertentu. Surat kuasa ini dikeluarkan oleh Anda sendiri (Authorization Server) setelah teman Anda meminta izin dan Anda setuju (Resource Owner).

💡 Alur Kerja OAuth 2.0 (Authorization Code Flow)

Ada beberapa “Grant Types” atau alur kerja dalam OAuth 2.0, tetapi yang paling umum dan direkomendasikan untuk aplikasi web adalah Authorization Code Flow. Mari kita lihat langkah-langkahnya:

Client Meminta Otorisasi: Aplikasi klien mengarahkan browser Resource Owner ke Authorization Server. Permintaan ini menyertakan client_id (ID unik aplikasi klien), redirect_uri (URL tempat Authorization Server akan mengirim kembali respons), scope (izin yang diminta, misal: read:photos), dan response_type=code.
```
GET https://authorization-server.com/authorize?
    client_id=your-client-id&
    redirect_uri=https://your-app.com/callback&
    scope=read:photos&
    response_type=code
```
Resource Owner Memberikan Persetujuan: Authorization Server mengautentikasi Resource Owner (jika belum login) dan menampilkan halaman persetujuan. Resource Owner melihat izin yang diminta oleh Client dan memutuskan untuk mengizinkan atau menolak.
Authorization Server Mengirim Authorization Code: Jika Resource Owner menyetujui, Authorization Server mengarahkan kembali browser ke redirect_uri Client, menyertakan authorization_code di URL.
```
GET https://your-app.com/callback?code=some-authorization-code
```

Client Menukar Authorization Code dengan Access Token: Client menerima authorization_code dan segera mengirimkannya ke Authorization Server dari backend servernya (bukan dari browser). Permintaan ini juga menyertakan client_id, client_secret (kunci rahasia aplikasi klien), redirect_uri, dan grant_type=authorization_code.

POST https://authorization-server.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=some-authorization-code&
redirect_uri=https://your-app.com/callback&
client_id=your-client-id&
client_secret=your-client-secret

Authorization Server memvalidasi permintaan dan, jika valid, merespons dengan access_token (dan mungkin refresh_token serta expires_in).

{
  "access_token": "a-long-string-of-access-token",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "a-long-string-of-refresh-token",
  "scope": "read:photos"
}

Client Mengakses Resource yang Dilindungi: Dengan access_token, Client dapat membuat permintaan ke Resource Server untuk mengakses resource yang diizinkan. Token ini biasanya dikirim di header Authorization sebagai Bearer Token.
```
GET https://resource-server.com/api/photos
Authorization: Bearer a-long-string-of-access-token
```
Resource Server memvalidasi access_token dan jika valid, mengembalikan resource yang diminta.

✅ Mengapa Authorization Code Flow aman? Karena authorization_code ditukar dengan access_token di backend server Client, client_secret tidak pernah terekspos di browser. Bahkan jika authorization_code dicegat, tanpa client_secret, tidak bisa ditukar dengan access_token.

4. OpenID Connect (OIDC): Lapisan Autentikasi di Atas OAuth 2.0

Seperti yang kita bahas, OAuth 2.0 hanya tentang otorisasi. Ia memberitahu Anda “apa yang boleh dilakukan” oleh aplikasi, bukan “siapa yang sedang melakukan”. Namun, dalam banyak kasus, aplikasi membutuhkan informasi identitas pengguna — siapa yang sedang login?

Di sinilah OpenID Connect (OIDC) masuk. OIDC adalah lapisan identitas sederhana di atas protokol OAuth 2.0. Ini memungkinkan Client untuk memverifikasi identitas pengguna akhir berdasarkan autentikasi yang dilakukan oleh Authorization Server, dan untuk mendapatkan informasi profil dasar tentang pengguna akhir.

💡 ID Token (JWT)

Fitur utama OIDC adalah ID Token. Ini adalah JSON Web Token (JWT) yang berisi informasi identitas pengguna (disebut “claims”) seperti sub (subject/ID unik pengguna), name, email, picture, dll. ID Token ini ditandatangani secara digital oleh Authorization Server, sehingga Client dapat memverifikasi keaslian dan integritasnya.

Contoh struktur ID Token (setelah di-decode):

// Header
{
  "alg": "RS256",
  "kid": "...",
  "typ": "JWT"
}

// Payload (Claims)
{
  "iss": "https://accounts.google.com", // Issuer (Authorization Server)
  "sub": "101234567890123456789",       // Subject (Unique User ID)
  "aud": "your-client-id",              // Audience (Your Client ID)
  "exp": 1678886400,                    // Expiration Time
  "iat": 1678882800,                    // Issued At
  "name": "John Doe",
  "email": "john.doe@example.com",
  "picture": "https://example.com/john.jpg"
}

// Signature
// ...

💡 Alur Kerja OIDC

Alur kerja OIDC sangat mirip dengan OAuth 2.0 Authorization Code Flow, dengan beberapa tambahan kunci:

Client Meminta Autentikasi dan Otorisasi: Client mengarahkan browser Resource Owner ke Authorization Server. Kali ini, scope akan mencakup openid (wajib untuk OIDC) dan mungkin profile, email, dll. response_type juga bisa menyertakan id_token.

GET https://authorization-server.com/authorize?
    client_id=your-client-id&
    redirect_uri=https://your-app.com/callback&
    scope=openid profile email& // Perhatikan scope 'openid' dan lainnya
    response_type=code&
    nonce=random-string-for-security // Nonce untuk mencegah replay attacks

Resource Owner Memberikan Persetujuan: Sama seperti OAuth 2.0.
Authorization Server Mengirim Authorization Code: Sama seperti OAuth 2.0.

Client Menukar Authorization Code dengan Access Token DAN ID Token: Client mengirim authorization_code ke Authorization Server. Kali ini, respons dari Authorization Server akan menyertakan access_token dan id_token.

POST https://authorization-server.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=some-authorization-code&
redirect_uri=https://your-app.com/callback&
client_id=your-client-id&
client_secret=your-client-secret

Respons:

{
  "access_token": "a-long-string-of-access-token",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "a-long-string-of-refresh-token",
  "id_token": "an-encoded-jwt-for-identity", // Ini ID Tokennya!
  "scope": "openid profile email"
}

Client Memverifikasi ID Token dan Menggunakan Access Token: Client memverifikasi tanda tangan ID Token untuk memastikan keasliannya dan memeriksa klaim-klaim di dalamnya (seperti iss, aud, exp, nonce). Setelah divalidasi, Client dapat mengekstrak informasi identitas pengguna dari ID Token dan menggunakannya untuk login pengguna ke aplikasi. access_token tetap digunakan untuk mengakses resource yang dilindungi.

✅ OIDC menyederhanakan autentikasi Dengan OIDC, aplikasi Client tidak perlu mengelola database pengguna atau sistem autentikasi sendiri. Cukup delegasikan ke IdP (Identity Provider) seperti Google atau Facebook, dan terima ID Token yang terverifikasi sebagai bukti identitas.

5. Kapan Menggunakan OAuth 2.0 dan Kapan OIDC?

Memahami perbedaan fungsionalitas utama antara OAuth 2.0 dan OIDC sangat penting untuk memilih protokol yang tepat:

Gunakan OAuth 2.0 (saja):
- Ketika aplikasi Anda perlu mengakses resource yang dilindungi milik pengguna di layanan lain.
- Contoh: Aplikasi photo editor ingin mengakses foto Anda di Google Photos. Aplikasi project management ingin membuat event di Google Calendar Anda.
- Fokusnya adalah otorisasi (izin untuk melakukan sesuatu).
Gunakan OpenID Connect:
- Ketika aplikasi Anda perlu mengautentikasi pengguna dan mendapatkan informasi identitas dasar mereka.
- Contoh: Anda ingin “Login dengan Google” ke aplikasi e-commerce Anda. Aplikasi Anda perlu tahu siapa pengguna yang login dan beberapa detail profilnya (nama, email).
- Fokusnya adalah autentikasi (siapa Anda) dan mendapatkan informasi identitas.

⚠️ Penting: Karena OIDC dibangun di atas OAuth 2.0, kedua protokol ini sering digunakan bersamaan. Dalam skenario “Login dengan Google”, Anda akan menggunakan OIDC untuk mengautentikasi pengguna dan mendapatkan ID Token, dan secara bersamaan Anda mungkin juga mendapatkan access_token melalui OAuth 2.0 untuk mengakses API Google atas nama pengguna (misalnya, untuk membaca profil publik mereka).

6. Implementasi Praktis & Best Practices

Meskipun konsepnya terlihat kompleks, untungnya ada banyak tool dan library yang menyederhanakan implementasi OAuth 2.0 dan OIDC:

Gunakan Library yang Sudah Ada: Hampir semua bahasa pemrograman dan framework populer memiliki library klien OAuth 2.0/OIDC.
- Node.js: passport.js (dengan strategi OAuth/OIDC), oidc-client-js (untuk frontend).
- PHP (Laravel): Laravel Socialite (untuk integrasi dengan penyedia identitas populer).
- Python (Django/Flask): django-oauth-toolkit, Authlib.
- Java (Spring Boot): Spring Security OAuth2.
- Golang: golang.org/x/oauth2.
Penyedia Identitas (IdP) & Solusi Enterprise:
- Google, Facebook, GitHub: Berfungsi sebagai Authorization Server dan IdP.
- Keycloak, Auth0, Okta: Platform identitas dan manajemen akses yang menyediakan Authorization Server dan IdP sendiri, sangat berguna untuk aplikasi enterprise.

✅ Best Practices:

Selalu Gunakan HTTPS: Semua komunikasi antara Client, Authorization Server, dan Resource Server harus melalui HTTPS untuk melindungi token dan kode sensitif dari penyadapan.
Jaga Kerahasiaan client_secret: client_secret adalah kunci rahasia aplikasi Anda. Jangan pernah mengeksposnya di kode frontend atau aplikasi publik (seperti aplikasi mobile atau desktop). Simpan di server backend atau lingkungan yang aman.
Gunakan Authorization Code Flow dengan PKCE: Untuk aplikasi web tradisional dan single-page applications (SPA), Authorization Code Flow adalah yang paling aman. Untuk SPA dan aplikasi mobile yang tidak bisa menjaga client_secret secara aman, gunakan tambahan PKCE (Proof Key for Code Exchange). PKCE melindungi dari serangan authorization code interception bahkan jika client_secret tidak ada.
Validasi ID Token: Jika Anda menggunakan OIDC, pastikan Client Anda memvalidasi ID Token yang diterima:
- Verifikasi tanda tangan digital.
- Pastikan iss (issuer) sesuai dengan Authorization Server yang diharapkan.
- Pastikan aud (audience) berisi client_id aplikasi Anda.
- Periksa exp (expiration time) agar tidak menggunakan token yang sudah kedaluwarsa.
- Verifikasi nonce untuk mencegah replay attacks.
Kelola Refresh Token dengan Hati-hati: Refresh Token digunakan untuk mendapatkan Access Token baru tanpa perlu pengguna login ulang. Simpan Refresh Token dengan sangat aman (biasanya di database server backend) dan pastikan hanya dapat digunakan sekali atau memiliki masa berlaku yang ketat.
Pilih Scope yang Tepat: Minta hanya izin (scope) yang benar-benar dibutuhkan aplikasi Anda. Ini adalah prinsip least privilege dan meningkatkan kepercayaan pengguna.
Error Handling yang Baik: Tangani error dengan elegan, baik dari sisi pengguna maupun sisi developer.

Kesimpulan

OAuth 2.0 dan OpenID Connect adalah pilar penting dalam arsitektur aplikasi modern. OAuth 2.0 memungkinkan delegasi otorisasi yang aman, memungkinkan aplikasi pihak ketiga mengakses resource pengguna tanpa perlu kredensial langsung. Sementara itu, OpenID Connect menambahkan lapisan autentikasi di atas OAuth 2.0, menyediakan cara standar untuk memverifikasi identitas pengguna dan mendapatkan informasi profil dasar melalui ID Token yang terpercaya.

Dengan memahami perbedaan antara autentikasi dan otorisasi, serta cara kerja kedua protokol ini, Anda kini memiliki fondasi yang kuat untuk merancang dan mengimplementasikan sistem keamanan yang robust untuk aplikasi Anda. Gunakan library dan praktik terbaik yang tersedia untuk menyederhanakan implementasi dan memastikan keamanan data pengguna. Jangan takut untuk mendalami lebih jauh, karena keamanan adalah aspek yang tidak bisa ditawar dalam pengembangan web!