Klaim OpenID Connect dan Token ID

OpenID Connect (OIDC) menambahkan lapisan identitas di atas OAuth 2.0. Meskipun OAuth 2.0 menangani otorisasi (apa yang dapat diakses aplikasi ini?), OIDC menjawab pertanyaan identitas (siapa penggunanya?). OIDC diimplementasikan dengan menambahkan ruang lingkup "openid" ke permintaan OAuth 2.0, yang menyebabkan server otorisasi mengembalikan token ID bersama token akses.

Token ID OIDC adalah JSON Web Token (JWT) yang berisi klaim tentang pengguna yang telah diautentikasi. JWT ditandatangani oleh server otorisasi menggunakan kunci privatnya (biasanya RS256 atau ES256), lalu pihak pengandalan (aplikasi klien) memverifikasi tanda tangan tersebut menggunakan kunci publik server otorisasi yang dipublikasikan (titik akhir JWKS).

Klaim token ID yang diwajibkan dan umum digunakan: "sub" (subjek, pengenal pengguna unik), "iss" (penerbit, URL server otorisasi), "aud" (audiens, ID klien), "exp" (stempel waktu Unix kedaluwarsa), "iat" (stempel waktu Unix saat diterbitkan). Opsional: "auth_time" (waktu autentikasi terjadi), "nonce" (pencegahan pemutaran ulang), "at_hash" (hash token akses), "acr" (kelas konteks autentikasi), "amr" (metode autentikasi yang digunakan).

Titik akhir OIDC UserInfo mengembalikan klaim tambahan tentang pengguna yang telah diautentikasi ketika dipanggil dengan token akses yang valid. Klien meminta kumpulan klaim tertentu melalui ruang lingkup: "profile" (nama, foto, lokalitas), "email" (email, email_verified), "address" (alamat terformat), "phone" (phone_number, phone_number_verified). Respons UserInfo berupa objek JSON atau JWT.

Validasi token ID dimulai dengan verifikasi tanda tangan. Klien mengambil JWKS (JSON Web Key Set) milik server otorisasi dari titik akhir standar, menemukan kunci yang cocok dengan parameter "kid" (ID kunci) pada header JWT, lalu memverifikasi tanda tangan JWT. Ini membuktikan bahwa token diterbitkan oleh server otorisasi yang sah dan tidak diubah.

Setelah verifikasi tanda tangan, klien harus memvalidasi hal-hal berikut: "iss" harus sama persis dengan URL server otorisasi yang diharapkan (termasuk skema dan jalur). "aud" harus memuat client_id milik klien tersebut. "exp" harus berada di masa depan (tolak token yang sudah kedaluwarsa). "iat" seharusnya masih cukup baru. Keempat pemeriksaan ini diwajibkan oleh spesifikasi OIDC.

Klaim nonce mencegah serangan pemutaran ulang token ID. Klien membuat nonce acak dan menyertakannya dalam permintaan otorisasi. Server otorisasi menyisipkan nonce tersebut ke dalam token ID. Klien memverifikasi bahwa nonce dalam token ID sama dengan yang dikirimkannya. Ini mencegah penyerang yang menangkap token ID memutarnya kembali untuk melakukan autentikasi pada sesi yang berbeda.

Ketika OIDC menggunakan alur implisit (response_type=id_token), token ID dikembalikan langsung dalam fragmen URL. Klien harus memvalidasi at_hash (hash token akses) untuk mengikat token akses ke token ID. Tanpa validasi at_hash, serangan substitusi token akses dapat terjadi. Ini merupakan alasan lain mengapa alur implisit tidak lagi direkomendasikan.

OIDC mendefinisikan pemetaan standar ruang lingkup ke klaim. Ruang lingkup "openid" wajib digunakan dan mengembalikan klaim "sub". Ruang lingkup "profile" mengembalikan name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. Ruang lingkup "email" mengembalikan email dan email_verified. Meminta ruang lingkup yang tidak diperlukan melanggar prinsip pengungkapan minimal dan dapat mengekspos data pengguna yang sensitif.

Ketika mengimplementasikan login OIDC dengan banyak penyedia (misalnya, "Masuk dengan Google" dan "Masuk dengan GitHub"), serangan penyisipan klaim mungkin terjadi. Jika penyerang membuat akun di Penyedia B dengan alamat email korban yang menggunakan Penyedia A, penyerang mungkin mendapat akses jika aplikasi mencocokkan akun hanya berdasarkan klaim email. Selalu cocokkan akun berdasarkan pasangan (iss, sub), bukan email saja.

Alur hibrida OIDC (response_type=code id_token) mengembalikan kode otorisasi dan token ID dari titik akhir otorisasi. Token ID memungkinkan verifikasi identitas segera, sementara kode ditukarkan dengan token melalui kanal belakang. Alur ini digunakan ketika klien perlu segera menampilkan informasi pengguna sebelum menyelesaikan pertukaran token melalui kanal belakang.

Kombinasi klaim apa yang harus divalidasi oleh pihak pengandalan dalam token ID OIDC?

OIDC menambahkan token ID JWT yang ditandatangani ke alur OAuth 2.0. Validasi tanda tangan (JWKS), iss (pencocokan tepat), aud (client_id), exp (belum kedaluwarsa), dan nonce (jika dikirimkan). Titik akhir UserInfo menyediakan klaim tambahan melalui ruang lingkup. Cocokkan akun berdasarkan pasangan (iss, sub), jangan pernah berdasarkan email saja, untuk mencegah penyisipan klaim. Alur implisit tidak lagi direkomendasikan; gunakan kode otorisasi dengan PKCE untuk OIDC.