Menyederhanakan login lintas-domain

Eiji Kitamura

Arsitektur bisnis modern sering kali mencakup beberapa domain yang berbeda. Organisasi mempertahankan lingkungan khusus untuk berbagai fitur—seperti brand.example untuk pemasaran, service-app.example untuk produk inti, dan support-portal.example untuk layanan pelanggan. Idealnya, Anda ingin memberikan pengalaman login tunggal yang terpadu saat pengguna menjelajahi properti ini. Namun, tim teknik sering kali mengintegrasikan domain ini menggunakan teknik ad hoc yang menyebabkan fragmentasi. Hal ini mengganggu pengelolaan kredensial browser bawaan dengan merusak alur isi otomatis pengelola sandi dan menghentikan adopsi kunci sandi.

Jika akun yang sama mencakup beberapa domain, pengguna harus mengenali bahwa domain tersebut milik organisasi yang sama dan memberikan kredensial yang sama saat login. Dalam kasus terburuk, pengguna membuat akun duplikat atau memberikan sandi ke situs phishing.

Pelajari cara menggunakan standar dan solusi arsitektur (seperti metadata, iframe lintas origin, gabungan identitas, dan konsolidasi subdomain) untuk mengatasi fragmentasi identitas lintas domain dan memberikan perjalanan pengguna yang lancar.

Solusi umum

Organisasi menggunakan beberapa teknik yang sudah mapan untuk mempertahankan perjalanan lintas domain. Meskipun metode ini umum, metode ini menghadapi hambatan struktural karena browser menerapkan batas privasi dan standar keamanan yang lebih ketat.

Permintaan pengambilan CORS

Saat domain beroperasi secara independen, frontend sering kali mengandalkan permintaan lintas origin fetch() yang diarahkan ke API autentikasi terpusat, yang dapat diizinkan dengan aman menggunakan Cross-Origin Resource Sharing (CORS). Karena browser sering kali memblokir atau membatasi cookie lintas situs, developer dapat secara eksplisit mendesain API ini untuk menampilkan token autentikasi, seperti JSON Web Tokens (JWT) dalam payload JSON, bukan mengandalkan header Set-Cookie.

Berbagi database akun

Untuk menyatukan identitas di backend tanpa integrasi frontend yang kompleks, Anda dapat memusatkan datastore pengguna. Meskipun beberapa domain melakukan autentikasi terhadap database yang sama, pengalaman login frontend mereka tetap terpisah. Hal ini memaksa pengguna untuk mengingat domain mana yang menggunakan kredensial yang sama, sehingga menyebabkan pengalaman pengguna yang buruk.

Masalah dengan login yang terpisah

Meskipun solusi teknis dapat mencapai fungsi dasar, solusi ini gagal memberikan perjalanan yang lancar. Alur login yang terpisah menimbulkan titik gesekan yang membahayakan kegunaan dan keamanan.

Fragmentasi pengelola sandi

Titik gesekan tertinggi adalah gangguan pengelola sandi. Pengelola sandi mengikat kredensial yang disimpan ke origin tertentu tempat kredensial tersebut didaftarkan. Hal ini mencegah browser menawarkan isi otomatis di berbagai domain, meskipun domain tersebut milik organisasi yang sama.

Saat pengguna beralih dari domain dengan kredensial tersimpan ke domain baru di organisasi Anda, pengelola sandi gagal mengenali hubungan tersebut dan tidak memicu perintah isi otomatis. Hal ini menyebabkan gesekan entri manual. Pengguna harus mencari kredensial mereka, menyetel ulang sandi, atau membuat akun duplikat.

Karena pengelola sandi terbukti tidak dapat diandalkan di seluruh properti ini, pengguna dapat meninggalkan alat untuk situs ini. Sebagai gantinya, mereka sering membuat sandi yang lemah dan mudah diingat untuk digunakan kembali di tempat lain, yang menurunkan keamanan keseluruhan organisasi Anda.

Gateway phishing

Gangguan ini berfungsi sebagai gateway phishing. Penolakan pengelola sandi untuk mengisi otomatis di domain yang tidak dikenal adalah mekanisme pertahanan utama. Dengan mewajibkan pengguna memasukkan kredensial secara manual di URL yang berbeda, Anda secara tidak sengaja melatih pengguna untuk menjadi korban serangan phishing.

Iklan roadblock kunci sandi

Gesekan meningkat saat Anda menggunakan kunci sandi. Arsitektur keamanan inti WebAuthn mengikat kunci sandi secara kriptografis dengan ketat ke ID Pihak Tepercaya (RP ID) yang ditentukan.

Hal ini membuat "RP ID Trap". Kunci sandi yang terdaftar di brand.example tidak dapat digunakan di service-app.example karena browser menolak akses lintas domain. Untuk menghindari meminta pengguna mendaftarkan kunci sandi yang berbeda untuk setiap situs, Anda harus mengonsolidasikan properti ini ke dalam satu RP ID.

Pendekatan yang direkomendasikan

Untuk menetapkan kontinuitas identitas, Anda harus beralih dari integrasi login ad hoc dan mengadopsi standar arsitektur yang diakui:

• Menggunakan file konfigurasi metadata: Hosting file metadata seperti Digital Asset Links dan Related Origin Requests, untuk membuat rantai kepercayaan kriptografis. Hal ini memungkinkan berbagi kredensial dan kunci sandi yang lancar di berbagai domain dan aplikasi seluler. Pendekatan ini adalah perbaikan senyap dan berbiaya rendah untuk fragmentasi identitas yang tidak memerlukan arsitektur ulang yang kompleks dari infrastruktur web yang ada.
• Menggunakan iframe lintas origin: Sematkan origin autentikasi terpusat sebagai iframe dalam pihak tepercaya untuk menjembatani kredensial dan kunci sandi yang disimpan di berbagai situs. Pendekatan ini menggunakan Kebijakan Izin dan cookie yang dipartisi untuk memungkinkan pengalaman login dalam konteks yang lancar sekaligus mempertahankan batas keamanan yang ketat melalui CSP dan pesan lintas dokumen.
• Mengikuti gabungan identitas standar: Mengadopsi protokol standar industri seperti OpenID Connect untuk memusatkan autentikasi di domain Penyedia Identitas (IdP) khusus. Hal ini memformalkan perjalanan login melalui pengalihan yang aman, menggantikan integrasi yang rapuh dengan solusi pihak pertama yang andal dan skalabel.
• Mengonsolidasikan subdomain: Beralih ke subdomain di bawah root umum. Hal ini memungkinkan berbagi sesi yang lancar melalui cookie karakter pengganti dan kontinuitas kunci sandi di seluruh domain yang dapat didaftarkan. Banyak pengelola sandi dapat mengenali domain root bersama dan otomatis menyarankan kredensial yang disimpan di seluruh subdomain terkait.

Menggunakan file konfigurasi metadata

Tantangan utama identitas lintas domain adalah fragmentasi kredensial yang disimpan. Pengelola sandi memperlakukan domain dan aplikasi yang berbeda sebagai entitas yang sepenuhnya terisolasi, yang mencegahnya mengisi otomatis kredensial yang disimpan di satu properti ke properti lain.

Untuk mengatasi fragmentasi, Anda dapat mengonfigurasi perilaku pengelola sandi, bukan mengubah struktur situs. Dengan menghosting file konfigurasi metadata tertentu, organisasi dapat secara kriptografis menegaskan bahwa domain dan aplikasi yang berbeda milik organisasi yang sama. Hal ini memungkinkan sistem operasi, browser, dan pengelola sandi mengenali hubungan ini dan secara otomatis menjembatani konteks identitas, berbagi sandi dan kunci sandi di seluruh properti Anda. Pendekatan ini juga diperlukan untuk berbagi sandi dan kunci sandi berbasis web dengan aplikasi seluler, meskipun domain web Anda dikonsolidasikan.

Gunakan dua file konfigurasi yang berbeda untuk memastikan Anda mencakup platform dan ekosistem yang berbeda:

• Pengelola Sandi Google di Android dan Chrome: Hosting file JSON Digital Asset Links (DAL) di /.well-known/assetlinks.json untuk membuat hubungan kepercayaan yang dapat diverifikasi antara aplikasi dan situs terkait organisasi. Kepercayaan ini memungkinkan deep link di aplikasi dan Berbagi Kredensial yang Lancar, tempat sandi yang disimpan di web otomatis mengisi otomatis situs terkait (meskipun berbagi kunci sandi di beberapa domain web masih memerlukan Related Origin Requests). Pelajari lebih lanjut di panduan Berbagi kredensial yang lancar.

• Sandi Apple di iOS dan Safari: Hosting file Apple App Site Association (AASA) di /.well-known/apple-app-site-association untuk membuat rantai kepercayaan kriptografis yang diperlukan untuk menjembatani status Sandi Apple di seluruh aplikasi iOS dan Safari. Untuk mendukung ekosistem pihak ketiga, Anda dapat mendeklarasikan domain terkait ini secara terpusat menggunakan repositori crowdsourcing. Dengan melakukannya, alat independen (seperti 1Password, yang secara eksplisit menggunakan repositori ini) juga akan mengenali konteks identitas bersama. Untuk mempelajari Asosiasi Situs Aplikasi Apple lebih lanjut, baca Mendukung domain terkait.

Untuk mengaktifkan kunci sandi di berbagai domain web dan mengatasi iklan kunci sandi roadblock, developer dapat menghosting file Related Origin Requests (ROR) di /.well-known/webauthn. ROR secara eksplisit mendeklarasikan domain resmi yang diizinkan untuk berbagi RP ID kunci sandi yang sama secara aman. Untuk mempelajari lebih lanjut tentang Related Origin Requests, baca Mengizinkan penggunaan kembali kunci sandi di seluruh situs Anda dengan Related Origin Requests.

• Keunggulan:
  • Perbaikan latar belakang untuk pengguna akhir: Perbaikan ini berfungsi sepenuhnya di latar belakang, yang secara otomatis mengatasi fragmentasi isi otomatis dan menetapkan kontinuitas kunci sandi di tingkat OS atau browser tanpa perubahan yang terlihat pada UX.
  • Implementasi sederhana: Ini adalah solusi berbiaya rendah, yang hanya memerlukan hosting file JSON statis. Solusi ini tidak memerlukan arsitektur ulang backend atau logika pertukaran token yang kompleks.
  • Mempertahankan infrastruktur yang ada: Anda dapat meningkatkan perjalanan lintas domain secara signifikan tanpa mengubah merek atau mengonsolidasikan domain.
• Kekurangan:
  • Batasan platform: Platform biasanya menerapkan batasan ketat pada ROR. Misalnya, Chrome membatasi satu RP ID hingga maksimum 5 label eTLD+1 terkait. Sebagai ilustrasi, example.co.uk dan example.de berbagi label eTLD+1 example yang sama; namun, example-rewards.com menggunakan label example-rewards yang terpisah. Jika Anda mengelola portofolio domain yang luas atau beragam, batas ini mungkin tidak mencukupi.
  • Peningkatan latensi operasional: Menyelesaikan file metadata memerlukan perjalanan pulang pergi jaringan tambahan, yang menambahkan latensi saat browser memproses autentikasi.

Menggunakan iframe lintas origin

Jika Anda tidak dapat menggunakan pendekatan file konfigurasi metadata karena batasan domain ROR, elemen iframe lintas origin menawarkan jalur yang kuat dan didukung standar untuk mengatasi tantangan login lintas domain.

Dengan menyematkan origin autentikasi terpusat (misalnya, auth.brand.example) sebagai iframe dalam pihak tepercaya (misalnya, brand.example), Anda dapat berinteraksi dengan kolom formulir biasa dan modern API. Untuk sandi, pengelola kredensial browser mengaitkan tindakan isi otomatis dengan origin iframe (auth.example). Hal ini memungkinkan pengguna mengakses kredensial terpusat mereka dengan lancar di berbagai situs.

Untuk kunci sandi, jendela induk harus memberikan akses iframe menggunakan framework Kebijakan Izin, yang memungkinkan iframe memanggil WebAuthn untuk melakukan autentikasi terhadap RP ID originnya sendiri. Dalam kedua alur, CSP (Kebijakan Keamanan Konten) berguna untuk melindungi pengguna dari serangan seperti clickjacking dan pembuatan skrip lintas situs. Setelah autentikasi berhasil, sesi akan dibuat dengan cookie yang dipartisi dan token akan dikirim kembali ke jendela induk menggunakan postMessage()dengan aman.

• Keunggulan:
  • Kredensial terpusat: Menghindari fragmentasi kredensial. Satu origin terpusat mengelola sandi yang disimpan dan RP ID kunci sandi terpadu, sehingga memungkinkan domain yang berbeda berbagi kredensial ini tanpa perlu mengonsolidasikan domain.
  • Autentikasi kontekstual: Seluruh alur login—baik mengisi otomatis sandi atau verifikasi dengan kunci sandi—berlangsung dengan lancar dalam konteks di dalam halaman induk, sehingga menghindari pengalihan gabungan yang mengganggu.
  • Ketahanan terhadap perlindungan pelacakan: Pendekatan ini beroperasi dengan benar bahkan di bawah perlindungan pelacakan lintas situs yang ketat menggunakan cookie yang dipartisi.
• Kekurangan:
  • Batasan implementasi: Arsitektur ini memerlukan teknik khusus. Arsitektur ini memerlukan CSP (frame-ancestors) yang ketat untuk membatasi penyematan ke domain induk tepercaya dan mencegah clickjacking, konfigurasi Kebijakan Izin HTTP untuk mengaktifkan WebAuthn API, dan pesan lintas dokumen yang aman dan divalidasi (postMessage()) untuk mengurangi serangan spoofing origin dan CSRF. Pelajari praktik terbaik di Kunci sandi dalam iframe.

Mengikuti gabungan identitas standar

Mengadopsi gabungan identitas standar seperti OpenID Connect adalah pendekatan yang kuat dan berkelanjutan untuk mempertahankan sistem akun Anda. Pendekatan ini memformalkan alur kerja autentikasi dengan mengonsolidasikannya ke satu domain Penyedia Identitas (IdP) khusus, seperti auth.brand.example. Dengan protokol yang ditetapkan, aplikasi mengalihkan pengguna ke hub pusat ini untuk autentikasi sebelum menerima transfer token dengan aman untuk menyelesaikan login di domain target. Meskipun sering dikaitkan dengan login pihak ketiga (seperti Login dengan Google), gabungan standar sepenuhnya valid dan banyak digunakan sebagai solusi pihak pertama untuk menggantikan solusi sementara yang rapuh.

• Keunggulan:
  • Bahasa teknik umum: Developer tidak perlu mempelajari atau mempertahankan protokol khusus yang dibuat khusus; mereka dapat mengandalkan pengetahuan industri yang mapan dan library yang komprehensif. Ada juga solusi paket.
  • Keandalan yang teruji: Protokol standar terbukti aman dan jauh lebih tidak rapuh daripada implementasi ad hoc.
  • Dapat diperluas dengan mudah: Jika organisasi perlu bergabung dengan layanan pihak ketiga baru atau mengintegrasikan akuisisi nanti, infrastruktur identitas sudah dilengkapi untuk memberikan kredensial.
  • UX yang konsisten: Pengguna mengenali halaman IdP terpusat sebagai sumber resmi untuk merek, yang menjelaskan dengan tepat kapan dan di mana kredensial diperlukan.
• Kekurangan:
  • Overhead integrasi yang tinggi: Mengembangkan atau bermigrasi ke IdP terpusat akan menimbulkan overhead integrasi yang tinggi dan memerlukan keahlian keamanan khusus. Organisasi harus berinvestasi untuk memfaktorkan ulang semua aplikasi yang terhubung dengan aman untuk mendukung pola berbasis pengalihan yang aman.
  • Pengalihan yang mengganggu: Alur autentikasi mengharuskan pengalihan pengguna dari situs origin ke halaman Penyedia Identitas terpusat, sehingga mencegah pengalaman login dalam konteks yang lancar.

Mengonsolidasikan subdomain

Pendekatan struktural lainnya adalah menyatukan semua domain dengan memindahkan properti digital yang berbeda di bawah domain root umum yang dapat didaftarkan (eTLD+1). Hal ini memerlukan transisi domain terpisah seperti brand.example dan service-app.example ke subdomain seperti www.brand.example dan service.brand.example.

• Keunggulan:
  • Pengelolaan kredensial terpadu: Pengelola sandi dapat mengenali domain root dan memperlakukan semua subdomain sebagai satu entri, sehingga menghilangkan perintah duplikat dan entri manual untuk sandi.
  • Kontinuitas kunci sandi: Developer dapat secara native mencakup RP ID kunci sandi ke domain yang dapat didaftarkan, sehingga langsung memperluas dukungan kunci sandi di semua subdomain terkait. Dalam hal ini, RP ID brand.example akan berfungsi di www.brand.example dan service.brand.example.
  • Berbagi sesi yang mudah: Mengonsolidasikan struktur domain memungkinkan berbagi satu sesi menggunakan cookie karakter pengganti (misalnya, mencakup cookie ke Domain=brand.example).
• Kekurangan:
  • Batasan branding dan migrasi: Pendekatan ini dapat menimbulkan potensi batasan branding jika organisasi Anda mewajibkan domain tingkat atas yang berbeda. Migrasinya kompleks dan memerlukan pengelolaan pengalihan HTTP yang cermat serta perbaikan konfigurasi lintas origin lama yang ekstensif.

Kesimpulan

Untuk mencapai kontinuitas identitas, Anda harus beralih dari integrasi login ad hoc ke standar autentikasi yang ditetapkan. Dengan mengevaluasi batasan bisnis terhadap praktik yang ditetapkan ini—seperti gabungan, konsolidasi domain, iframe, atau metadata—Anda dapat menghilangkan gesekan UX dan meningkatkan autentikasi di seluruh ekosistem Anda.

Untuk mempelajari topik terkait lebih lanjut, pastikan untuk mengikuti blog kami dan menjelajahi lebih banyak resource di portal identitas Chrome.