Perancangan Dan Implementasi Resource Server Dan Authorization Server Menggunakan Teknologi Otentikasi Oauth 2
PERANCANGAN DAN IMPLEMENTASI RESOURCE SERVER
DAN AUTHORIZATION SERVER MENGGUNAKAN
TEKNOLOGI OTENTIKASI OAUTH 2
SKRIPSI
YOSRINAL
111421017
PROGRAM STUDI EKSTENSI S1 ILMU KOMPUTER
FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI
UNIVERSITAS SUMATERA UTARA
MEDAN
2014
(2)
PERANCANGAN DAN IMPLEMENTASI RESOURCE SERVER DAN AUTHORIZATION SERVER MENGGUNAKAN
TEKNOLOGI OTENTIKASI OAUTH 2
SKRIPSI
Diajukan untuk melengkapi tugas dan memenuhi syarat memperoleh ijazah Sarjana Ilmu Komputer
YOSRINAL 111421017
PROGRAM STUDI EKSTENSI S1 ILMU KOMPUTER FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI
UNIVERSITAS SUMATERA UTARA MEDAN
(3)
PERSETUJUAN
Judul : PERANCANGAN DAN IMPLEMENTASI
RESOURCE SERVER DAN AUTHORIZATION SERVER MENGGUNAKAN TEKNOLOGI OAUTH 2
Kategori : SKRIPSI
Nama : YOSRINAL
Nomor Induk Mahasiswa : 111421017
Program Studi : EKSTENSI S1 ILMU KOMPUTER
Fakultas : ILMU KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA
Komisi Pembimbing :
Dosen Pembimbing II Dosen Pembimbing I
M. Anggia Muchtar, ST, MM.IT Dian Rachmawati, S.Si, M.Kom NIP. 19800110 200801 1 010 NIP. 19830723 200912 2 004
Diketahui/disetujui oleh
Program Studi Ekstensi S1 Ilmu Komputer Ketua,
Dr. Poltak Sihombing, M.Kom NIP. 19620217 199103 1 001
(4)
PERNYATAAN
PERANCANGAN DAN IMPLEMENTASI RESOURCE SERVER
DAN AUTHORIZATION SERVER MENGGUNAKAN
TEKNOLOGI OTENTIKASI OAUTH 2
Saya mengakui bahwa skripsi ini adalah hasil karya saya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing disebutkan sumbernya.
Medan, Januari 2014
Yosrinal 111421017
(5)
PENGHARGAAN
Bismillaahirrahmaanirrahim Alhamdulillahirrabbila’lamin Puji dan syukur penulis panjatkan hanya kepada Allah SWT, yang memelihara dan mengatur seluruh kehidupan ini, tempat mengadu dan memohon pertolongan. Berkat berkahan karunia dan petunjuk yang diberikan dariNya, penulis mampu menyelesaikan skripsi ini. Shalawat dan beriring salam penulis ucapkan kepada baginda Rasulullah Muhammad SAW.
Skripsi ini dikerjakan sebagai salah satu syarat guna memperoleh gelar Sarjana Ilmu Komputer Fakultas Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara. Penulis menyadari bahwa terselesaikannya skripsi ini tentunya tak lepas dari dorongan dan bantuan berbagai pihak. Oleh karena itu, dengan segala kerendahan hati penulis mengungkapkan rasa terima kasih dan penghargaan kepada :
1. Ibu Dian Rachmawati, S.Si, M,Kom, selaku Dosen Pembimbing I yang telah memberikan arahan, masukan, bimbingan, saran, serta motivasi yang membangun untuk penulis sehingga penulis dapat menyelesaikan skripsi ini dengan baik.
2. Bapak M. Anggia Muchtar, ST, MM.IT, selaku pembimbing II yang telah memberikan masukan, bimbingan, saran dan motivasi kepada penulis, serta sabar memberikan bantuan sehingga penulis dapat menyelesaikan skripsi ini dengan baik.
3. Bapak Ade Candra, ST, M.Kom selaku Dosen Pembanding I, yang telah memberikan kritik dan saran yang membangun bagi penulis.
4. Bapak Herriyance, ST, M.Kom sebagai Dosen Pembanding II yang telah memberikan kritik dan saran yang membangun bagi penulis.
5. Dekan dan Pembantu Dekan Fakultas Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara berserta para pegawai yang bertugas di Program Studi Ilmu Komputer FASILKOM-TI USU.
6. Orang tua tercinta, Ayahanda Faizal Tahar dan Ibunda Rosdawati, Abangnda Yoseirsal untuk semua doa, dukungan, dan motivasi yang tak ternilai harganya.
7. Bapak dr. Alis Marajo dan Bapak Drs.H.Asyirwan Yunus, M.Si selaku Bupati Lima Puluh Kota dan Wakil Bupati Lima Puluh Kota - Sumatera Barat yang telah memberikan izin kepada penulis melakukan kegiatan tugas belajar.
8. Bapak Ambardi, SE, MM selaku Kepala Badan Penanaman Modal dan Pelayanan Perizinan Lima Puluh Kota beserta keluarga besar BPMPPT, yang telah memberikan kesempatan penulis melakukan tugas belajar.
9. Kepala Badan Kepegawaian Lima Puluh Kota Lima - Sumatera Barat beserta seluruh jajaran staf / pegawai, terimakasih atas bantuan yang telah diberikan kepada penulis selama ini.
10.Dolly Aswin Harahap, dan teman - teman sejawat Ekstensi 2011 Donny Sanjaya, Hedi Hermawan Harahap, Adam Kurniawan, Fatah Abdella Sutara,
(6)
Tanzilul Khoir Gultom dan seluruh teman - teman Ekstensi Kom A dan B dengan tidak mengurangi rasa persahabatan sedikit pun, salam kompak.
11.Seluruh kolega dan teman-teman dari jajaran Pemkab Lima Puluh Kota - Sumatera Barat Ronal Harsya, Ifdol Rahman, Pak Haji Salman, Uda Musmulyadi, HN, ST, Kak Melsy, Yengky Nofra Effendi, serta adik - adik dari CV. Ferrari Corp. (Harianto dan Ferdi), terimakasih untuk semua dukungan morilnya. Semoga Allah SWT membalas semua kebaikan yang telah kalian berikan.
Medan, Januari 2014 Penulis
Yosrinal
(7)
ABSTRAK
OAuth adalah entitas yang dapat memberikan hak akses terhadap sumber yang dilindungi (protected resource). Dengan OAuth seseorang dapat berbagi data dengan orang lain seperti foto, video dan tulisan secara langsung sehingga dapat mengidentifikasi dan memudahkan dalam proses pengenalan dan pencarian informasi. Tujuan penelitian ini adalah merancang dan menerapkan prosedur mekanisme kerja teknologi OAuth 2 dengan melibatkan adanya otorisasi server yang merupakan sumber daya server itu sendiri dalam melakukan otentikasi dan otorisasi credential dari seorang client. Pada penelitian ini digunakan 3 (tiga) aplikasi yang bersifat single sign on, terdiri atas 3 halaman sign-in berbasis otentikasi OAuth 2 dari pemilik sumber daya (Resource Owner) dengan menerapkan proses kerja otentikasi OAuth 2. Otentikasi OAuth 2 lewat peran Authorization Server akan memvalidasi credential dari client seusai keberadaannya pada basis data, di proses dengan mengeluarkan sebuah halaman otorisasi (Authorize App) untuk diarahkan ke halaman utama setiap aplikasi web masing-masing. Otorisasi akhir dari kebenaran credential seorang client adalah di hasilkan sebuah akses token yang bekerja pada url (uniform resource locator) pada masing - masing aplikasi web.
Kata Kunci: Authorization Server, OAuth 2, Otentikasi dan Otorisasi, Resource Server.
(8)
DESIGN AND IMPLEMENTATION OF RESOURCE SERVER AND AUTHORIZATION SERVER USING OAUTH 2
AUTHENTICATION TECHNOLOGY
ABSTRACT
OAuth is an entity that can grant access to a protected resource. With OAuth someone can share the data with others such as photos, videos and posts directly so as to identify and facilitate the process of recognition and information retrieval. The purpose of this research is to design and implement procedures work mechanism involving technology OAuth 2 authorization server is a server resource itself in the authentication and authorization of a client credential. In this study, the three applications that are single sign on, consisting of 3 pages sign in OAuth 2 authentication based on the owner of the resource (resource owner) by implementing OAuth 2 authentication work process. Authentication via OAuth 2 Authorization Server will validate the role of client credential after its existence on the basis of the data, in the process by issuing an authorization page ( Authorize app ) to be directed to the main page of any web application, respectively. Final authorization of a client credential truth is generated an access token that works on the url ( uniform resource locator ) on each web application.
Keywords: Authentication and Authorization, Authorization Server, OAuth 2, Resource Server.
(9)
DAFTAR ISI
Hal.
PERSETUJUAN ii
PERNYATAAAN iii
PENGHARGAAN iv
ABSTRAK vi
ABSTRACT vii
DAFTAR ISI viii
DAFTAR TABEL x
DAFTAR GAMBAR xi
BAB 1 PENDAHULUAN
1.1 Latar Belakang 1
1.2 Rumusan Masalah 2
1.3 Batasan Masalah 2
1.4 Tujuan Penelitian 3
1.5 Manfaat Penelitian 3
1.6 Metode Penelitian 3
1.7 Sistematika Penulisan 4
BAB 2 TINJAUAN PUSTAKA 6
2.1 Pengenalan OAuth 6
2.2 OAuth 1.0 7
2.3 OAuth 2.0 11
2.4 Hibah Otorisasi (Authorization Grant) 13
2.4.1 Authorization Code 13
2.4.2 Implicit 13
2.4.3 Resource Owner Password Credential 14
2.4.4 Client Credential 14
2.5 Access Token dan Refresh Token 14
2.5.1 Access Token 14
2.5.2 Refresh Token 15
2.6 Jenis Client Profile 15
2.6.1 Server Side Web Application 15 2.6.2 Client Side User Agent Based Application 15 2.6.3 Resource Owner Password Flow 16
2.7 Workflow Client Profile 16
2.7.1 Server Side Web Application Flow 16 2.7.2 Client Side Web Application Flow 18 2.7.3 Resource Owner Password Flow 19
2.8 Proses Roles of Authetication 20
2.8.1 Web Server Application 20
2.8.2 Browser Based Application 24
(10)
2.9.1 Pengertian Sistem Informasi 26
2.9.2 Pengertian Informasi 26
2.9.3 Konsep Sistem Informasi 27
BAB 3 ANALISIS DAN PERANCANGAN SISTEM 28
3.1 Analisis Permasalahan 28
3.2 Analisis Kebutuhan Sistem 29
3.3 Analisis Teknologi OAuth 2 31
3.4 Perancangan Sistem 34
3.4.1 Deskripsi Sistem 34
3.4.1.1 Fungsi Utama 34
3.4.1.2 Batasan 35
3.4.2 DFD (Data Flow Diagram) 35
3.4.2.1 Diagram Konteks 35
3.4.2.2 Data Flow Diagram Level 1 37 3.4.2.3 Data Flow Diagram Level 2 39
3.4.3 Perancangan Basis Data 40
3.4.4 Flowchart Sistem 41
3.4.4.1 Flowchart Sistem Aplikasi Secara Umum 42 3.4.4.2 Flowchart Otentikasi OAuth 2 43
3.4.5 Perancangan Tampilan 44
3.4.5.1 Rancangan Halaman Tambah Client 45 3.4.5.2 Rancangan Halaman Sign-In 46 3.4.5.3 Rancangan Halaman Utama 47 3.4.5.4 Rancangan Halaman Menu dan Harga 48 3.4.5.5 Rancangan Halaman Reservasi 49
3.4.6 Pseudocode 50
BAB 4 IMPLEMENTASI DAN PENGUJIAN
4.1 Implementasi Sistem 56
4.1.1 Spesifikasi Perangkat Lunak dan Perangkat Keras 56 4.1.2 Implementasi Aktivitas Menambah Client Baru 56 4.1.3 Implementasi Aktivitas Sign In 57 4.1.4 Implementasi Proses Otentikasi Teknologi OAuth 2 58 4.1.5 Implementasi Reservasi Pada Web Aplikasi Cafe 60
4.2 Pengujian Sistem 61
4.2.1 Pengujian Black Box 61
4.2.2 Pengujian Tambah Client Baru 63 4.2.3 Pengujian Sign In dengan Otentikasi OAuth2 65
4.2.4 Pengujian Reservasi 72
BAB 5 KESIMPULAN DAN SARAN 75
5.1 Kesimpulan 75
5.2 Saran 76
(11)
DAFTAR TABEL
Hal. 2.1 Tugas dan Fungsi 4 (empat) Komponen OAuth 12 2.2 Keterangan Server Side Web Application Flow 17 2.3 Keterangan Server Side Web Application Flow 18 2.4 Keterangan Resource Owner Password Flow 19 3.1 Keterangan Proses Kerja Teknologi OAuth 2 32 3.2 Keterangan Proses Schema Jaringan OAuth 2 33
3.5 Tabel Reservasi 40
3.6 Tabel Clients 40
3.7 Tabel Tokens 41
3.8 Kode Program Untuk Membuat Kode OAuth 2 48
4.1 Spesifikasi Perangkat Pada Aplikasi 56
4.2 Tahapan Pengujian Pada Sistem 61
4.3 Daftar Client ID dan Client Secret 66
4.4 Daftar Client ID dan Client Secret Dari Basis Data Clients 66 4.5 Akses Token Yang Dihasilkan Dari Beberapa Client Yang Berbeda 71 4.6 Data Akses Token Yang Berasal Dari Basis Data Tokens 71
(12)
DAFTAR GAMBAR
Hal.
2.1 Tiga Peran Aktif pada OAuth 1.0 8
2.2 Otorisasi Akses Layanan bit.ly Menggunakan Account Twitter.com 9
2.3 Lalu Lintas Transaksi OAuth 1.0 10
2.4 Antar Muka Layanan Bit.ly 10
2.5 Mekanisme Kerja OAuth 2 12
2.6 Server Side Web Application Flow 16
2.7 Client Side User Web Application Flow 18
2.8 Resource Owner Password Flow 19
2.9 Proses Otentikasi Web Server Application 20 2.10 Proses Otentikasi Web Server Application -2 21 2.11 Proses Otentikasi Web Server Application- 3 22
2.12 Auth Code dari Google API 22
2.13 Halaman Auth Code dari Google API 23
2.14 Proses Otentikasi Web Server Application - 4 23 2.15 Proses Otentikasi Web Sever Application - 5 24 2.16 Proses Otentikasi Browser Based Application 25 2.17 Proses Otentikasi Browser Based Application- 2 25 2.18 Proses Otentikasi Browser Based Application- 3 26 2.19 Proses Otentikasi Browser Based Application - 4 26
3.1 Diagram Ishikawa Analisis Masalah 29
3.2 Proses Kerja Teknologi OAuth 2 Pada Aplikasi Web 31
3.3 Schema Jaringan OAuth 2 33
3.4 DFD Level 0 36
3.5 Data Flow Diagram Level 1 38
3.6 Data Flow Diagram Level 2 40
3.6 Flowchart Sistem Aplikasi Secara Umum 43
3.7 Flowchart Otentikasi OAuth 2 44
3.8 Rancangan Tampilan Halaman Tambah Client 46
3.9 Rancangan Tampilan Halaman Sign-In 47
3.10 Rancangan Tampilan Halaman Utama 48
3.11 Rancangan Tampilan Halaman Menu dan Harga 49 3.12 Rancangan Tampilan Halaman Reservasi 50
4.1 Form Pendaftaran Client Baru 57
4.2 Form Aktivitas Sign In Web SSO 57
4.3 Form Aktivitas Sign In Web 2 SSO 58
4.4 Form Aktivitas Sign In Web 3 SSO 58
4.5 Halaman Authorize App 59
4.6 Akses Token Dihasilkan 59
4.7 Halaman Form Reservasi 60
4.8 Halaman Tambah Client Baru 63
4.9 Pesan Error Halaman Tambah Client Baru 64 4.10 Pesan Sukses Halaman Tambah Client Baru 64
(13)
4.11 Pengujian Tambah Client Baru Menggunakan Add-ons Firebug 65
4.12 Halaman Aktivitas Sign In 66
4.13 Pesan Error - 1 Halaman Aktivitas Sign In 67 4.14 Pesan Error - 2 Halaman Aktivitas Sign In 67 4.15 Pesan Error Menggunakan Add-ons Firebug 68
4.16 Form Sign In Diisi Dengan Benar 69
4.17 Halaman Authorize App Menggunakan Data Client-1 69 4.18 Pengujian Form Sign-in Menggunakan Add-ons Firebug 70 4.19 Akses Token Yang Dihasilkan Pada Halaman Utama 70
4.20 Form Aktivitas Reservasi 72
4.21 Form Aktivitas Reservasi Saat Diisi 73
(14)
DAFTAR LAMPIRAN
Hal.
A. Listing Program A-1
(15)
ABSTRAK
OAuth adalah entitas yang dapat memberikan hak akses terhadap sumber yang dilindungi (protected resource). Dengan OAuth seseorang dapat berbagi data dengan orang lain seperti foto, video dan tulisan secara langsung sehingga dapat mengidentifikasi dan memudahkan dalam proses pengenalan dan pencarian informasi. Tujuan penelitian ini adalah merancang dan menerapkan prosedur mekanisme kerja teknologi OAuth 2 dengan melibatkan adanya otorisasi server yang merupakan sumber daya server itu sendiri dalam melakukan otentikasi dan otorisasi credential dari seorang client. Pada penelitian ini digunakan 3 (tiga) aplikasi yang bersifat single sign on, terdiri atas 3 halaman sign-in berbasis otentikasi OAuth 2 dari pemilik sumber daya (Resource Owner) dengan menerapkan proses kerja otentikasi OAuth 2. Otentikasi OAuth 2 lewat peran Authorization Server akan memvalidasi credential dari client seusai keberadaannya pada basis data, di proses dengan mengeluarkan sebuah halaman otorisasi (Authorize App) untuk diarahkan ke halaman utama setiap aplikasi web masing-masing. Otorisasi akhir dari kebenaran credential seorang client adalah di hasilkan sebuah akses token yang bekerja pada url (uniform resource locator) pada masing - masing aplikasi web.
Kata Kunci: Authorization Server, OAuth 2, Otentikasi dan Otorisasi, Resource Server.
(16)
DESIGN AND IMPLEMENTATION OF RESOURCE SERVER AND AUTHORIZATION SERVER USING OAUTH 2
AUTHENTICATION TECHNOLOGY
ABSTRACT
OAuth is an entity that can grant access to a protected resource. With OAuth someone can share the data with others such as photos, videos and posts directly so as to identify and facilitate the process of recognition and information retrieval. The purpose of this research is to design and implement procedures work mechanism involving technology OAuth 2 authorization server is a server resource itself in the authentication and authorization of a client credential. In this study, the three applications that are single sign on, consisting of 3 pages sign in OAuth 2 authentication based on the owner of the resource (resource owner) by implementing OAuth 2 authentication work process. Authentication via OAuth 2 Authorization Server will validate the role of client credential after its existence on the basis of the data, in the process by issuing an authorization page ( Authorize app ) to be directed to the main page of any web application, respectively. Final authorization of a client credential truth is generated an access token that works on the url ( uniform resource locator ) on each web application.
Keywords: Authentication and Authorization, Authorization Server, OAuth 2, Resource Server.
(17)
BAB 1 PENDAHULUAN
1.1Latar Belakang
Kecanggihan dunia teknologi informasi yang berkembang pesat memiliki dampak yang luas kepada setiap individu. Setiap orang dapat bersosialiasi dan memberikan akses kepada orang lain dengan memanfaatkan account suatu website tertentu. Dengan social media account, selain wadah pertemuan dengan orang - orang baru, juga bermanfaat dalam pendelegasian akses data. Untuk sebuah aplikasi cafe yang memiliki mekanisme pelayanan bersifat online (seperti tersedianya harga menu makanan atau minuman serta fasilitas booking untuk kegiatan tertentu) dapat meningkatkan kecanggihan sistem aplikasi dengan menyediakan fitur otentikasi pengunjung yang terintegrasi dengan penerbit social media account, agar pengunjung dapat menerima dan melakukan kegiatan mengakses data yang sudah tersedia.
Pendelegasian akses data menggunakan perantara account website tertentu merupakan model pelayanan yang sudah diintegrasikan dengan pemakaian otentikasi API pada salah satu penyedia API. API (Application Programming Interface) bisa bersumber dari peyelenggara utama social media seperti Facebook, Twitter, Google+, LinkedIn atau dari beberapa vendor penyedia API yang mengatur pendelegasian akses data[10].
Protokol OAuth (Open Authorization) adalah protokol otentikasi yang bersumber dari layanan penyedia API, yang memberikan kuasa kepada seseorang untuk mendapatkan hak akses mereka dengan menukarkan credential (username dan password) menjadi akses token[8]. Otentikasi dengan menggunakan OAuth mengatur
(18)
sedemikian rupa agar pengunjung tetap aman menggunakan layanan aplikasi dengan mempercayakan kehadiran pihak ketiga (third party) yang telah dipercayai sebagai sumber server (resource server) yang mempunyai kuasa untuk menertibkan dan mengatur segala credential yang ada. Resource Server juga merupakan Authorization Server yang melakukan proses otorisasi client permintaan API dengan menukarkan authorization code dalam bentuk akses token[1]. Biasanya access token diterbitkan bersamaan dengan refresh token.
1.2Rumusan Masalah
Bagaimana mempelajari, merancang dan mengimplementasikan Resource Server dan Authorization Server yang dibangun dan diterbitkan sendiri tanpa mengarahkan otentikasi kepada pihak ketiga (third party) pada proses otentikasi OAuth aplikasi layanan cafe online.
1.3Batasan Masalah
Pembahasan dalam penelitian ini dibatasi pada :
1. Penelitian ini dibangun menggunakan bahasa pemrograman PHP Versi 5.3, Database Management System MySQL Versi 5.5.
2. Penggunaan aplikasi single sign on sebagai layanan dengan media login otentikasi berbasis OAuth.
3. Aplikasi layanan single sign on dibatasi dengan memiliki 3 (tiga) halaman sign in yang terintegrasi pada masing - masing aplikasi berbasis web.
4. Resource Server dan Authorization Server terintegrasi langsung pada layanan aplikasi cafe online, tidak mengandalkan penggunaan API yang bersumber pada salah satu penyedia API.
(19)
5. Protokol otentikasi OAuth yang digunakan OAuth versi 2.0
6. Penelitian tidak membahas teknik keamanan, berkonsentrasi pada penerapan Resource Server dan Authorization Server yang dibangun dan diterbitkan sendiri.
1.4Tujuan Penelitian
Penelitian ini bertujuan untuk menerapkan Resource Server dan Authorization Server pada sistem otentikasi OAuth layanan aplikasi web yang bersifat single sign on yang dirancang dan dibangun sendiri dengan memanfaatkan penggunaan bahasa pemrograman PHP.
1.5Manfaat Penelitian
Penelitian ini diharapkan bermanfaat dengan menggunakan otentikasi OAuth dapat membangun dan menerbitkan sendiri Resource Server dan Authorization Server yang bukan berasal dari penyedia API salah satu vendor tertentu.
1.6 Metode Penelitian
Metode penelitian yang dilakukan dalam penelitian ini adalah:
1. Studi Kepustakaan
Pada tahap ini dilakukan peninjauan terhadap ebook, artikel, tugas akhir, paper maupun hasil jurnal yang membahas tentang OAuth, bahasa pemrograman PHP yang berkaitan dalam membangun Resource Server dan Authorization Server 2. Analisis dan Perancangan
Dengan adanya rumusan dan batasan masalah, kebutuhan perancangan dianalisis disertai pembuatan flowchart, DFD (Data Flow Diagram) dan kamus data.
(20)
3. Implementasi
Menerapkan Resource Server dan Authorization Server pada sistem otentikasi OAuth ke dalam aplikasi web single sign on yang dirancang.
4. Pengujian
Pengujian difokuskan pada penerapan Resource Server dan Authorization Server yang berjalan dan berdiri sendiri tanpa menggunakan pihak penyedia API tertentu. 5. Dokumentasi
Dokumentasi dihasilkan dengan membuat skripsi sebagai laporan dari hasil penelitian.
1.7Sistematika Penulisan
Sistematika penulisan dari tugas akhir ini terdiri dari beberapa bagian utama yakni :
BAB 1. PENDAHULUAN
Bab ini akan menjelaskan mengenai latar belakang masalah yang diangkat pada penelitian ini, rumusan masalah, batasan masalah, tujuan penelitian, manfaat penelitian, metode penelitian, dan sistematika penulisan penelitian.
BAB 2. LANDASAN TEORI
Bab ini merupakan tinjauan teoritis yang berkaitan dengan teknologi otentikasi yakni OAuth, penerapan OAuth serta workflow OAuth yang bersumber dari literatur jurnal ilmiah, paper, serta ebook yang terdapat di internet.
BAB 3. ANALISIS DAN PERANCANGAN SISTEM
Pada Bab ini akan dibahas tentang analisis dan perancangan dari Authorization Server dan Resource Server dalam mendukung dan menghasilkan alur kerja otentikasi dan otorisasi yang berbasis OAuth yang disertakan dengan pembuatan flowchart, DFD (Data Flow Diagram), dan kamus data.
(21)
BAB 4. IMPLEMENTASI DAN PENGUJIAN
Di bab ini akan di implementasikan dari perancangan yang sudah dilakukan dengan menerapkan kinerja Authorization Server dan Resource Server otentikasi OAuth 2 pada web aplikasi single sign on.
BAB 5. KESIMPULAN DAN SARAN
Bab ini memuat kesimpulan dari keseluruhan teoritis dan uraian setiap Bab, serta saran - saran yang dihasilkan dan diperlukan dalam perbaikan sistem otentikasi OAuth kedepannya.
(22)
BAB 2
TINJAUAN PUSTAKA
2.1 Pengenalan OAuth
OAuth (Open Authorization) adalah protokol otorisasi standar terbuka yang memungkinkan pengguna mengakses aplikasi tanpa perlu berbagi password mereka[4]. Pemilik aplikasi mengintegrasikan credential milik pengguna dengan teknologi otentikasi yang berasal dari penerbit API (Application Programming Interface). OAuth juga mengizinkan otorisasi API yang sudah terproteksi yang berasal dari desktop ataupun aplikasi web melalui metode sederhana dan standard. Mengatur lalu lintas data antar aplikasi dan digunakan saat penerbit API ingin mengetahui siapa yang terlibat dan berkomunikasi di dalam sistem[17].
OAuth 1.0 (juga dikenal sebagai RFC 5849), diterbitkan pada tanggal 4 Desember 2007, direvisi pada tanggal 24 Juni 2009, dan diselesaikan pada bulan April 2010 yang memberikan pengaruh penting pada perkembangan keamanan web API tanpa harus pengguna berbagi username dan password mereka. Adapun pencipta dan pengagas utama dari otentikasi OAuth berbasis API ini adalah E. Hammer-Lahav, Ed.
Pada bulan April 2009, Twitter merilis sebuah solusi otentikasi user yang mereka sebut “Sign-in with Twitter” dengan menggunakan protokol OAuth. Otentikasi OAuth yang diciptakan dan dimodifikasi sendiri menciptakan layanan khusus untuk Twitter. Pembaharuan yang diciptakan oleh twitter mengundang para komunitas keamanan web merilis First Security Advisory di tahun 2009, yang diikuti dengan versi revisi dari protokol OAuth, OAuth Revision A pada 24 Juni 2009.[7]
(23)
OAuth 2 adalah project lanjutan dari protokol OAuth yang asal mulanya diciptakan pada akhir tahun 2006. OAuth 2 lebih menekankan pada kemudahan client sebagai pemilik dan pengembang aplikasi dengan memberikan otorisasi khusus di berbagai aplikasi. OAuth berada dalam pengembangan IETF OAuth WG dan didasarkan pada usulan WRAP OAuth. WRAP (Web Resource Authorization Protocol) adalah profil OAuth yang memiliki sejumlah kemampuan penting yang tidak tersedia di versi OAuth sebelumnya. Spesifikasi terbaru dari OAuth disumbangkan kepada IETS OAuth WG dan merupakan dasar dari terciptanya OAuth versi 2[8].
Dengan banyaknya aplikasi web yang mengapdopsi kolaborasi penggunaan jaringan sosial, pengembang aplikasi memiliki kesempatan untuk menghubungkan pengguna dengan aplikasi dimanapun mereka berada. Yang dapat meningkatkan efektivitas dan efisiensi terjadinya transaksi pengolahan data didalam sistem tersebut. OAuth menyediakan kemampuan terhubung dengan sistem aplikasi secara aman, sehingga pengguna tidak perlu menyerahkan sandi akun pentingnya[16]. Ada beberapa fungsionalitas menguntungkan yang tersedia pada OAuth meliputi[2] : 1. Mendapatkan akses ke grafik social media seperti teman yang berasal dari
Facebook, orang - orang yang mengikuti (following) di Twitter, ataupun list contact yang berasal dari Google Contact.
2. Berbagi informasi mengenai kegiatan seorang pengunjung pada sebuah web aplikasi dengan menandai postingan mereka di Facebook ataupun tweet dari Twitter mereka.
3. Mengakses penggunaan Google Docs atau akun Dropbox untuk menyimpan data online mereka dengan berbagai file pilihan.
2.2 OAuth 1.0
OAuth 1.0 dilakukan oleh terlibatnya dari 3 peran berikut yakni : client, server, dan resource owner. Ketiga peran ini akan hadir dalam setiap alur kerja OAuth. Versi asli
(24)
dari spesifikasi yang digunakan yang berbeda istilah untuk peran ini : konsumen (klien), penyedia layanan (server), dan user (pemilik sumber daya). 3 (tiga) peran yang terlibat aktif ini disebut dengan 3-Legged. Jika di contohkan dan di ilustrasikan perannya seperti berikut ini. Pada gambar 2.1 menunjukkan keterlibatan 3 (tiga) peran aktif pada lalu lintas protokol OAuth 1.0 [2] :
1. Pengguna layanan atau disebut user dimisalkan Bob
2. Sebuah client (berupa aplikasi web ataupun aplikasi mobile), di misalkan di sini adalah layanan dari bit.ly
3. Sebuah server dimana aplikasi berjalan dimisalkan Twitter.com
Gambar 2.1 Tiga peran aktif pada OAuth 1.0
Bagaimana Bob menggunakan sumber daya layanannya yang ada di bit.ly melalui account twitternya[2].
1. Bob mengunjungi dan mengakses bit.ly, yang sudah menggunakan layanan dan tersedia di twitter. Dan Bob sudah memiliki account baik itu untuk bit.ly ataupun twitter.
2. Pada sistem layanan bit.ly menggunakan OAuth credential sebagai proses awal otentikasi kepemilikan Bob.
(25)
Bit.ly mengarahkan Bob untuk sementara ke twitter.com untuk proses login (bit.ly tanpa pernah sedikitpun mengetahui account Bob di twitter.com). Halaman otentikasi twitter menanyakan apakah aplikasi bit.ly dapat mengakses twitter. Pada gambar 2.2 di bawah ini menunjukkan otorisasi bit.ly menggunakan account twitter.com
Gambar 2.2 Otorisasi Akses Layanan bit.ly Menggunakan Account Twitter.com 3. Jika proses login berhasil, bit.ly menggunakan credential OAuth (token) yang
merupakan valet key, mengizinkan bit.ly menggunakan Twitter Bob.
4. Bit.ly menyimpan credential penting Bob sepanjang Bob menggunakan account nya bit.ly mengizinkan Bob menggunakan layanan pada bit.ly dan hanya bit.ly mengakses twitter.com. Gambar 2.3 di bawah ini menjelaskan lalu lintas transaksi yang terjadi pada sistem otentikasi OAuth 1.0. Dan pada gambar 2.4 terlihat interface (antar muka) daripada bit.ly setelah sukses login menggunakan credential otentikasi OAuthaccountTwitter.
(26)
Gambar 2.3 Lalu Lintas Transaksi OAuth 1.0
(27)
2.3 OAuth 2.0
Terdapat 4 peran utama dalam mekanisme kerja OAuth 2 yakni[5] : 1. Resource Server
Resource server (Sumber Daya Server) yang digunakan oleh pengguna yang memiliki API (Application Programming Interface) dan dilindungi oleh OAuth. Resource server merupakan penerbit API yang memegang dan memiliki kekuasaan pengaturan data seperti foto, video, kontak, atau kalender.
2. Resource Owner
Memposisikan diri sebagai pemilik sumber daya (Resource Owner), yang merupakan pemilik dari aplikasi. Pemilik sumber daya memiliki kemampuan untuk mengakses sumber daya server dengan aplikasi yang sudah tersedia.
3. Client
Sebuah aplikasi yang membuat permintaan API pada Resource Server yang telah diproteksi untuk kepentingan pemilik Resource Owner dengan melakukan otorisasi.
4. Authorization Server
Authorization Server (Otorisasi Server) mendapat persetujuan dari pemilik sumber daya (Resource Owner) dengan melakukan dan memberikan akses token kepada client untuk mengakses sumber daya yang diproteksi yang sudah tersedia pada Resource Server.
Mekanisme kerja OAuth 2 terbentuk dari peran aktif 4 (empat) bagian yang terdiri dari : Client, Resource Owner, Authorization Server, Resource Server[8]. Gambar 2.5 menunjukkan mekanisme kerja OAuth 2[5], sedangkan pada tabel 2.1 menunjukkan keterangan dari tugas dan fungsi 4 (empat) komponen OAuth.
(28)
Gambar 2.5 Mekanisme Kinerja OAuth 2
Tabel 2.1 Tugas dan Fungsi 4 (empat) Komponen OAuth 2
KETERANGAN
A Client melakukan permintaan otorisasi dari Resource Owner. Permintaan otorisasi dapat dilakukan langsung menuju Resource Owner, atau jika tidak langsung melalui perantara Authorization Server.
B Client mendapatkan persetujuan otorisasi yang merupakan credential mewakili otorisasi kepemilikan client. Pemberian otorisasi ini tergantung pada metode yang digunakan oleh client dan jenis yang didukung oleh Authorization Server.
C Client melakukan permintaan akses token dengan otentikasi kepada Authorization Server, client mendapatkan penyajian hibah dan bentuk otorisasi dari Authorization Server.
D Otorisasi Server (Authorization Server) melakukan otentikasi kepada client dan memvalidasi pemberian otorisasi kepada client, jika sesuai dan berlaku, otorisasi server membagikan akses token.
(29)
E Client melakukan permintaan sumber daya yang sudah diproteksi dari Resource Server, melakukan tindakan otentikasi dengan menghadirkan akses token.
F Resource Server memvalidasi akses token, jika valid dan sesuai, akan melayani permintaan client untuk menggunakan aplikasi yang sudah terlindungi.
2.4Hibah Otorisasi (Authorization Grant)
Hibah otorisasi adalah mandat mewakili sumber daya pemilik otorisasi (Resouce Owner) untuk mengakses sumber daya yang dilindungi yang digunakan oleh client (pengunjung) untuk mendapatkan akses token. Ada beberapa metode hibah otorisasi :authorization code, implicit, resource owner password credential[8].
2.4.1 Authorization Code
Kode otorisasi diperoleh dengan menggunakan otorisasi server sebagai perantara antara client dan resource owner. Client melakukan permintaan otorisasi langsung dari resource owner, diarahkan menuju ke otorisasi server melalui user-agent (web browser) yang pada gilirannya mengarahkan pemilik sumber daya ke client dengan kode otorisasi[5].
2.4.2 Implicit
Hibah otorisasi implisit adalah hibah otorisasi yang disederhanakan dan dioptimalkan untuk client yang diimplementasikan dalam browser menggunakan bahasa scripting javascript. Dalam aliran otorisasi implicit, client diberikan langsung akses token sebagai hasil dari otorisasi pemilik sumber daya (resource owner) yang kemudian digunakan untuk mendapatkan akses token[5].
(30)
2.4.3 Resource Owner Password Credential
Sumber daya pemilik password credential seperti (username dan password) dapat digunakan langsung sebagai hibah otorisasi untuk mendapatkan akses token. Credential yang digunakan berdasarkan kepercayaan tingkat tinggi antara pemilik sumber daya dan client. Jenis hibah ini membutuhkan akses client langsung ke pemilik sumber daya credential yang digunakan untuk satu permintaan dan ditukar dengan akses token[5].
2.4.4 Client Credential
Kredensial klien adalah bentuk lain dari otentikasi klien yang digunakan sebagai hibah otorisasi terbatas pada sumber daya yang dilindungi di bawah pengawasan dan pengaturan klien. Atau ke sumber daya terlindungi yang sebelumnya telah di atur dengan server otorisasi. Kredensial klien digunakan sebagai otorisasi hibah ketika klien bertindak sebagai pemilik sumber daya (resource owner) atau meminta akses ke sumber daya yang dilindungi berdasarkan otorisasi yang sudah diatur dengan server otorisasi (resource server)[5].
2.5Access Token dan Refresh Token
2.5.1 Access Token
Adalah credential yang digunakan untuk mengakses sumber daya yang terlindungi. Akses token adalah kumpulan string yang mewakili suatu kuasa yang diberikan kepada client. Setiap token menyatakan batasan dan jangka waktu akses, yang diberikan oleh Resource Owner (pemilik sumber daya), yang berasal dari Resource Server (sumber server) dan Authorization Server (otorisasi server)[1]. Token dapat menunjukkan pengenal yang digunakan untuk mengambil informasi otorisasi atau mungkin data diri yang diverifikasi yaitu berupa tanda string yang terdiri dari
(31)
beberapa rangkaian data[8]. Akses token dapat memiliki format yang berbeda baik dalam struktur dan metode pemanfaatan.
2.5.2 Refresh Token
Refresh token adalah token credential yang digunakan untuk mendapatkan token akses yang baru. Merefresh kembali akses token yang dikeluarkan otorisasi server (authorization server) dan digunakan untuk mendapatkan akses token terbaru ketika akses token tidak menjadi sah atau akses token memiliki ruang lingkup yang lebih pendek yang diterbitkan oleh authorization server. Refresh token merupakan string yang mewakili otorisasi yang diberikan kepada client oleh pemilik sumber daya. Tidak seperti akses token, refresh token hanya digunakan untuk otorisasi server dengan tidak mengirimkan ke pemilik sumber daya (resource owner)[1].
2.6 Jenis Client Profile
OAuth 2 mendefenisikan beberapa jenis client profile penting sebagai berikut :
2.6.1 Server Side Web Application
Adalah salah satu dari client profile OAuth 2 yang berjalan pada sisi web server. Aplikasi web yang telah diakses oleh pemilik sumber daya ataupun pengguna, melakukan permintaan API (Application Programming Interface) memanggil penggunaan satu bahasa program yang berjalan pada sisi server[3].
2.6.2 Client Side User Agent Based Application
Adalah jenis client profile yang berjalan pada web browser pengguna, dimana client mendapatkan hak akses kode aplikasi ataupun permintaan API. Aplikasi dapat berupa
(32)
javascript yang terdapat di dalam sebuah halaman web bisa berupa browse extension, atau menggunakan teknologi plugin seperti Flash[3].
2.6.3 Resource Owner Password Flow
Adalah jenis client profile yang dimana resource owner (pemilik sumber daya) memiliki kepercayaan tingkat tinggi terhadap client. Kelemahan dari client profile berikut adalah otorisasi server harus berhati - hati saat mengijinkan hibah ke dalam aliran sistem yang bekerja, mengingat kepercayaan penuh yang sudah diberikan kepada client.
2.7 Workflow Client Profile
Workflow Client Profile pada OAuth 2 berdasarkan pada mekanisme kerja yang berjalan pada sisi client side ataupun server side. Di bawah ini adalah model kerja yang otentikasi OAuth 2 yang berjalan pada sisi server side, client side, resource owner password flow dan client credential.
2.7.1 Server Side Web Application Flow[3]
(33)
Tabel 2.2 Keterangan Server Side Web Application Flow
KETERANGAN
A Client memulai aliran menuju aplikasi pemilik sumber daya (Resource Owner) lewat perantara user-agent langsung menuju titik akhir otorisasi.
B Otorisasi Server mengotentikasi Resource Owner dan menetapkan apakah pemilik sumber daya memberikan atau menolak permintaan akses client. C Dengan asumsi client mendapatkan kuasa melakukan akses, otorisasi server
mengarahkan ulang user-agent kembali ke client menggunakan redirect url (redirect url termasuk kode otorisasi).
D Client meminta akses token dari otorisasi server termasuk didalamnya kode otorisasi (code authorization) yang sudah diterima sebelumnya. Ketika melakukan permintaan, client mengotentikasi dengan server otorisasi. Client termasuk url direction digunakan untuk memperoleh kode otorisasi untuk verifikasi.
E Otorisasi server mengotentikasi client, memvalidasi kode otorisasi dan memastikan url redirect di terima sesuai dengan url yang digunakan untuk mengarahkan client, jika valid otorisasi server merespon kembali dengan akses token dan opsional refresh token.
(34)
2.7.2 Client Side Web Application Flow[3]
Gambar 2.7 Client Side User Web Application Flow
Tabel 2.3 Keterangan Server Side Web Application Flow KETERANGAN
A Client memulai aliran dengan mengarahkan pemilik sumber daya (Resource Owner) lewat perantara user-agent menuju titik akhir otorisasi. Otorisasi Server akan mengirim kembali ke user-agent setelah akses diberikan atau ditolak.
B Otorisasi Server mengotentikasi pemilik sumber daya, dan menetapkan apakah pemilik sumber daya memberikan atau menolak permintaan akses client.
(35)
C Dengan asumsi pemilik sumber daya memberikan akses, otorisasi server mengarahkan ulang user-agent kembali ke client menggunakan redirect url sebelumnya. Pengalihan url termasuk akses token di dalam fragmen url
D User-agent mengikuti instruksi pengalihan dengan membuat permintaan sumber daya client web hosting dengan tetap mempertahankan informasi fragment lokal agar user-agent dapat mengeksekusi scripts yang disediakan web-host sumber daya client lokal yang mengektrak akses token dan lolos ke client.
2.7.3 Resource Owner Password Flow[3]
Gambar 8.Resource Owner Password Flow
Gambar 2.8 Resource Owner Password Flow Tabel 2.4 Keterangan Resource Owner Password Flow
KETERANGAN
A Pemilik sumber daya (resource owner) menyediakan client dengan nama pengguna (username) dan sandi (password)
B Client meminta sebuah akses token dari Authorization Server (otorisasi server) dengan memasukkan credential yang telah diterima dari pemilik
(36)
sumber daya (resource owner). Saat melakukan permintaan tersebut, client mengotentikasi dengan otorisasi server (authorization server).
C Server otorisasi mengotentikasi client dan memvalidasi credential dari pemilik sumber daya, dan jika berlaku, mendapatkan sebuah akses token.
2.8Proses Roles Authentication
2.8.1 Web Server Application
Aplikasi web yang berjalan pada sisi server adalah jenis paling umum yang dikembangkan oleh pemilik aplikasi (resource owner) yang didukung penuh pada OAuth Server. Aplikasi web pada bahasa pemrograman server-side seperti php, asp.net, jsp melakukan proses kerjanya pada sisi server yang tidak dipublikasikan untuk umum[2]. Proses yang terjadi dan berlaku saat seorang pengunjung melakukan kegiatan otentikasi dengan meng-klik tombol ”Log In” adalah pengunjung akan menerima rangkaian link pada alamat browser seperti pada gambar 2.9[11] :
Gambar 2.9 Proses Otentikasi Web Server Application
Beberapa parameter query yang terdapat pada rangkaian link alamat browser adalah sebagai berikut[4] :
1 client-id
Nilai yang diberikan saat mendaftarkan suatu aplikasi web yang dimiliki oleh Resource Owner.
2 redirect_uri
(37)
3 scope
Data aplikasi meminta akses menuju dan merujuk pada web developer penyedia OAuth. Jika berasal dari google api berarti merujuk ke halaman auth google api contoh : https://www.googleapis.com/auth/tasks.
4 response_type
Adalah kode server side web application flow yang mengindetifikasikan sebuah kode otorisasi yang akan dikembalikan lagi ke aplikasi setelah user menerima dan menyetujui permintaan otorisasi.
Pada sisi halaman browser, pengunjung di terbitkan suatu halaman pemberian izin hibah, untuk disetujui oleh pengunjung agar dapat dilakukan otorisasi oleh OAuth Server (Authorization Server). Gambar 2.10 memperlihatkan permintaan persetujuan dari pengunjung[11].
Gambar 2.10 Proses Otentikasi Web Server Application - 2
Jika pengunjung melakukan proses tindakan ”Allow”, maka sistem yang bekerja akan mengarahkan kembali pada aplikasi web dengan sebuah Auth Code. Auth Code untuk suatu aplikasi web memiliki kode unique dan berbeda, yang setiap aplikasi jika didaftarkan pada salah satu penerbit OAuth seperti Google akan
(38)
mendapatkan auth code tertentu. Pada gambar 2.11 memperlihatkan sebuah halaman dengan auth code. Pada gambar 2.12 adalah auth code yang didapat saat didaftarkan pada layanan OAuth yang tersedia pada Google API[4].
Gambar 2.11 Proses Otentikasi Web Server Application - 3
Gambar 2.12 Auth Code dari Google API
Authorization Server (otorisasi server) kemudian mengubah auth code untuk sebuah akses token, dan alamat pada browser akan terlihat seperti pada gambar 2.13[11]. di bawah ini :
(39)
Gambar 2.13 Halaman Auth Code dari Google API Keterangan[3] :
1. client_id
Nilai id yang diberikan saat mendaftarkan suatu aplikasi 2. client_secret
Kepercayaan yang bersifat rahasia diberikan saat mendaftar aplikasi 3. grant_type
Nilai suatu authorization_code, mengidentifikasikan penukaran sebuah kode otorisasi pada suatu akses token.
4. code
Kode otorisasi yang dikirimkan ke aplikasi 5. redirect_uri
Lokasi yang telah terdaftar dan digunakan pada permintaan awal menuju otorisasi Kemudian otorisasi server menggantikannya dengan sebuah akses token seperti yang terlihat pada gambar 2.14 Dan jika terdapat error pada akses token akan terlihat seperti pada gambar 2.15.
(40)
Gambar 2.15 Proses Otentikasi Web Server Application - 5
Adapun beberapa kondisi error yang terjadi pada alamat url (uniform resource locator) dan ditampilkan pada halaman browser seperti[3] :
1. invalid_request
Adalah permintaan yang tidak valid, parameter mengalami kekurangan atau nilai parameter yang tidak sesuai atau tidak didukung.
2. unauthorized_client
Client tidak mempunyai kewenangan untuk meminta kode otorisasi menggunakan metode mendapatkan token.
3. unsupported_response_type
Otorisasi server tidak mendukung mendapatkan kode otorisasi menggunakan salah satu metode mendapatkan token.
4. invalid_scope
cakupan yang diminta tidak valid, tidak diketahui dan tidak sesuai (cacat). 5. server_error
Otorisasi server mengalami masalah sehingga tidak dapat mencegah masalah dan memenuhi permintaan penyesuaian token.
6. temporarily_unavailable
Keberadaan dan kondisi dariAuthorization Server (otorisasi server) yang tidak dapat menangani permintaan karena overloading atau maintenance server.
2.8.2 Browser Based Application
Aplikasi browser dijalankan sepenuhnya dalam browser setelah memuat suatu kode sumber dari suatu halaman web. Karena seluruh kode sumber tersedia untuk dan pada browser, sehingga kerahasiaan dari rahasia client, tidak digunakan pada aplikasi
(41)
ini[11]. Proses yang tercipta apabila seorang pengunjung melakukan kegiatan otentikasi dengan meng-klik tombol ”Log In” pada aplikasi browser adalah seperti yang ditunjukkan pada gambar 2.16 di bawah ini :
Gambar 2.16 Proses Otentikasi Browser Based Application
Kemudian pengunjung akan diarahkan pada suatu halaman pemberian izin hibah, agar pengunjung dapat melakukan pemberian izin hibah yang akan di proses kembali oleh otorisasi server (authorization server). Gambar 2.17 berikut menunjukkan halaman browser persetujuan pemberian hibah oleh pengunjung[11].
Gambar 2.17 Proses Otentikasi Browser Based Application - 2
Jika pengunjung melakukan tindakan dengan menekan tombol ”Allow”, layar browser akan diarahkan menuju aplikasi dengan menghadirkan sebuah akses token. Pada gambar 2.18 adalah proses yang terdapat alamat HTTP (Hypertext Transfer
(42)
Protocol) saat pengunjung menekan tombol ”Allow” dengan menampilkan akses token.
Gambar 2.18 Proses Otentikasi Browser Based Application- 3
Selesai. Akses token diterima pada browser dengan memanggil kumpulan kode javascript yang bisa mengeluarkan kode token akses dari fragment (setelah tanda #) dan mulai membuat permintaan OAuth API[11]. Jika terdapat kesalahan, halaman akan menerima kode kesalahan dalam fragment url yang terdapat pada gambar 2.19 di bawah ini :
Gambar 2.19 Proses Otentikasi Browser Based Application - 4
2.9 Sistem Informasi
2.9.1 Pengertian Sistem
Menurut Prof. Dr. Mr. S. Prajudi A. mendefinisikan sistem adalah suatu yang terdiri dari obyek, unsur-unsur atau komponen - komponen yang berkaitan dan berhubungan satu sama lainnya, sehingga unsur-unsur tersebut merupakan satu kesatuan proses. Secara sederhana, suatu sistem dapat diartikan sebagai suatu kumpulan atau himpunan dari unsur, komponen, atau variabel yang terorganisir, saling berinteraksi, saling tergantung satu sama lain, dan terpadu[12].
(43)
2.9.2 Pengertian Informasi
Secara umum informasi dapat didefinisikan sebagai hasil dari pengolahan data dalam suatu bentuk yang lebih berguna dan lebih berarti bagi penerimanya yang menggambarkan suatu kejadian - kejadian yang nyata yang digunakan untuk pengambilan keputusan. Informasi merupakan data yang telah diklasifikasikan atau diolah atau diinterpretasi untuk digunakan dalam proses pengambilan keputusan[12].
2.9.3 Konsep Sistem Informasi
Sistem informasi adalah suatu sistem dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian yang mendukung fungsi operasi organisasi yang bersifat manajerial dengan kegiatan strategi dari suatu organisasi untuk dapat menyediakankepada pihak luar tertentu dengan informasi yang diperlukan untuk pengambilan keputusan[12].
Sistem informasi dalam suatu organisasi dapat dikatakan sebagai suatu sistem yang menyediakan informasi bagi semua tingkatan dalam organisasi tersebut kapan saja diperlukan. Sistem ini menyimpan, mengambil, mengubah, mengolah dan mengkomunikasikan informasi yang diterima dengan menggunakan sistem informasi atau peralatan sistem lainnya.
(44)
BAB 3
ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Permasalahan
Belakangan saat ini, pengembangan web dengan fungsi tertentu, telah memiliki login alternatif atau solusi login yang berbeda yakni di antaranya penggunaan OAuth untuk menghindari client atau pengunjung melakukan registrasi pada web yang memerlukan account untuk bisa mengakses aplikasi yang telah terproteksi (protected resource). Mereka mempercayakan account pihak ketiga (third party) yang bisa melakukan “sign-in” pada aplikasi web yang sudah di kembangkan.
Pada penelitian yang penulis lakukan, pengunjung yang bertindak sebagai client akan melakukan login yang di bangun berdasarkan teknologi OAuth 2, dimana account setiap client bukan berasal dari pihak yang dipercayakan (seperti situs social media) tapi di bangun dan di kembangkan sendiri menggunakan bahasa pemrograman PHP (Hypertext Preprocessor). Dengan account tersebut setiap client akan di arahkan pada satu halaman untuk melakukan otorisasi aplikasi terlebih dahulu, untuk dapat menghadirkan sebuah access token yang dapat terlihat pada pengalamatan http (hypertext transfer protocol). Proses otorisasi tersebut mengandalkan sebuah authorization server yang merupakan resource server itu sendiri, memproses otorisasi keabsahan account dari suatu client yang melakukan aktivitas “sign-in”.
Analisis permasalahan pada sistem yang dirancang dapat diilustrasikan seperti diagram ishikawa gambar 3.1 di bawah ini.
(45)
Gambar 3.1 Diagram Ishikawa Analisis Masalah
3.2 Analisis Kebutuhan Sistem
Pada sistem yang akan dibangun, perlu rencana pembangunan sistem yang dapat merumuskan tujuan yang dicapai. Agar hal itu tercapai, di kelompokkan apa saja yang menjadi kebutuhan pada sistem yang dapat di kategorikan menjadi 2 (dua) bagian yaitu : kebutuhan fungsional dan kebutuhan non fungsional.
1. Kebutuhan fungsional adalah kebutuhan yang menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi pada sistem yang di bangun. Adapun kebutuhan fungsional pada sistem yang dirancang adalah sebagai berikut : a. Sistem mampu memberikan layanan penambahan client sebagai account yang
terdaftar pada aplikasi web single sign on .
b. Sistem memiliki field sign-in credential yang digunakan sebagai pengganti username dan password yakni client id dan client secret yang bertipe string. c. Sistem menyediakan proses otorisasi account setiap client, di proses oleh
authorization server yang datanya ditampung pada basis data yang telah dibuat.
Machine Method
People Material MySQL 5.5 Workflow Server Side Web Application OAuth 2
Melakukan kegiatan
Pendaftaran Client
Tabel Clients
Melakukan Aktivitas
Sign In metode
OAuth 2
Tabel Tokens Tabel Reservasi
PHP 5.3 Apache Web Server
Penerapan
Authorization Server dan
Resource Server
Otentikasi
(46)
d. Sistem mampu menghasilkan akses token yang berupa rangkaian string yang panjang dan berbeda, yang bekerja pada layer protokol http (hypertext transfer protocol).
e. Sistem mampu menerapkan 3 (tiga) halaman sign in untuk menuju pada salah satu ataupun ketiga aplikasi berbasis web dengan sekali melakukan sign in.
2. Kebutuhan non fungsional adalah kebutuhan yang tidak secara langsung menunjukkan fungsi khusus yang harus ada pada sistem. Adapun kebutuhan non fungsional yang harus dimiliki adalah :
a. Performa
Sistem harus mampu melaksanakan tugasnya dengan waktu yang tidak terlalu lama sehingga tidak banyak menghabiskan waktu pengguna.
b. Informasi
Sistem harus mampu menyediakan informasi tentang data yang akan digunakan pada sistem.
a. Ekonomi
Sistem harus dapat bekerja dengan baik tanpa harus mengeluarkan biaya tambahan dalam penggunaan perangkat keras maupun perangkat lunak.
b. Kontrol
Sistem yang telah dibangun harus dikontrol agar fungsi dan kinerja sistem tetap terjaga dan dapat memberikan hasil yang sesuai dengan keinginan pengguna.
c. Efisiensi
Sistem harus dapat dirancang bersifat user-friendly agar memudahkan pengguna dalam menjalankan aplikasi tersebut.
d. Pelayanan
Sistem yang telah dibangun dapat dikembangkan ke tingkat yang lebih kompleks lagi, bagi pihak yang ingin mengembangkan sistem tersebut.
(47)
3.3 Analisis Teknologi OAuth 2
Teknologi otentikasi yang diterapkan pada prosedur pemrosesan otentikasi “sign-in” setiap client menggunakan teknologi OAuth 2. Teknologi otentikasi OAuth 2 memiliki perbedaan jika di bandingkan dengan teknologi otentikasi lainnya ataupun otentikasi yang mengandalkan fitur session pada penerapannya. Gambar 3.2 di bawah ini adalah struktur cara kerja otentikasi OAuth 2 yang diilustrasikan berjalan pada aplikasi website seperti aplikasi cafe yang dibangun oleh penulis.
(48)
Tabel 3.1 Keterangan Proses Kerja Teknologi OAuth 2
Proses Keterangan Proses
A Client yang mengakses aplikasi milik sumber daya (Resource Owner) lewat perantara user-agent (browser) menuju authorization server setelah melakukan “sign-in” pada aplikasi web.
B Otorisasi Server (Authorization Server) mengotentikasi client id kepemilikan pengunjung (client), menetapkan apakah pemilik sumber daya memberikan atau menolak permintaan client untuk mengakses aplikasi web.
C Dengan asumsi client mendapatkan kuasa melakukan akses, otorisasi server (authorization server) mengarahkan ulang user-agent kembali ke client beserta kode otorisasi.
D Client yang sudah menerima kode otorisasi (authorization code) sebelumnya, mendapatkan perintah yang di terima di user-agent (browser) berupa authorize app, persetujuan melakukan otorisasi yang di kirim ke authorization server.
E Jika client melakukan otorisasi, access token akan dihadirkan bersamaan dengan dihantarkannya client pada halaman utama aplikasi web.
Authorization server di rancang bersamaan pada web aplikasi yang di kerjakan yakni aplikasi cafe online yang dapat di tempatkan pada localhost ataupun berjalan pada internet. Schema jaringan pada gambar 3.3 di bawah ini akan menjelaskan bentuk workflow dari otentikasi OAuth 2 pada aplikasi yang di bangun.
(49)
Gambar 3.3 Schema Jaringan OAuth 2
Tabel 3.2 Keterangan Proses Schema Jaringan OAuth 2
Proses Keterangan Proses
1 Client mengakses aplikasi milik sumber daya (Resource Owner) yaitu aplikasi web single sign on menggunakan browser melakukan “sign-in” pada aplikasi web.
2 Account dari kepemilikan pengunjung (client), di tetapkan dan di proses pada authorization server, apakah sesuai dengan data account yang terdapat pada basis data resource server.
3 Dengan asumsi account dari client dinyatakan valid, otorisasi server (authorization server) melakukan pengecekan otorisasi kebenaran credential milik client lewat perantara browser.
4 Client yang dinyatakan sesuai, akan mendapatkan halaman authorize app, yang merupakan halaman persetujuan melakukan otorisasi yang di kirim ke authorization server.
A B
C
1
2 3
4
(50)
5 Jika client melakukan otorisasi, akses token akan dihadirkan bersamaan dengan di hantarkannya client pada halaman utama aplikasi web single sign on
3.4 Perancangan Sistem
Perancangan sistem adalah proses menyusun dan mengembangkan sistem yang sudah di dapat dari hasil analisis. Perancangan dilakukan agar sistem tidak lari dari hasil analisis yang sudah ditetapkan, juga memberikan gambaran yang jelas dan lengkap bagaimana aplikasi akan dikerjakan. Maka perlu dibuat rancangan aplikasi berupa deskripsi sistem serta batasan - batasan yang diberikan, rancangan aplikasi dalam bentuk DFD (Data Flow Diagram), rancangan basis data, flowchart, dan rancangan tampilan aplikasi.
3.4.1 Deskripsi Sistem
Pada deskripsi sistem akan dibahas fungsi utama dari sistem yang dibangun serta batasan - batasan dalam membangun sistem.
3.4.1.1 Fungsi Utama
Fungsi utama dari sistem yang di bangun adalah sistem mampu melakukan otorisasi hak akses pengguna yang di proses oleh authorization server yang diciptakan sendiri oleh resource owner sebagai pemilik aplikasi, menghasilkan akses token berupa rangkaian string yang berbeda untuk setiap client sebagai pemilik hak akses yang sah pada aplikasi web single sign on.
(51)
3.4.1.2 Batasan
Adapun batasan dari sistem yang akan dibangun adalah :
1. Perancangan login otentikasi berbasis teknologi OAuth 2 dan aplikasi layanan cafe online menggunakan bahasa pemrograman PHP (Hypertext Preprocessor) serta menggunakan Database Management System MySQL.
2. Permintaan otorisasi dari client di proses oleh Authorization Server yang data setiap client di tampung pada basis data.
3. Authorization Server akan menghasilkan halaman persetujuan otorisasi (Authorize App) sebagai bentuk otoritas client yang sah untuk mengakses aplikasi.
4. Client yang melakukan permintaan hak akses penuh menggunakan aplikasi pelayanan web single sign on, akan menghasilkan akses token yang muncul di pengalamatan http (hypertext transfer protocol), jika meniadakan, akses token tidak dihasilkan.
5. Redirect uri yang dituju, disesuaikan dengan pengalamatan aplikasi web single signon yang dibangun.
3.4.2 DFD (Data Flow Diagram)
Data Flow Diagram adalah alat pembuatan model yang memungkinkan pemilik sistem untuk mengambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi. DFD dari aplikasi yang dibuat dimulai dari DFD level 0 hingga DFD level 2.
3.4.2.1Diagram Konteks
Aliran data bersumber dari client yang dimasukkan ke dalam sistem, yang kemudian akan di proses dan menghasilkan output. client menginput data registrasi pada
(52)
aplikasi penambahan client pada sistem seperti client id, client secret, dan redirect uri serta keterangan lain yang dibutuhkan pada sistem ini.
Gambar 3.4 DFD Level 0
Penjelasan proses diagram konteks DFD yaitu sebagai berikut : a. Arus Data
Masukan :
• Data client
• reservasi Keluaran :
• data client dan web aplikasi sso
• Hak Akses web aplikasi sso
b. Entitas Luar
Nama Entitas : Resource Owner
Keterangan : Merupakan pemilik web aplikasi sso (single sign on), juga pihak yang mengontrol dan memperbaiki sistem.
Keluaran :
• Respon data id_client, redirect uri Nama Entitas : Client
Sistem Otentikasi
OAuth 2
Client Resource Owner
data client
Web Application SSO hak akses
hak akses
data client, redirect uri 0
id_client
hak akses Web Application
(53)
Keterangan : Pengguna yang menggunakan sistem aplikasi web single sign on. Masukan :
• client id
• client secret
• redirect uri Keluaran :
• access token
• Akses web single sign on
3.4.2.2Data Flow Diagram Level 1
Proses yang ada pada DFD level 0 dipecah lagi menjadi proses-proses yang lebih kecil dan lengkap dalam DFD level 1.
Gambar 3.5 Data Flow Diagram Level 1
0 Register 1 Login 2 Melakukan Otentikasi dan Otorisasi OAuth 2 3
Akses Web
Application SSO (Single Sign On)
clients
tokens
reservasi client
Resource owner
client id, client secret, redirect uri client id, client secret, redirect uri
client_id, response_type, redirect_uri
client id, client secret client id, client secret
client_id, response_type, redirect_uri
data client data client
data client data client
authorize app authorize app
Pembaharuan data client
management data client
reservasi
pembaharuan data reservasi
manage data resevasi data resevasi
data resevasi
(54)
Penjelasan proses DFD level 1 adalah sebagai berikut : 1. Proses 1
Nama Proses : Proses Register
Masukan : - client id, client secret - redirect uri
Keluaran : - data client 2. Proses 2
Nama Proses : Proses Login Masukan : - client id
- client secret Keluaran : - redirect uri
- response_type
Keterangan : Pada proses ini client akan mendapatkan parameter - parameter dari action post yang di input client saat melakukan aktivitas login.
3. Proses 3
Nama Proses : Melakukan Otentikasi dan Otorisasi OAuth 2 Masukan : data client
Keluaran : halaman authorize app
Keterangan : Pada proses ini client akan mendapatkan sebuah halaman otorisasi akhir pada aplikasi sistem cafe online.
4. Proses 4
Nama Proses : Akses Aplikasi Cafe Masukan : reservasi
Keluaran : data reservasi
Keterangan : Pada proses ini client dapat melakukan aktivitas reservasi pada sistem.
(55)
3.4.2.3Data Flow Diagram Level 2
Gambar 3.6 Data Flow Diagram Level 2
Penjelasan proses DFD level 2 adalah sebagai berikut :
a. Nama Proses : Melakukan Otentikasi dan Otorisasi OAuth 2 Masukan : data client
Keluaran : authorize app
Keterangan : Menghasilkan halaman authorize app dari sistem web aplikasi sso yang client di minta untuk melakukan otorisasi pada aplikasi. b. Nama Proses : Menghasilkan Aksen Token
Masukan : persetujuan authorize app Keluaran : access token
Keterangan : Melakukan persetujuan halaman authorize app yang menghantar kan client ke halaman aplikasi utama dengan menghasilkan token.
3.1 Melakukan Otentikasi dan
Otorisasi OAuth 2 client
data client data client
authorize app authorize app
tokens
3.2 Menghasilkan
Akses Token
authorize app “Yes” authorize app “Yes”
(56)
3.4.3 Perancangan Basis Data
Basis Data atau dalam bahasa inggris disebut database adalah sekumpulan informasi yang disimpan di dalam komputer secara sistematik sehingga dapat di periksa menggunakan suatu bahasa pemrograman komputer untuk memperoleh informasi dari basis data tersebut. Di dalam perancangan resource server dan authorization server OAuth ini diperlukan 2 (dua) database yakni database heaven dan database oauth2-heaven meliputi tabel - tabel yang berada di dalamnya. Di dalam database heaven diperlukan tabel reservasi seperti yang ditunjukkan pada tabel 3.5, database oauth2-heaven diperlukan untuk tabel clients dan tabel tokens seperti pada tabel 3.6 dan 3.7.
Tabel 3.5 Tabel Reservasi
Field Type Length PrimaryKey Autoincrement
ID INT 5 * *
nama Varchar 30
tgl_reservasi Varchar 20
gender Varchar 8
Hp Varchar 13
message Varchar 350
Tabel 3.6 Tabel Clients
Field Type Length PrimaryKey Autoincrement
client_id Varchar 20 *
client_secret Varchar 20 redirect_uri Varchar 200
(57)
Tabel 3.7 Tabel Tokens Database : heaven-oauth
Field Type Length PrimaryKey Autoincrement
oauth_token Varchar 40 *
client_id Varchar 20
expires INT 11
scope Varchar 250
3.4.4 Flowchart Sistem
Flowchart adalah suatu bagan dengan simbol - simbol tertentu yang menggambarkan urutan proses secara mendetail dan hubungan antara suatu proses (instruksi) dengan proses lainnya dalam suatu program atau prosedur sistem secara logika. Pada perancangan flowchart yang terjadi pada sistem otentikasi OAuth terbagi menjadi dua mekanisme yakni flowchart sistem aplikasi secara umum dan flowchart otentikasi OAuth 2 yang diterapkan pada sistem.
(58)
3.4.4.1 Flowchart Sistem Aplikasi Secara Umum
Gambar 3.7 Flowchart Sistem Aplikasi Secara Umum
Prosedur flowchart di atas merupakan gambaran sistem aplikasi secara umum. Sistem diatas memberikan petunjuk bahwa ada proses otentikasi OAuth yang harus di lalui oleh pengunjung untuk dapat masuk dan menerima akses layanan yang tersedia pada aplikasi. Di bawah ini adalah prosedur kerja dari flowchart di atas :
1. Mulai.
2. Melakukan “sign-in” pada sistem aplikasi.
3. Data credential client berupa client id dan client secret di proses menggunakan teknologi otentikasi OAuth.
(59)
4. Di asumsikan data client adalah sesuai, client dapat menerima layanan yang tersedia pada sistem aplikasi web single sign on.
5. Client dapat memilih akses salah satu pada web aplikasi single sign on. Dengan melakukan akses pada web aplikasi pertama, kedua ataupun ketiga. 6. Selesai.
3.4.4.2 Flowchart Otentikasi OAuth 2
(60)
Prosedur flowchart di atas di gunakan untuk memproses credential dari client apakah valid atau tidak, menggunakan prosedur teknologi otentikasi OAuth. Di bawah ini akan di jelaskan prosesnya secara terperinci :
1. Mulai.
2. Client menginput client id, client secret dan redirect uri
3. Client melakukan tindakan “sign-in” menuju aplikasi. Jika client sesuai maka proses otentikasi dilanjutkan menggunakan teknologi OAuth.
4. Proses otentikasi OAuth dilakukan untuk mengecek keabsahan dari data client, Dengan melakukan otorisasi untuk menghadirkan halaman Authorize App. 5. Halaman persetujuan otorisasi pada halaman Authorize App merupakan
halaman melakukan tindakan persetujuan otoritas untuk mendapat akses token.
6. Client yang melakukan tindakan persetujuan akan di arahkan browser menuju halaman utama sistem aplikasi single sign on, ditandai dengan keluarnya akses token pada alamat browser.
7. Jika client tidak melakukan tindakan persetujuan maka browser akan mengeluarkan keterangan error yang berarti client tidak dapat mengakses aplikasi utama.
8. Selesai.
3.4.5 Perancangan Tampilan
Perancangan tampilan pada implementasi resource server dan authorization server otentikasi oauth pada web aplikasi single sign on di maksudkan sebagai gambaran umum user interface dalam penerapan perancangan aplikasi yang sebenarnya antara pengguna dengan komputer.
(61)
3.4.5.1Rancangan Halaman Tambah Client
Halaman ini dimaksudkan atau diperuntukkan untuk kegiatan menambah pengunjung baru yang digunakan dalam otorisasi hak akses menggunakan web aplikasi single sign oncredential pengunjung yang ciri khasnya menggunakan username dan password di ganti sesuai dengan model workflow otentikasi OAuth 2 yakni client id dan client secret. Pada gambar 3.9 di bawah ini adalah halaman perancangan tambah client yang terdapat pada web aplikasi single sign on.
Gambar 3.9 Rancangan Tampilan Halaman Tambah Client Keterangan :
1. Canvas yang memuat logo dari aplikasi web aplikasi dengan link - link halaman
2. Canvas yang memuat dari slogan web
1 2
3 4 5 6
(62)
3. Label yang berisikan “masukan client id” lengkap dengan input text 4. Label yang berisikan “masukan client secret” lengkap dengan input text 5. Label yang berisikan “redirect uri” lengkap dengan input text
6. Tombol button yang terdiri dari tombol tambah dan batal
7. Bagian footer berisi tentang hak cipta dan tahun aplikasi dilaunchingkan
3.4.5.2 Rancangan Halaman Sign In
Halaman ini diperuntukkan bagi pengunjung untuk melakukan “sign-in” menuju halaman utama aplikasi. Tersedia inputan yang terdiri dari client id dan client secret. Pada gambar 3.10 di bawah ini adalah model rancangan dari halaman “sign-in”. Tersedia link jika pengunjung belum mendaftar, silahkan melakukan pendaftaran.
Gambar 3.10 Rancangan Tampilan Halaman Sign-In
1 2
3 4 5 6
(63)
Keterangan :
1. Canvas yang memuat logo dari aplikasi web dengan link - link halaman 2. Canvas yang memuat dari slogan web
3. Label yang berisikan “client id” lengkap dengan input text 4. Label yang berisikan “client secret” lengkap dengan input text 5. Label keterangan “Belum Terdaftar, silahkan klik disini” 6. Tombol button yang terdiri dari tombol Kirim dan Batal
7. Bagian footer berisi tentang hak cipta dan tahun aplikasi dilaunchingkan
3.4.5.3 Rancangan Halaman Utama
Gambar 3.11 Rancangan Tampilan Halaman Utama
1 2
3
4
5
(64)
Keterangan :
1. Canvas yang memuat logo dari aplikasi webdengan link - link halaman 2. Canvas yang memuat dari slogan web
3. Image slider yang terdiri dari 3 image yang melakukan animasi transisi 4. Image feature sebagai image keterangan kondisi web
5. Isi dari halaman utama sisi kiri dan sisi kanan
6. Bagian footer berisi tentang hak cipta dan tahun aplikasi dilaunchingkan
3.4.5.4 Rancangan Halaman Menu Dan Harga
Halaman ini di rancang untuk pengunjung agar dapat menikmati layanan dari web aplikasi single sign on, berupa informasi aneka menu lengkap dengan daftar harganya. Adapun ilustrasi halaman menu dan harga dapat dilihat seperti gambar 3.12 di bawah ini :
Gambar 3.12 Rancangan Tampilan Halaman Menu dan Harga
1 2 3
5
4
(65)
Keterangan :
1. Canvas yang memuat logo dari aplikasi webdengan link - link halaman 2. Canvas yang memuat dari slogan web
3. Image dan keterangan dari hidangan spesial 4. List daftar harga menu
5. List image dari menu - menu yang tersedia lengkap dengan harga
6. Bagian footer berisi tentang hak cipta dan tahun aplikasi dilaunchingkan
3.4.5.5 Rancangan Halaman Reservasi
Halaman ini bertujuan agar pengunjung dapat melakukan pemesanan tempat untuk suatu acara tertentu, dan di hari tertentu. Adapun ilustrasi halaman reservasi dapat dilihat seperti gambar 3.13 di bawah ini :
Gambar 3.13 Rancangan Tampilan Halaman Reservasi
1 2
3 4
5
(66)
Keterangan :
1. Canvas yang memuat logo dari aplikasi web dengan link - link halaman 2. Canvas yang memuat dari slogan web
3. Image dan keterangan dari hidangan spesial 4. List daftar harga menu
5. Form Reservasi untuk melakukan pemesanan tempat
6. Bagian footer berisi tentang hak cipta dan tahun aplikasi dilaunchingkan
3.4.6 Pseudocode
Pseudocode adalah deskripsi dari algoritma program komputer yang menggunakan struktur sederhana dari beberapa bahasa pemrograman, tetapi bahasa tersebut hanya ditujukan agar dapat dipahami manusia. Tujuan penggunaan utama dari pseudocode adalah untuk memudahkan manusia dalam memahami prinsip-prinsip dari suatu algoritma ataupun metode. Dari aplikasi sistem yang dibangun, pseudocode mengenai teknologi otentikasi OAuth 2 akan di jabarkan seperti pada tabel 3.8 di bawah ini.
Tabel 3.8 Kode Program Untuk Membuat Kode OAuth 2
No Kode
1 define("PDO_DSN",
"mysql:dbname=heaven-oauth;host=localhost"); define("PDO_USER", "root"); define("PDO_PASS", "root"); 2 include "oauth.php";
3 class PDOOAuth2 extends OAuth2 {
private $db;
public function __construct() { parent::__construct(); try {
$this->db = new PDO(PDO_DSN, PDO_USER, PDO_PASS);
(67)
} catch (PDOException $e) {
die('Connection failed: ' . $e->getMessage());
} }
function __destruct() { $this->db = null; }
private function handle_exception($e) {
echo "Database error: " . $e->getMessage(); exit;
}
4 public function add_client($client_id, $client_secret, $redirect_uri) {
try {
$sql = "insert into clients (client_id, client_secret, redirect_uri) values (:client_id, :client_secret, :redirect_uri)";
$stmt = $this->db->prepare($sql);
$stmt->bindParam(":client_id", $client_id, PDO::PARAM_STR); $stmt->bindParam(":client_secret", $client_secret, PDO::PARAM_STR); $stmt->bindParam(":redirect_uri", $redirect_uri, PDO::PARAM_STR); $stmt->execute();
} catch (PDOException $e) { $this->handle_exception($e); }
}
5 protected function auth_client_credentials($client_id, $client_secret = null) {
try {
$sql = "select client_secret from clients where client_id = :client_id";
$stmt = $this->db->prepare($sql);
$stmt->bindParam(":client_id", $client_id, PDO::PARAM_STR);
$stmt->execute();
$result = $stmt->fetch(PDO::FETCH_ASSOC); if ($client_secret === null)
return $result !== false; return $result["client_secret"] == $client_secret;
(1)
if($this->old_refresh_token)
$this->expire_refresh_token($this->old_refresh_token); }
return $token; }
private function create_auth_code($client_id, $redirect_uri, $scope) {
$code = $this->gen_auth_code();
$this->store_auth_code($code, $client_id, $redirect_uri, time() + $this->auth_code_lifetime, $scope);
return $code; }
protected function gen_access_token() {
return base64_encode(pack('N6', mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand()));
}
protected function gen_auth_code() {
return base64_encode(pack('N6', mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand(), mt_rand()));
}
private function get_authorization_header() {
if (array_key_exists("HTTP_AUTHORIZATION", $_SERVER)) return $_SERVER["HTTP_AUTHORIZATION"];
if (function_exists("apache_request_headers")) { $headers = apache_request_headers();
if (array_key_exists("Authorization", $headers)) return $headers["Authorization"];
}
return false; }
private function send_json_headers() {
header("Content-Type: application/json"); header("Cache-Control: no-store");
}
public function error($code, $message = null, $description = null) {
header("HTTP/1.1 " . $code); if ($message)
{
$this->send_json_headers();
$response = array("error" => $message); if(ERROR_VERBOSE && $description)
(2)
echo json_encode($response); }
exit; }
public function callback_error
($redirect_uri, $error, $state, $message = null, $error_uri = null) {
$result["query"]["error"] = $error; if ($state)
$result["query"]["state"] = $state; if ($message)
$result["query"]["error_description"] = $message; if ($error_uri)
$result["query"]["error_uri"] = $error_uri;
$this->do_redirect_uri_callback($redirect_uri, $result); }
}
index.php (halaman utama cafe)
<body id="page1">
<!--=========================header=================================-->
<header>
<div class="row-top"> <div class="main"> <div class="wrapper">
<h1><a href="index.php"><span>Heaven</span>Cafe</a></h1> <nav>
<ul class="menu">
<li><a class="active" href="index.php">About</a></li> <li><a href="menu.php">Menu</a></li>
<li><a href="reservasi.php">Reservasi</a></li> </ul>
</nav> </div> </div> </div>
<div class="row-bot">
<div class="row-bot-bg"> <div class="main">
<h2>Bergaya Lokal <span>Berkelas Dunia</span></h2> <div class="slider-wrapper">
(3)
<div class="slider"> <ul class="items"> <li>
<img src="images/slider-img1.jpg" alt="" /> </li>
<li>
<img src="images/slider-img2.jpg" alt="" /> </li>
<li>
<img src="images/slider-img3.jpg" alt="" /> </li>
</ul> </div> </div> </div> </div> </div> </header>
<!--=========================content================================--> <section id="content">
<div class="main">
<div class="wrapper img-indent-bot"> <article class="col-1">
<a href="#">
<img class="img-border" src="images/ban-1.jpg" alt=""> </a>
</article>
<article class="col-1">
<a href="#"><img class="img-border" src="images/ban-2.jpg" alt=""> </a>
</article>
<article class="col-2">
<a href="#"><img class="img-border" src="images/ban-3.jpg" alt=""> </a>
</article> </div>
<div class="wrapper">
<article class="column-1"> <div class="indent-left">
<div class="maxheight indent-bot"> <h3>Kami Melayani</h3>
<ul class="list-1">
<li><a href="#">Melayani - 1</a></li> <li><a href="#">Melayani - 2</a></li>
(4)
<li><a href="#">Melayani - 3</a></li> <li><a href="#">Melayani - 4</a></li> <li><a href="#">Melayani - 5</a></li> <li><a href="#">Melayani - 6</a></li> <li><a href="#">Melayani - 7</a></li> </ul>
</div>
<!-- <a class="button-1" href="#">Read More</a> --> </div>
</article>
<article class="column-2">
<div class="maxheight indent-bot"> <h3 class="p1">Tentang Kami</h3>
<h6 class="p2">Heaven Cafe adalah cafe dengan menyediakan solusi layanan yang bersifat online. Aplikasi website ini diperuntukkan untuk semua pengunjung setia cafe kami. Terimakasih buat semuanya.</h6>
<p class="p2">Aplikasi cafe pada website ini kami rancang sedemikian rupa, agar kami dapat memberikan yang terbaik dalam pelayanan dan layanan kami.</p> <p class="p2">Semoga dengan hadirnya aplikasi cafe ini akan enambah dan meningkatkan kualitas pelayanan kami kepada anda semua. Terima kasih.</p> </div>
<!-- <a class="button-2" href="#">Read More</a> --> </article>
</div> </div>
(5)
(6)