openid logo
Setiap anda akan mengakses bank account,
social network, email dan layanan lain, anda memerlukan identitas
digital. Dalam artikel ini saya membahas tentang OpenID sebagai bentuk
baru identitas digital anda yang akan memudahkan mengelola identitas
anda.
Security pada OpenID akan saya bahas pada artikel saya berikutnya, dalam artikel ini sifatnya hanya konsep dasar dan perkenalan.
Digital Identity
Identitas adalah atribut yang membuat berbeda dengan yang lain.
Identitas adalah kumpulan atribut yang membedakan sesuatu dengan yang
lainnya. Nama saja tidak bisa dijadikan identitas seseorang karena
kemungkinan banyak orang yang bernama sama. Biasanya identitas seseorang
ditunjukkan dengan ID Card yang berisi kumpulan atribut, antara lain:
nama, alamat, tanggal lahir. Bila nama saja tidak cukup membedakan
seseorang dengan yang lain, maka kumpulan dari nama, alamat, tanggal
lahir akan membuatnya unik (berbeda dengan yang lain).
Berbeda dengan di dunia nyata, di internet biasanya nama (username) atau
alamat email memang harus unik dari awalnya. Tidak mungkin ada alamat
email yang sama untuk dua orang yang berbeda, sehingga umumnya username
atau email bisa dijadikan identitas. Khusus untuk username, biasanya
keunikannya hanya relatif terhadap satu website/domain saja. Misal, bila
kita punya username rizki di detik.com, kita boleh juga membuat
username yang sama di facebook.com.
On the Internet, Nobody Knows You‘re a Dog
Di internet, anda bisa menjadi siapa
saja yang anda mau. Mau jadi diri sendiri, silakan. Mau menyamar jadi
orang lain juga boleh. Sangat sulit bagi orang lain untuk bisa
mengetahui siapa anda sebenarnya. Hal ini karena identitas anda di
internet diwakilkan dalam bentuk username dan password. Siapapun yang
mengetahui username dan password anda, akan bisa memakai identitas anda
dan semua orang akan menganggap dia adalah anda.
Identitas digital sangat mudah dibuat,
cukup dengan memasukkan beberapa data pada saat signup/register di suatu
web, maka anda telah membuat identitas baru untuk anda. Karena mudah
dibuat, maka identitas digital kurang bisa dipercaya. Agar identitas
digital memiliki kredibilitas yang kuat, maka perlu didukung dengan
proses verifikasi manual.
Salah satu contoh digital identitas yang
kredibilitasnya kuat adalah SSL certificate. SSL certificate adalah
bentuk bukti identitas suatu server. Dalam sertifikat tersebut tertera
nama domain, nama perusahaan dan deskripsi lainnya. Data-data tersebut
telah melalui proses verifikasi yang ketat oleh Certificate Authority
(CA) sehingga dijamin datanya benar, bukan fiktif.
Contoh lain adalah Paypal. Pengguna
Paypal harus memasukkan nomor kartu kredit yang akan dipakai untuk
bertransaksi. Dalam Paypal account terbagi dalam dua macam, Verified dan
non-Verified. Apa bedanya? Bedanya adalah verified account telah
melalui verifikasi manual untuk memastikan bahwa anda adalah pemilik
kartu kredit yang anda daftarkan tersebut. Caranya adalah dengan
memasukkan sebuah kode dalam tagihan kartu kredit anda. Anda harus
menunggu sampai tagihan kartu kredit anda bulan berikutnya tiba,
kemudian memasukkan kode yang tertera di dalamnya. Bila kode yang anda
masukkan benar, berarti anda telah membuktikan bahwa anda memang benar
pemilik kartu kredit yang anda daftarkan dalam Paypal. Hal ini karena
hanya pemilik kartu kredit yang sah yang bisa membaca lembar tagihan,
kecuali bila anda mencuri surat tagihan kartu kredit milik orang lain.
Hal ini berbeda dengan identitas anda di
jaringan social seperti Facebook. Dalam facebook anda bisa menjadi
siapa saja karena tidak ada verifikasi manual di Facebook. Untuk menjadi
seorang selebritas, anda cukup mendaftar dengan nama dan data umum
selebritas tersebut, kemudian upload foto-fotonya. Dengan begini, kini
anda telah menjadi seorang selebritas di Internet. Tidak akan ada yang
bisa membedakan, apakah anda memang benar-benar selebritas, atau orang
biasa yang menyamar.
Too Many Identity Problem
how to effectively manage multiple identities at many web sites that a user has to interact with
Kemudahan membuat identitas digital
membuat satu orang bisa memiliki banyak identitas. Hal ini menjadi
masalah, karena seseorang harus mengelola banyak identitias untuk web
yang berbeda-beda. Bila identitas sudah terlalu banyak, orang cenderung
untuk melakukan hal yang terlarang, antara lain membuat password yang
terlalu lemah, mencatat password di kertas dan membuat password yang
sama untuk semua web.
Bila seseorang menggunakan password yang
sama untuk semua web, maka bila ada satu saja web yang diikuti korban
berhasil ditembus dengan sql injection atau bug lainnya, maka attacker
itu bisa mengakses semua account milik korban dengan mudah. Ini sangat
berbahaya.
Dari sisi server kita tahu bahwa
tidaklah mudah membuat authentication yang tingkat keamanannya tinggi.
Banyak kasus hacking yang disebabkan karena authentication yang tidak
aman. Salah satu yang cukup sering terjadi adalah sql injection di
halaman login. Selain itu halaman authentication yang aman seharusnya
menggunakan SSL (https), bukan http biasa karena http tidak mengenkrip
paket datanya.
Namun tidak mudah dan murah biayanya
untuk membuat halaman authentication yang aman. Sehingga tidak heran
bila sebagian besar halaman authentication di web tidak menggunakan
https. Bila ada seseorang yang memiliki banyak account dengan password
yang sama. Bila ada salah satu web saja yang tidak secure dan membuat
passwordnya berhasil di sniff, maka semua account lainnya akan terancam
juga.
Jadi baik dari sisi klien maupun dari
sisi server, terlalu banyak identitas menimbulkan masalah. Oleh karena
itu dibutuhkan identitas digital tunggal yang diterima di banyak tempat.
URL as Single Universal Identity
Kita telah melihat bahwa terlalu banyak
identitas membuat masalah yang berbahaya, mempunyai banyak identitas
terkadang diperlukan untuk beragam kondisi. Namun memiliki terlalu
banyak identitas bisa melukai pemiliknya karena username, password dan
data lain milik user bertebaran di banyak tempat menunggu untuk dicuri
cracker.
OpenID adalah protokol terbuka yang
memungkinkan seseorang menggunakan URL sebagai identitas tunggal yang
diterima di banyak tempat. Apa maksudnya, URL kok dijadikan identitas?
URL bisa dibayangkan sebagai petunjuk untuk mencapai lokasi yang mengandung sesuatu yang berharga
Kembali ke URL sebagai identitas.
Bagaimana logikanya? Identitas menunjukkan siapa anda, yang biasanya
diwakilkan dengan identifier/nama. Jadi sebenarnya sederhana saja, URL
bisa dianggap sebagai identifier/nama, jadi bisa juga dipakai sebagai
identitas. Misalkan kalau ada yang bertanya, siapa anda? Saya bisa
menjawab dengan “Saya Rizki”, atau bisa juga menjawab dengan “Saya
rizkiwicaksono.pip.verisignlabs.com”.
URL sebagai identifier sebenarnya lebih
baik dibanding nama orang, karena URL adalah unik, kalau saya sebutkan
saya adalah rizki, tentu banyak orang lain yang punya nama yang sama.
Tapi kalau saya bilang, “saya rizkiwicaksono.pip.verisignlabs.com” tidak
akan ada kembarannya, karena URL menunjukkan satu lokasi yang unik.
Example of URL Authentication
Identitas tentu sangat erat kaitannya
dengan authentication yang fungsinya untuk memastikan siapakah anda.
Bagaimanakah authentication dari identitas yang berupa URL? Anda tentu
ingat bahwa URL adalah petunjuk lokasi.
Bayangkan bila anda menyebutkan
identitas anda bahwa “Saya adalah Jl. Sudirman no. 17″, itu adalah klaim
identitas anda yang harus dibuktikan dengan authentication. Orang lain
akan percaya bahwa anda adalah “Jl Sudirman no. 17″, bila anda bisa
membuktikan bahwa anda adalah pemilik properti di lokasi itu. Salah satu
cara membuktikannya adalah dengan menunjukkan surat/akta kepemilikan.
Mirip dengan contoh itu, dalam URL.
Salah satu bentuk authentication adalah anda harus bisa membuktikan
bahwa anda benar pemilik lokasi yang ditunjukkan oleh URL itu. Bila URL
itu menunjukkan alamat web, maka anda harus bisa memasukkan sebuah file,
atau mengubah teksnya menjadi sesuatu yang lain. Bila anda bisa, maka
orang akan yakin anda benar pemilik URL itu.
Bagi yang pernah memakai Google
Analytics tentu tahu, cara untuk membuktikan bahwa anda adalah pemilik
web, adalah dengan membuat sebuah file kosong yang namanya telah
ditentukan google. Kemudian google akan mengakses file tersebut, bila
hasilnya 200 OK, maka anda telah lolos verifikasi google analytics.
Berarti klaim anda benar, bahwa web itu memang benar milik anda.
Oke, yang saya sebutkan di atas hanyalah
contoh sederhana authentication sebuah URL untuk menunjukkan bahwa URL
bisa dipakai sebagai identitas yang sah karena bisa diotentikasi.
Faktanya OpenID jauh lebih kompleks dari sekedar memasukkan sebuah file
seperti verifikasi yang dilakukan oleh google analytics.
Terminologi
Beberapa istilah yang perlu saya jelaskan sebelum saya masuk pembahasan teknis openid adalah:
- End user: pengguna.
- Consumer/Relying Party: website yang mendukung openid, anda bisa login dengan openid di situs ini.
- Identifier: URL openid.
- Identity provider: server yang mengelola account
openid pengguna. Server inilah yang menangani authentication openid
account anda. Jadi sebelum bisa mengakses consumer website anda harus
login dulu di server identity provider.
- User agent: web browser pengguna.
Creating OpenID
Agar lebih
memahami
openID, saya akan menunjukkan pembuatan dan pemakaian OpenID. Dalam
contoh ini saya menggunakan OpenID provider milik Verisign yaitu
Personal Identity Portal. Untuk mendaftar klik ke PIP Portal Verisign, di https://pip.verisignlabs.com. Kemudian klik tombol Get Started Now.
sign up button
Setelah itu masukkan username, password dan email anda.Dalam contoh ini saya menggunakan username ilmuhacking.
sign up form
Setelah selesai, anda akan menerima email konfirmasi dan account PIP anda sudah siap digunakan.
openid created
Sangat mudah bukan membuat openID, hanya
perlu 3 langkah saja. OpenID yang baru saya buat adalah
“ilmuhacking.pip.verisignlabs.com”. URL tersebut adalah identifier
identitas saya yang bisa saya pakai untuk login ke web yang mendukung
OpenID. Dalam satu account PIP tersebut saya bisa membuat banyak
identitas OpenID, jadi sesuai dengan namanya Personal Identity Portal,
jadi PIP itu semacam portal/gerbang untuk identitas pribadi saya. Cukup
dengan satu account (username+password) PIP, saya bisa membuat dan
memakai banyak identitas OpenID.
multiple openID
Dengan punya banyak identitas dalam satu
account, saya bisa menggunakannya untuk kondisi yang berbeda. Misalkan
di situs yang terkait dengan hacking, saya pakai
“ilmuhacking.pip.verisignlabs.com”, namun bila di situs yang sifatnya
umum, saya pakai “masrizki.pip.verisignlabs.com”.
Using OpenID in LiveJournal
livejournal openID
Sebagai contoh pemakaian OpenID, saya menggunakan contoh
LiveJournal,
yang dalam hal ini bertindak sebagai consumer website. Sebelumnya saya
akan logout dulu dari PIP. Untuk Login di Livejournal dengan OpenID,
klik link “
Login w/ OpenID“.
Dalam contoh ini saya menggunakan “ilmuhacking.pip.verisignlabs.com”
sebagai identitas saya. Setelah saya klik tombol Login, maka LiveJournal
akan redirect ke PIP Verisignlabs.
Berhubung saya sudah mengaktifkan
setting “Sign in Security”, maka yang muncul bukan halaman login PIP,
tapi peringatan bahwa saya harus login dulu ke PIP dengan cara
mengetikkan URL: http://pip.verisignlabs.com/login.do. Bila settings
“Sign in Security” tidak diaktifkan, maka saya akan langsung diarahkan
ke halaman login PIP.
Setelah saya login ke PIP, kemudian saya
harus mengulang lagi memasukkan OpenID URL saya di LiveJournal. Kali
ini karena saya sudah login (session PIP masih hidup di browser saya),
saya tidak perlu login ke PIP dulu dan saya langsung masuk ke halaman
verifikasi berikut:
verifikasi
Di situ saya diminta untuk
memverifikasi, apakah benar ilmuhacking adalah OpenID saya. Saya juga
diminta menentukan hubungan trust dengan situs LiveJournal, bila saya
tetapkan Never Expire maka berikutnya saya tidak diminta verifikasi
situs LiveJournal.com seperti ini. Namun bila saya setting Expire After
Sign In, maka saya hanya mengijinkan untuk login kali ini saja, login
berikutnya saya akan ditanyakan verifikasi lagi.
welcome back to livejournal
Setelah verifikasi, saya masuk ke
halaman pribadi LiveJournal.com karena saya sudah berhasil login dengan
OpenID. Saya tidak pernah mendaftar di situs ini, tapi saya mendaftar di
PIP sekali saja, dan saya bisa langsung memakai LiveJournal dan banyak
situs lainnya, menyenangkan bukan?
Using OpenID in CommonGate
commongate openid login
Pada contoh sebelumnya saya sudah
menunjukkan pemakaian OpenID di situs LiveJournal. Biar lebih mantap,
saya akan coba lagi untuk consumer website yang lain, yaitu
CommonGate.com. Kali ini saya menggunakan identitas
“masrizki.pip.verisignlabs.com”, ingat di awal saya sudah ceritakan
bahwa identitas masrizki.pip.verisignlabs.com dan
ilmuhacking.pip.verisignlabs.com adalah dua OpenID dalam satu account
PIP yang sama, yaitu username ilmuhacking.
Dalam keadaan session PIP saya masih
hidup (belum logout) dengan account ilmuhacking, saya masukkan URL
OpenID saya di commongate.com seperti pada gambar di atas. Sekali lagi,
karena session PIP saya masih hidup, maka saya langsung diarahkan pada
halaman verifikasi, karena ini adalah situs baru yang belum pernah saya
percayai.
confirmation commongate
Berbeda dengan LiveJournal yang hanya
meminta expiration date saja, kali ini commongate meminta beberapa data
seperti tanggal lahir, negara, bahasa. Data tersebut adalah data yang
sudah saya masukkan sebelumnya ketika saya membuat OpenID di PIP. Jadi
sekarang saya tidak perlu repot-repot mengisinya lagi, saya tinggal
tentukan tanggal expired hubungan trus commongate.com dengan PIP saya.
Untuk mudahnya saya pilih Never Expire.
commongate profile page
Setelah melalui verifikasi, saya langsung diarahkan ke halaman home
saya di commongate seperti pada gambar di atas. Karena saya memilih
Never Expire, jadi berikutnya dengan session PIP yang masih aktif,
ketika saya login di commongate dengan OpenID, saya akan langsung masuk
ke halaman profile saya di commongate. Perhatikan pada gambar tersebut,
username, country dan gender sudah terisi dengan benar karen field
tersebut diambil dari data saya di PIP tanpa perlu saya memasukkan
secara manual. Field location masih salah karena memang tidak ada field
location di PIP.
Using Different URL
Sebelumnya saya selalu menggunakan
“masrizki.pip.verisignlabs.com” dan “ilmuhacking.pip.verisignlabs.com”
sebagai identifier OpenID saya. Karena saya membuat OpenID di PIP
Verisignlabs (Verisignlabs adalah Identity Provider), maka URL saya
defaultnya adalah menggunakan URL yang diberikan oleh PIP.
Sebenarnya URL openID tidak harus sama
dengan URL identity provider. Fungsi dari URL OpenID adalah sebagai
tempat untuk meng-host html dokumen yang mengandung petunjuk di mana
alamat Identity Provider yang dipakai. Mari kita lihat source html dari
URL
http://masrizki.pip.verisignlabs.com/ :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />
<meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" />
<title>Identity Endpoint For masrizki</title>
</head>
<body>
<p>This is an identity endpoint for masrizki</p>
<p>For more information, please visit <a href="http://pip.verisignlabs.com">http://pip.verisignlabs.com</a></p>
</body>
</html>
|
Informasi yang penting hanyalah pada
baris ke-5,6 dan 7. Pada baris ke-5 dan 6 terlihat bahwa openid server
yang dipakai adalah http://pip.verisignlabs.com/server. Sedangkan pada
baris-7 menunjukkan lokasi file XRDS (eXtensible Resource Descriptor
Sequence) yang merupakan file XML yang mendeskripsikan openID saya.
Isi dari file XRDS tersebut adalah berikut ini:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| <?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://openid.net/sreg/1.0</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type>
<Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor</Type>
<Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</Type>
<URI>http://pip.verisignlabs.com/server</URI>
<LocalID>http://masrizki.pip.verisignlabs.com/</LocalID>
</Service>
<Service priority="1">
<Type>http://openid.net/signon/1.1</Type>
<Type>http://openid.net/sreg/1.0</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<URI>http://pip.verisignlabs.com/server</URI>
<openid:Delegate>http://masrizki.pip.verisignlabs.com/</openid:Delegate>
</Service>
</XRD>
</xrds:XRDS>
|
Sebagai contoh saya akan membuat URL : masrizki.ilmuhacking.com sebagai
identifier OpenID saya. Saya harus membuat index.html di url itu berisi:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.local_id" href="http://masrizki.pip.verisignlabs.com" />
<meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" />
<title>OpenID MasRizki</title>
</head>
<body>
<h1>OpenID MasRizki</h1>
</body>
</html>
|
masrizki.ilmuhacking.com
Kalau dibuka di browser URL tersebut akan tampak
seperti gambar disamping. Setelah file htmlnya dibuat, kini saya siap
menggunakan masrizki.ilmuhacking.com sebagai identifier saya, bukan lagi
memakai masrizki.pip.verisignlabs.com yang menurut saya terlalu
panjang. Mari kita coba identifier baru tersebut dalam
sniffo.org.
Setelah saya membuka halaman depan sniffo.org dan login, prosesnya terlihat pada gambar di bawah ini.
sniffo.org login using openid
Terlihat pada gambar di atas saya login di sniffo.org
menggunakan OpenID identifier: masrizki.ilmuhacking.com. Karena situs
itu masih baru, belum ada trust, maka PIP meminta saya untuk menentukan
waktu expired trust. Walaupun identifiernya terletak pada host
masrizki.ilmuhacking.com, namun authentication tetap dihandle oleh
VerisignLabs sebagai OpenID Provider. Jadi masrizki.ilmuhacking.com
hanya sebagai nama (identifier) saja, semua proses authentication
selanjutnya dihandle oleh PIP Verisignlabs. Proses ini disebut dengan
authentication delegation karena host ilmuhacking.com mendelegasikan
otentikasi ke PIP Verisignlabs. Instruksi delegate ini bisa diketahui
dari dokumen html yang diambil dari url masrizki.ilmuhacking.com pada
baris ke-7 yaitu:
<link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" />
Baris di atas menunjukkan bahwa
masrizki.ilmuhacking.com mendelegasikan otentikasi kepada
masrizki.pip.verisignlabs.com. Sehingga selanjutnya proses otentikasi
diarahkan ke Verisignlabs. Dengan begini saya bisa membuat identifier
apapun yang saya mau, tanpa perlu repot menjadi OpenID Provider. URL
untuk identifier OpenID benar-benar bebas, anda bisa membuat identifier
misalkan: www.foobar.or.id/namaku/, yang terpenting pada URL tersebut
terdapat file html yang menunjukkan delegasi OpenID provider yang
dipakai.
Centralized vs Distributed Session Management
SSO (single sign on) adalah teknologi yang memungkinkan pengguna hanya
perlu login sekali saja untuk bisa menikmati banyak layanan. Cara
pengelolaan session dalam SSO ada dua macam:
- Centralized: hanya ada satu session saja untuk mengakses semua layanan. Contohnya adalah layanan google dan yahoo.
- Distributed: setiap website memiliki session
masing-masing yang saling independent. Openid adalah salah satu contoh
SSO yang memakai distributed session.
4 independent session: distributed session
OpenID provider (dalam artikel ini PIP Verisignlabs), hanya mengurus
soal authentication, dan tidak bertanggung jawab untuk mengurus session
consumer web (livejournal,commongate,sniffo).
Pada gambar di samping terlihat ada 4 session yang
terpisah dan satu sama lain saling independent. Bila anda sudah login ke
PIP, pada browser anda nanti akan ada session cookie khusus untuk
OpenID Provider. Selama session ini masih hidup anda tidak perlu lagi
memasukkan password setiap kali memakai openid.
Session untuk masing-masing consumer website dikelola
secara mandiri dan tidak ada hubungannya dengan session OpenID
provider. Jadi bila anda sudah login ke PIP, kemudian dengan OpenID
login ke LiveJournal, CommonGate dan Sniffo, berarti pada browser anda
akan ada 4 session cookie yang berbeda, satu untuk openid provider, dan 3
untuk consumer website (livejournal,commongate,sniffo).
Logout dari openid provider, tidak akan membuat anda logout dari consumer website
Bila anda logout dari salah satu consumer website,
maka anda tetap bisa memakai layanan di consumer website yang lain.
Logout dari satu consumer website hanya mematikan session consumer web
itu saja, tidak berpengaruh sama sekali pada session di web lainnya.
single session google network: centralized session
Salah satu contoh implementasi SSO yang terpusat adalah layanan dari
yahoo dan google seperti terlihat pada gambar di samping. Pada
yahoo/google user cukup sign-on sekali saja, kemudian dia bisa membaca
email, chatting dan menggunakan layanan lain tanpa perlu ditanyakan
password lagi. Begitu pula sebaliknya, bila user logout dari salah satu
layanan, maka user tersebut akan logout dari seluruh network, sehingga
tidak bisa mengakses layanan yang lain.
Di Balik Layar
Setelah mencoba berbagai situs yang mendukung OpenID dengan identifier
yang dari PIP dan identifier yang dibuat sendiri. Kini tiba saatnya saya
untuk menjelaskan apa yang sebenarnya terjadi di balik layar.
Indirect vs Direct Communication between Consumer and Provider
Dalam openid ada 3 entitas yang terlibat, yaitu User Agent (browser yang
dipakai user), consumer website (relying party), dan openid provider.
Komunikasi yang terjadi di antara ketiganya bisa dilakukan secara
langsung atau tidak langsung, semuanya menggunakan protokol HTTP. Pada
gambar di samping terlihat gambaran komunikasi secara langsung dan tidak
langsung. Komunikasi secara langsung menggunakan HTTP POST, sedangkan
komunikasi tidak langsung menggunakan HTTP GET melalui browser Redirect.
Pada komunikasi tida langsung, request dikirimkan dalam bentuk http
response 302 (redirect), kemudian browser user akan melakukan GET
request pada url yang tertera pada header Location. Begitu pula
sebaliknya, response juga akan dikirimkan melalui user dengan
mengirimkan 302 redirect terlebih dahulu.
Komunikasi yang terjadi di openid ada dua mode:
- Dumb Mode
Pada mode “bodoh” ini, consumer tidak memiliki ingatan, sehingga tidak
menyimpan state koneksi antara consumer dan provider. Dalam mode ini
percakapan berlangsung lebih banyak karena banyak percakapan yang harus
diulang lagi karena “lupa terus”.
- Smart Mode
Pada mode smart, consumer mengingat state koneksi antara consumer dan
provider. Hal yang diingat terutama adalah shared secret key, yang
dipakai untuk menjaga integritas pesan dengan fungsi HMAC. Dengan
mengingat shared key ini, consumer tidak perlu lagi melakukan verifikasi
setelah user di-redirect ke consumer website dari openid provider
(untuk lebih jelasnya lihat langkah 1-7 di bawah ini).
Alur authentication openid diperlihatkan pada gambar di bawah ini.
Gambar tersebut diambil dari white paper Eugene Tsyrklevich dan Vlad
Tsyrklevich pada acara BlackHat USA 2007. Pada gambar di bawah ini
komunikasi tidak langsung terjadi pada langkah nomor 4 dan 7, yaitu
redirect. Sedangkan komunikasi langsung terjadi pada langkah nomor 3,
yaitu negotiate crypto keys.
openid authentication flow
Gambar tersebut memperlihatkan alur ketika user login ke consumer
website atau relying party. Penjelasan dari skenario pemakaian OpenID
tersebut:
- Login with openid URL
User membuka halaman consumer website (misal
livejournal.com) dan login dengan memasukkan identifier openidnya,
misal: masrizki.ilmuhacking.com
- Download openid URL
Livejournal mengakses url http://masrizki.ilmuhacking.com dan menerima file html.
- Negotiate crypto keys
Dari html yang didapat di url
masrizki.ilmuhacking.com, livejournal menemukan delegation server di
http://masrizki.pip.versignlabs.com. Di balik layar, livejournal
berkomunikasi secara langsung dengan server openid provider
pip.verisignlabs.com dengan protokol HTTP untuk menegosiasikan kunci
kriptografi yang akan dipakai bersama. Kunci ini dipakai untuk menjaga
integritas pesan antara consumer dan provider.
Openid memakai
HMAC (Hash
Message Authentication Code) untuk menjaga integritas pesan, oleh
karena itu kedua pihak harus mengetahui kunci rahasia yang sama.
Pertukaran kunci rahasia menggunakan protokol
Diffie Helman.
- Redirect
Karena user belum login ke pip verisign, maka livejournal mengirimkan perintah redirect ke halaman login pip verisignlabs.
- Enter password
User memasukkan password di halaman login pip.
- Authorize RP
Bila authentication berhasil (password benar), maka pip verisignlabs,
akan meminta user untuk meng-otorisasi relying parter (livejournal.com).
Bila user men-set Allow untuk selamanya (Never Expire), maka berikutnya
tidak akan dimintai konfirmasi seperti ini.
- Redirect
Provider berkomunikasi dengan consumer secara tidak
langsung melalui browser user dengan mengirimkan perintah Redirect.
Informasi yang dikirimkan dari provider ke consumer adalah status
authentication, apakah sukses atau gagal. Bila authentication sukses,
maka consumer web akan mengijinkan user mengakses consumer website dan
mensetup session antara user dan consumer.
Langkah ke-7 adalah langkah terakhir bila menggunakan mode smart. Namun
bila memakai mode dumb, ada satu langkah tambahan yaitu verifikasi.
Verifikasi ini berguna untuk memastikan bahwa user yang bersangkutan
benar-benar telah ter-otentikasi (autenticated) di provider, sehingga
mencegah attacker yang ingin menipu consumer dengan request palsu.
Consumer akan mengirimkan request HTTP POST ke
provider dengan membawa semua parameter yang diterima dari hasil
redirect browser (langkah ke-7). Kemudian provider akan menjawab request
tersebut dengan status valid atatu tidak valid.
Kesimpulan
OpenID menjanjikan solusi untuk mengelola identitas digital lebih baik
dan lebih mudah. Dalam artikel ini saya hanya menjelaskan basic concept
dan sekilas komunikasi openid. Penjelasan teknis dan detil komunikasi
yang terjadi tidak saya expose di sini, saya akan expose dalam artikel
berikutnya sekaligus membahas tentang keamanan openid.