Mengenal OpenID

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&nbsp;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:

1. Login with openid URL
User membuka halaman consumer website (misal livejournal.com) dan login dengan memasukkan identifier openidnya, misal: masrizki.ilmuhacking.com
2. Download openid URL
Livejournal mengakses url http://masrizki.ilmuhacking.com dan menerima file html.
3. 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.
4. Redirect
Karena user belum login ke pip verisign, maka livejournal mengirimkan perintah redirect ke halaman login pip verisignlabs.
5. Enter password
User memasukkan password di halaman login pip.
6. 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.
7. 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.