Cara menggunakan openid connect in php

Sebagai pengguna yang terdaftar di berbagai layanan internet, atau pun sebagai pekerja yang kesehariannya menggunakan aplikasi yang sudah banyak beralih ke komputasi awan (baca: perangkat lunak & platform berbentuk layanan), mengingat setiap kombinasi user dan password bukanlah hal yang menyenangkan. Di sisi lain, ancaman peretasan yang selalu menghantui membuat pengguna harus merangkai kata sandi yang unik dan kuat di setiap situs yang digunakan.

Metode Single Sign On (disingkat SSO) adalah solusi yang muncul dan banyak didukung secara luas oleh berbagai penyedia layanan di internet. Pada tulisan ini, penulis akan mencoba menguraikan dua standar SSO yang paling banyak didukung saat ini.

Apa itu Single Sign On?

Masih belum familiar bagaimana Single Sign On bekerja? Bisa jadi pembaca sudah menggunakannya tanpa pernah sadar. Misalnya situs detik.com pada gambar di bawah ini yang memiliki opsi untuk masuk atau pun mendaftar menggunakan akun Facebook atau pun Google account.

Dengan kata lain secara pengalaman pengguna, kita dapat diautentikasi menggunakan akun yang sudah kita miliki sebelumnya tanpa perlu membuat nama pengguna baru ataupun kata sandi yang harus kita catat.

Di balik layar, ada tiga pihak yang berperan dalam pertukaran informasi di dalam proses proses autentikasi di atas. Secara umum bisa dijabarkan sebagai berikut:

Teknologi SSO yang paling umum saat ini adalah SAML dan Open ID. Di mana Open ID banyak digunakan oleh layanan yang diakses pengguna umum seperti contoh website di atas. Sedangkan SAML banyak digunakan oleh pekerja di perusahaan/ organisasi enterprise. Apakah yang membedakan?

Secara de-facto organisasi enterprise memiliki standar keamanan yang sangat tinggi terkait autentikasi, di mana proses autentikasi tidak dapat diberikan kepada penyedia identitas pihak ketiga. Selain autentikasi, organisasi enterprise juga memiliki level otorisasi yang berbeda bagi setiap pengguna, dan juga level otorisasi yang berbeda di setiap aplikasi.

Secara eksplisit dari penjelasan diatas, kita dapat memahami bahwa Open ID tidak dipilih karena sifatnya yang terbuka sesuai namanya. Namun hal ini juga menjadi bahasan yang menarik, yaitu bagaimana SAML dapat mendukung fungsi-fungsi autentikasi dan otorisasi yang dibutuhkan oleh organisasi enterprise?

Sesuai judul tulisan ini, kita akan membahas terlebih dahulu SAML dan juga pengaplikasiannya di organisasi enterprise.

SAML (Security Assertion Markup Language)

SAML (dibaca sam-el) adalah protokol SSO standar terbuka yang memberikan fungsi autentikasi dan otorisasi berbasis assertion (penegas) berupa XML. Diperkenalkan pada tahun 2001 dan mendapat pembaruan besar pada tahun 2005 sampai saat ini, yaitu SAML 2.0.

Secara luas SAML menjadi standar yang paling banyak digunakan oleh aplikasi perangkat lunak/ platform berbentuk layanan (SaaS/PaaS) enterprise, sebut saja: Salesforce, Box, Jira, ServiceNow, Github, Workday, Cisco Meraki.

Alur autentikasi SAML

Berikut adalah alur autentikasi dari SAML:

Kita bisa mempraktikkan dengan mengamati alur autentikasi SAML dengan cara memasang pengaya SAML tracer di browser kita, contoh pengaya yang penulis pakai bisa didapat disini: SAML-Tracer.

Di bawah ini adalah hasil trace ketika penulis masuk ke aplikasi Salesforce, yang kemudian mengalihkan halaman ke penyedia identitas Okta.

X.509 Certificate

SAML menggunakan sertifikat yang ditandatangani secara digital sebagai autentikasi. Dapat dilihat pada gambar di atas, X.509 sertifikat yang ditandatangani di POST ke penyedia layanan untuk autentikasi.

Sebagai pengembang aplikasi, bagaimana saya mengadopsi SSO berbasis SAML di aplikasi saya?

Untuk memulai saya menyarankan untuk terlebih dahulu membaca dokumen teknis SAML disini: SAML Tech Overview. Setelah itu, bisa dilanjutkan untuk memilih system stack yang sesuai untuk aplikasi yang dibuat. Berikut adalah beberapa alternatif sumber terbuka yang bisa kamu pakai dari eksplorasi penulis.

1. One Login: SAML toolkit yang mendukung 5 bahasa pemrograman berbeda (PHP, Python, Ruby, Java, .NET).
2. Spring Security: Sebuah SAML Extension untuk bahasa pemrograman Java.
3. Passport SAML: Penyedia autentikasi SAML 2.0 untuk Passport, pustaka autentikasi untuk Node.js

Sebagai arsitek, ataupun konsultan IT bagaimana saya memilih penyedia identitas SSO SAML bagi perusahaan/ aplikasi saya?

Untuk memilih penyedia identitas, bisa dimulai dengan menyesuaikan dengan kebutuhan dan budget yang dimiliki. Dari pengalaman penulis, berikut rekomendasi penyedia layanan identitas yang pernah penulis pakai. Mohon dicatat layanan berikut ini berupa Identitas berbentuk layanan (Idaas) berbayar.

1. Okta : Sangat kaya akan fitur, antara lain: mendukung integrasi dengan on-premise Active Directory, kustomisasi user ID di setiap aplikasi, fungsi provisioning menggunakan SCIM (System for Cross-domain Identity Management)yang membuat administrator dapat mendaftarkan dan mengatur otorisasi pengguna di masing-masing aplikasi. Sebagai informasi, di luar SAML, OKTA juga mendukung OIDC (Open ID Connect).

2. Ping Identity: Juga kaya akan fitur yang dibutuhkan perusahaan enterprise seperti autentikasi terdelegasi ke Active Directory, SCIM provisioning, Open ID, dll. Ping Identity juga memiliki alternatif Active Directory : Ping Directory. Namun secara manajemen pengguna, dan SSO on-premise web application secara subjektif penulis, OKTA memiliki fitur yang lebih lengkap dan praktis untuk digunakan.

3. Azure Active Directory: Penyedia Identitas dari Microsoft. Secara native terintegrasi dengan ekosistem Microsoft (tentu saja), seperti Office 365 suite (Exchange, Sharepoint, One Drive, OneNote, Teams, dll), Active Directory (AD/ADFS), Azure Public Cloud/Stack/ Hybrid, dan masih banyak lainnya. Secara fungsi dan fitur tentunya sudah sangat memenuhi kebutuhan perusahaan enterprise.

Alternatif Kode Sumber Terbuka

Untuk pembaca yang ingin membuat server aplikasi manajemen identitas berbasis SAML secara on-premise dan juga bersumber terbuka (open source), alternatif berikut bisa menjadi pilihan: WSO2, Keycloak.

Kesimpulan dari standar SSO SAML?

Setelah kita membedah SSO SAML mulai dari mempelajari alur autentikasi, membuat aplikasi web yang mendukung SAML, dan juga memilih penyedia identitas. Dapat kita garis bawahi beberapa kesimpulan berikut:

1. Karena sifatnya yang digunakan untuk organisasi enterprise, penyedia identitas SAML adalah entitas yang memiliki kehandalan dan standar keamanan yang tinggi. Selain itu, fitur-fitur yang dimiliki juga menyesuaikan terhadap fungsi-fungsi autentikasi pada perusahaan.
2. SAML melakukan autentikasi menggunakan assertion (penegas) dalam format XML yang berisi dokumen sertifikat digital (X.509 certificate) yang sudah ditandatangani oleh penyedia identitas dan berisi informasi pengguna agar dapat diautentikasi oleh penyedia layanan.
3. Penyedia identitas pada umumnya sudah mendukung delegated authentication (autentikasi terdelegasi) kepada Active Directory/LDAP perusahaan. Sehingga data pengguna tersimpan di dalam domain perusahaan tanpa perlu menempatkannya pada penyedia identitas. Penyedia Identitas disini hanyalah sebagai perantara. Ini juga berarti satu user dan password bisa terhubung mulai dari aplikasi yang berbasis komputasi awan, hingga ke akun komputer karyawan, aplikasi perkantoran seperti Microsoft Office 365, printer kantor, wifi, bahkan server, dan akun lainnya yang tersentralisasi dengan domain perusahaan.
4. Lebih jauh, pendaftaran akun di setiap aplikasi, mengurus kompleksitas kata sandi, penggantian kata sandi berkala, pengaturan level otorisasi pengguna di masing-masing aplikasi, dapat dilakukan di satu tempat. Sehingga mempermudah pengaturan keamanan dan juga kepraktisan bagi administrator sistem IT mengurusi setiap akun di suatu perusahaan.

Open ID

Open ID adalah standar autentikasi terbuka yang diperkenalkan oleh Open ID Foundation. Diperkenalkan pada tahun 2006, dan pada Februari 2014 generasi ketiga Open ID disebut Open ID Connect (OIDC) diluncurkan. Penyempurnaan ini menambahkan layer autentikasi yang berbasis otorisasi OAuth 2.0, yang dapat digunakan untuk bertukar informasi pengguna menggunakan RESTful HTTP API dengan format JSON.

Pada Maret 2016 diperkirakan lebih dari 1 miliar akun Open ID dipergunakan untuk melakukan autentikasi di situs-situs internet. Sebut saja penyedia identitas yang populer seperti Google dan Facebook, kita hampir melihat mereka di hampir semua situs populer dalam opsi pendaftaran dan halaman masuk.

Alur autentikasi OIDC

Berikut adalah alur Autentikasi OIDC secara umum:

Ada beberapa alur autentikasi OIDC yang dijelaskan sebagai berikut:

1. Kode Otorisasi: Penyedia Identitas (OP) memberikan kode otorisasi yang bisa digunakan oleh backend dari Penyedia Sumber Daya(RP) untuk meminta Access Token dan ID Token untuk otorisasi sumber daya lebih lanjut seperti informasi pengguna, dan sumber daya lainnya seperti web API. Dari sisi keamanan, alur ini paling aman dikarenakan kita tidak memberikan token secara langsung kepada pengguna dalam hal ini browser ataupun aplikasi frontend yang digunakan. Kode Otorisasi yang dikirimkan dari sisi backend OP ke RP menyertakan Client ID dan Client Secret sehingga pertukaran kode dapat memvalidasi aplikasi Client.
2. Implisit: Penyedia layanan memberikan ID Token dan/atau Access Token. Alur implisit tidak membutuhkan logic pada backend penyedia layanan, sehingga informasi ID Token dan Access Token di antara penyedia layanan dan penyedia identitas dapat dilihat oleh browser pengguna ataupun aplikasi frontend yang digunakan, dan juga tidak dapat memvalidasi Client. Walaupun seperti itu, alur implisit tetap aman dikarenakan token ter-enkripsi menggunakan skema public/private key dan redirect URI parameter hanya diketahui RP. Alur implisit ini cocok untuk penyedia layanan yang berupa SPA (Single Page Application) atau pun autentikasi pada aplikasi mobile yang membutuhkan akses langsung untuk mengakses data pengguna.
3. Hybrid: Menggabungkan alur Kode Otorisasi dan Implisit. Meski secara umum Hybrid mengguna autentikasi berbasis kode Autentikasi, namun juga membutuhkan ID Token secara cepat. Pada flow ini ID token ataupun Access Token diberikan berbarengan dengan kode otorisasi.

Untuk berkenalan dan mempraktikkan langsung, kita bisa melakukan debugging sederhana autentikasi OIDC menggunakan tools debugger yang dibuat oleh para developer — yang baik hati, yang dibuat untuk membantu kita belajar : OpenID Connect debugger, OpenID Connect Playground, OKTA OIDC Example.

Open ID Token

Autentikasi Open ID menggunakan token berformat JSON. Ada tiga jenis token dalam spesifikasi OIDC, yaitu:

1. ID token: Adalah JWT (JSON Web Token), yang berarti identitas pengguna ter-encode pada token, dan bisa diproteksi keabsahannya secara digital. Pada alur Kode Otorisasi, ID token bisa didapatkan setelah kode otorisasi diberikan oleh Penyedia Identitas, sedangkan pada alur Implisit didapatkan langsung dari Penyedia Identitas tanpa memerlukan Kode Otorisasi.
2. Akses token: Digunakan sebagai bearertoken yang berarti selama pengguna memiliki bearer ini, ia dapat mengakses resource terotorisasi tanpa identifikasi lebih lanjut. Biasanya bearer token hanya memiliki masa hidup yang pendek bergantung pada pengaturan keamanan.
3. Refresh token: Diberikan bersamaan dengan akses token. Digunakan untuk meminta kembali akses token ketika sudah habis masa hidupnya. Ketika aplikasi mendapat respon bahwa akses token sudah expired, maka refresh token digunakan untuk meminta kembali akses token yang baru.

Terlihat bagi yang familiar dengan autentikasi OAuth2 alur autentikasi OIDC sangat identik dengan OAuth2. Yup, seperti yang pernah penulis utarakan di awal, ini dikarenakan OIDC berjalan diatas protokol OAuth2.

Dengan kesamaannya dengan OAuth2, mengapa dibuat standar OIDC?

OAuth adalah sebuah protokol untuk memberikan akses kepada seseorang atau yang biasa kita sebut delegasi. Namun dengan hak akses yang diberikan tersebut tidak menjamin bahwa seseorang yang diberikan akses adalah pengguna sebenarnya. OIDC memberikan layer identitas untuk memberikan keabsahan identitas pengguna sehingga bisa divalidasi secara digital.

Sebagai contoh dari ilustrasi di atas, Budi memberikan akses kepada Agus untuk masuk sebagai Toni, padahal keduanya bukanlah Toni. Hal ini menyebabkan masalah impersonasi akun. OIDC mendefinisikan ID Token yang memperjelas pengguna yang di autentikasi sebagai berikut:

• Siapa pengguna yang diautentikasi?
• Di mana ia diautentikasi?
• Kapan ia diautentikasi?
• Bagaimana ia diautentikasi?
• Atribut apa saja yang bisa diberikan?
• Mengapa ia diautentikasi?

Berikut adalah contoh isi dari ID Token Payload yang berisi data pengguna yang divalidasi menggunakan JSON Web Key.

{
 "sub": "00uisc43obADTkG2P0h7",
 "name": "Mirza Akbar",
 "locale": "en-US",
 "email": "",
 "ver": 1,
 "iss": "https://dev-196192.oktapreview.com/oauth2/default",
 "aud": "0oairye9f02fdRdTF0h7",
 "iat": 1546742858,
 "exp": 1546746458,
 "jti": "ID.iEB-4wz7EQY4tmDBRvWfvR09L4yVV3zM_-8NNMHJets",
 "amr": [
  "pwd"
 ],
 "idp": "00oisbhsxr5CT6mOO0h7",
 "nonce": "5dfde0c0-2c96-41ab-9fa7-9c8bccb5c066",
 "preferred_username": "",
 "given_name": "Mirza",
 "family_name": "Akbar",
 "zoneinfo": "America/Los_Angeles",
 "updated_at": 1546713718,
 "email_verified": true,
 "auth_time": 1546736659
}

Open ID dan keterkaitannya dengan data pengguna..

Pertanyaan yang muncul adalah, sesuai terjemahannya: ID Terbuka, apakah artinya informasi pengguna di situs seperti Facebook dan Google menjadi terbuka untuk situs penyedia layanan yang menerapkan autentikasi Open ID? Jawabannya, spesifikasi Open ID hanya memberikan informasi yang sudah disetujui pengguna ketika menggunakan Open ID, yang disebut dengan scope. Scope berisi set dari claimsyang berisi satuan informasi tentang pengguna.

Scope pada OIDC terdiri dari:

• Profile : permintaan akses default profile claims
• Email: permintaan akses ke email dan email_verified claims
• Address: permintaan akses ke address claims
• Phone: permintaan akses ke phone_number dan phone_number_verified claims.

Default profile claims berisi:

• name
• family_name
• given_name
• middle_name
• nickname
• preferred_username
• profile_picture
• website
• gender
• birthdate
• zoneinfo
• locale
• updated_at

Sebagai pengembang aplikasi, bagaimana saya mengadopsi SSO berbasis OIDC di sisi client aplikasi saya?

Untuk memasang OIDC sebagai client, bisa dimulai dengan mempelajari dan menentukan alur OIDC yang sesuai dengan kebutuhan aplikasi yang dibuat. Saya sertakan sumber ke dokumen teknis Open ID berikut: Open ID Connect Specification.

Dengan kepopulerannya, OIDC memiliki banyak dukungan sumber pustaka untuk berbagai macam bahasa pemrograman. Pustaka-pustaka yang yang sudah tersertifikasi oleh organisasi Open ID dapat dilihat disini: Certified Relying Party Libraries.

Sebagai pengembang aplikasi, bagaimana saya memilih penyedia identitas berbasis Open ID untuk aplikasi saya? Atau apakah lebih baik saya membangun, atau pun membuat aplikasi penyedia identitas sendiri?

Pertanyaan di atas dapat dikembalikan dengan kebutuhan. Tentunya untuk mempermudah pengguna umum mengakses aplikasi kita, bisa dipilih penyedia Open ID yang populer seperti Facebook, Google, dan Microsoft.

Lain halnya apabila dibutuhkan SSO untuk terautentikasi di suatu “keluarga” aplikasi yang kalian miliki, misalnya : Penyedia layanan X memiliki keluarga aplikasi layanan Y dan Z yang memiliki basis data pengguna berbeda dan fungsi otorisasi yang berbeda, sehingga X akan berlaku sebagai penyedia identitas untuk Y dan Z.

Untuk kasus di atas kita bisa mengintegrasikan aplikasi kita dengan penyedia Identitas pihak ketiga seperti penyedia identitas yang penulis sebutkan pada topik SAML di artikel ini. Karena dari pengamatan penulis saat ini penyedia identitas sudah mendukung SAML dan Open ID secara bersamaan.

Namun, apabila ingin membuat Open ID Provider sendiri (in house), banyak pustaka sumber terbuka yang bisa kita gunakan sebagai berikut: Certified Open ID Provider Libraries. Dengan fungsinya yang critical, faktor keandalan dan keamanan dari aplikasi penyedia identitas yang dibuat sangat harus dijaga secara optimal.

Kesimpulan dari standar SSO berbasis Open ID

Akhirnya kita sampai pada kesimpulan setelah menyelami Open ID mulai dari Alur autentikasi, debugging, dan mengimplementasi OIDC pada system stack kita.

1. Dengan sifatnya yang terbuka dan mudah diimplementasikan (RESTful service, JSON format, dan didukung penyedia Identitas besar yang gratis), Open ID banyak digunakan oleh penyedia layanan yang targetnya adalah pengguna umum. Juga dengan kemudahan itu, Open ID juga disukai oleh developer aplikasi untuk membuat SSO sendiri di dalam ekosistem aplikasi mereka.
2. Flow autentikasi OIDC menggunakan autentikasi Kode Otorisasi untuk proses yang melibatkan backend (pada alur Kode Otorisasi dan Hybrid), dan ID Token dan Akses Token untuk proses yang hanya melibatkan frontend (pada alur Implisit).

Kesimpulan Akhir SAML vs Open ID

Setelah kita membahas masing-masing standar dengan cukup objektif dan mendetail, kita bisa membandingkan kedua standar SSO secara apple to apple dan menghayati perbedaan dan persamaannya.

Secara simplifikasi kasar penulis, Open ID Connect “memodernisasi” ulang protokol SAML dengan menggunakan basis protokol OAuth2 (JSON format dan token-based signature). Serta dukungan untuk autentikasi pada aplikasi mobile secara native, dan keterbukaannya untuk digunakan oleh pengguna umum.

Sedangkan di sisi lain, standar SAML yang ada jauh lebih dulu dianggap sudah proven dan didukung secara luas oleh aplikasi perangkat lunak/ platform berbentuk layanan saat ini (baca: 97% aplikasi SaaS Mendukung SSO Berbasis SAML). Namun bukan berarti ini akan terus bertahan, dengan terus berkembangnya standar Open ID. Bukan tidak mungkin Open ID akan menggeser posisi SAML sebagai standar SSO di organisasi enterprise.

Dari sisi Penyedia Identitas, vendor-vendor Penyedia Identitas untuk perusahaan, pada umumnya sudah mendukung standar SSO SAML dan Open ID secara bersamaan, dan memberikan fitur-fitur yang berbeda bagi kebutuhan pengguna.

Demikian bahasan kali ini, sampai berjumpa di tulisan penulis berikutnya!

P.S. Jika teman-teman menyukai artikel semacam ini, silakan subscribe ke newsletter kita dan dapatkan notifikasi artikel terbaru langsung di inbox kamu!