Penulis XDA baru-baru ini menjalankan empat hal yang mereka lakukan untuk mengamankan server Plex sebelum mengeksposnya ke internet: menerapkan TLS, berhenti mengiklankan port 32400 langsung melalui router, menempatkan hal itu di balik proxy terbalik, dan mengaktifkan two-factor untuk akun. Semuanya masuk akal. Semuanya tidak lengkap. Proxy terbalik menghentikan TLS dan merutekan nama host, dan kemudian menyerahkan permintaan ke aplikasi, yang dibiarkan memutuskan sendiri apakah orang di ujung lain harus berada di sana. Setiap layanan berakhir dengan halaman login sendiri, aturan sandi sendiri, dan idenya sendiri tentang apa arti “logout”.
Itulah yang diisi aplikasi SSO terbaik yang di-host sendiri. Satu penyedia identitas duduk di belakang proxy terbalik, setiap layanan mengarahkan kepadanya, MFA diterapkan sekali untuk semuanya, dan menghapus akses seseorang adalah satu toggle alih-alih tur dari dua belas panel admin. Kami melihat 8 opsi yang dikembangkan secara aktif dan berjalan di lab rumah nyata hari ini, dari penyedia identitas penuh dengan database mereka sendiri hingga kontainer tunggal yang menjawab satu pertanyaan ya-atau-tidak per permintaan.
Apa yang harus diperhatikan dalam aplikasi SSO yang di-host sendiri
- Cakupan protokol. Jika aplikasi Anda secara native berbicara OIDC atau SAML, penyedia identitas adalah jawaban yang bersih. Jika separuh dari mereka tidak berbicara apa pun, Anda membutuhkan forward auth juga, bukan sebagai gantinya.
- Apakah itu memiliki toko pengguna sendiri. Beberapa menyimpan akun, grup, dan hash sandi. Yang lain tidak menyimpan apa pun dan mendelegasikan ke sesuatu di hulu. Keputusan itu mendorong rencana backup Anda.
- MFA yang benar-benar dapat Anda terapkan. TOTP adalah lantai. WebAuthn atau passkey adalah apa yang Anda inginkan untuk apa pun yang dapat dijangkau dari luar rumah.
- Aturan akses berbasis grup. “Semua orang yang dapat masuk dapat mencapai segalanya” bukanlah kontrol akses. Anda menginginkan kebijakan per-aplikasi yang terikat pada keanggotaan kelompok.
- Apa yang dikenakan kepada Anda dalam RAM dan suku cadang bergerak. Stack Postgres plus Redis plus server plus worker oke di NAS dengan 16 GB. Itu tidak baik-baik saja di Raspberry Pi yang sudah menjalankan dua belas kontainer.
- Jalur pemecahan kaca. Ketika penyedia identitas tidak aktif, Anda membutuhkan cara yang terdokumentasi untuk kembali ke infrastruktur Anda sendiri yang tidak bergantung pada penyedia identitas.
Perbandingan cepat
| Aplikasi | Terbaik untuk | Toko pengguna sendiri | Protokol | Forward auth | Lisensi |
|---|---|---|---|---|---|
| Authentik | Penyedia identitas penuh dengan UI web | Ya | OIDC, SAML, LDAP, RADIUS | Ya, proxy outpost | MIT core, paid enterprise tier |
| Authelia | Portal ringan di samping proxy terbalik Anda | Ya, file atau LDAP | OIDC provider, forward auth | Ya, native | Apache 2.0 |
| Tinyauth | Dapatkan login apa pun di depan beberapa aplikasi dengan cepat | Ya, plus OAuth dan LDAP | OIDC, forward auth | Ya, native | AGPL 3.0 |
| LLDAP | Satu direktori bersama yang dapat dibaca yang lain | Ya, LDAP saja | LDAP | Tidak | GPL 3.0 |
| oauth2-proxy | Mengoleskan IdP yang ada ke satu aplikasi | Tidak | OIDC dan OAuth2 client | Ya, via nginx auth_request | MIT |
| Zitadel | Jejak audit dan pengaturan multi-tenant | Ya | OIDC, SAML, SCIM, LDAP | Via OIDC | AGPL 3.0 |
| Keycloak | Cakupan protokol dan federasi terluas | Ya | OIDC, SAML | Via oauth2-proxy | Apache 2.0 |
| Pomerium | Kebijakan yang diputuskan per permintaan, bukan per login | Tidak | OIDC client | Ini adalah proxy | Apache 2.0 |
Mengapa lapisan identitas adalah yang orang lewati
Panduan proxy terbalik ada di mana-mana, dan mereka berakhir pada titik di mana lalu lintas mencapai aplikasi. Panduan firewall berakhir di port. Tidak ada yang menjawab pertanyaan yang penting setelah nama host menjadi publik: siapa yang diizinkan, terbukti bagaimana, dan dicabut kapan.
Hasilnya adalah lab rumah di mana proxy terbalik dikonfigurasi dengan baik dan aplikasi di belakangnya masing-masing dilindungi oleh apa pun yang dikembang pengembang mereka. Beberapa memiliki TOTP. Beberapa memiliki satu sandi admin bersama di variabel lingkungan. Beberapa memiliki wizard pengaturan yang tetap terbuka sampai seseorang mengunjunginya. Penyedia identitas di depan semua mereka mengubah permukaan yang tidak rata itu menjadi satu pintu, dan pintu adalah satu-satunya hal yang harus Anda dapatkan dengan benar.
Aplikasi
1. Authentik: terbaik secara keseluruhan untuk SSO yang di-host sendiri
Authentik adalah yang paling berakhir di lab rumah, dan dengan alasan yang baik: itu mencakup kedua belah pihak dari masalah. Aplikasi yang berbicara OIDC atau SAML mendapatkan penyedia identitas yang tepat dengan titik akhir penemuan, klaim grup, dan layar persetujuan. Aplikasi yang tidak berbicara apa pun mendapatkan proxy outpost, yang proxy terbalik Anda panggil sebagai forward auth dan yang meneruskan nama pengguna dan email yang diautentikasi ke bawah sebagai header. Semuanya dikonfigurasi melalui UI web, termasuk pembangun alur, yang memungkinkan Anda memutuskan dengan tepat kapan MFA diminta dan kapan sesi dapat digunakan kembali. Pendaftaran, pemulihan, dan pengaturan ulang sandi adalah self-service, yang penting pada saat seseorang selain Anda membutuhkan akun.
Dimana kekurangannya: ini adalah yang terberat dari opsi ringan. Penerapan default adalah kontainer server, kontainer pekerja, Postgres, dan Redis, dan proyek meminta kira-kira 2 inti CPU dan 2 GB RAM sebelum Anda menambahkan apa pun. Sistem alur kuat dan karenanya mudah dikonfigurasi dengan salah, dan alur autentikasi yang rusak mengunci Anda dari antarmuka admin seefektif mengunci semua orang.
Biaya: inti MIT-licensed dan gratis tanpa batas pengguna. Tingkat enterprise berbayar menambahkan dukungan dan fitur yang ditujukan pada perusahaan daripada rumah tangga.
Platform: Docker atau Kubernetes di Linux, dan Docker Desktop di Windows dan macOS.
Unduh: goauthentik.io · GitHub
Garis bawah: jalankan Authentik untuk SSO yang di-host sendiri jika Anda menginginkan satu sistem yang menangani aplikasi modern dan aplikasi yang tidak akan pernah menerapkan OIDC, dan Anda memiliki RAM untuk dilepaskan.
2. Authelia: opsi paling ringan dengan konfigurasi yang dapat Anda kontrol versi
Authelia adalah satu biner Go yang duduk di samping proxy terbalik Anda dan menjawab satu pertanyaan per permintaan. Pengguna tinggal di file YAML atau direktori LDAP yang Authelia tidak miliki, aturan akses tinggal di YAML yang sama, dan seluruh konfigurasi adalah satu artefak yang dapat Anda komitmen ke repositori pribadi dan pulihkan dalam satu menit. Ini mendukung TOTP, kunci keamanan WebAuthn, Duo push, dan passkey, dan itu OpenID Certified sebagai penyedia OIDC, jadi aplikasi yang berbicara OIDC dapat berbicara dengannya secara langsung daripada melalui header. Integrasi forward auth terdokumentasi untuk nginx, Traefik, Caddy, HAProxy, dan Envoy.
Dimana kekurangannya: tidak ada UI admin. Menambahkan pengguna berarti mengedit file dan memuat ulang, yang baik-baik saja untuk rumah tangga dan menyakitkan untuk apa pun yang lebih besar. Pengaturan ulang sandi memerlukan konfigurasi mail yang berfungsi. Sintaks pendaftaran klien OIDC tidak dapat diberdayakan, dan kesalahan ketik dalam URI pengalihan menghasilkan pesan kesalahan yang tidak memberi tahu Anda ujung mana yang salah.
Biaya: gratis dan berlisensi Apache 2.0.
Platform: Docker atau biner statis di Linux, plus Docker di Windows dan macOS.
Unduh: authelia.com · GitHub
Garis bawah: pilihan yang tepat jika aturan akses Anda stabil, Anda nyaman di YAML, dan Anda lebih suka backup satu file daripada satu database.
3. Tinyauth: terbaik untuk mendapatkan login di depan hal-hal malam ini
Tinyauth adalah apa yang Anda capai saat Authelia terasa seperti terlalu banyak upacara. Satu kontainer, satu config, dan halaman login di depan apa pun yang proxy terbalik Anda arahkan ke sana. Ini menangani pengguna lokal, LDAP, dan login OAuth dari penyedia seperti GitHub dan Google, mendukung TOTP, dan menerapkan aturan akses per-aplikasi. Versi 5.1.0 mengambil OpenID Certification untuk profil Basic OP di pertengahan 2026, jadi itu tidak lagi hanya shim forward-auth: aplikasi yang berbicara OIDC dapat menggunakannya sebagai penyedia mereka. Integrasi terdokumentasi mencakup Traefik, nginx, dan Caddy.
Dimana kekurangannya: itu muda, dan proyek itu sendiri memperingatkan bahwa perubahan konfigurasi sering terjadi di antara rilis, jadi upgrade memerlukan membaca catatan rilis daripada membaca tag baru secara membabi buta. Tidak ada SAML, tidak ada RADIUS, dan tidak ada pendaftaran self-service untuk orang yang belum dalam direktori. Jika lab rumah Anda tumbuh melampaui segelintir layanan dengan grup yang berbeda, Anda akan melampaui itu.
Biaya: gratis dan berlisensi AGPL 3.0.
Platform: Docker di Linux, Windows, dan macOS.
Unduh: tinyauth.app · GitHub
Garis bawah: jawaban jujur tercepat untuk “tidak ada login di depan ini sama sekali,” dan cukup kecil sehingga itu hampir tidak ada biaya untuk dijalankan bersama sesuatu yang lebih besar nanti.
4. LLDAP: terbaik untuk satu direktori pengguna yang dapat dibaca oleh yang lain
LLDAP bukan portal SSO. Ini adalah server Rust kecil yang berbicara cukup LDAP untuk perangkat lunak lain untuk autentikasi terhadapnya, dengan UI web untuk mengelola pengguna dan grup dan opsi bagi pengguna untuk mengatur ulang sandi mereka sendiri melalui email. Cakupan sempit itu adalah intinya: Authelia, Authentik, Keycloak, Nextcloud, Jellyfin, dan daftar panjang aplikasi yang di-host sendiri semuanya dapat membaca darinya, jadi Anda mendapatkan satu tempat di mana akun dibuat dan satu tempat di mana mereka dinonaktifkan. Ini menyimpan data di SQLite secara default, dengan MySQL, MariaDB, dan PostgreSQL sebagai alternatif, dan mengekspos API GraphQL jika Anda mengelola pengguna dari kode.
Dimana kekurangannya: sengaja bukan server LDAP penuh. Browser LDAP generik sering gagal terhadapnya, skema hash sandi berarti itu tidak dapat membagikan hash untuk layanan lain untuk memvalidasi, dan proyek menyebut Synology sebagai tidak kompatibel. Itu tidak melakukan otorisasi apa pun sendiri, jadi sesuatu yang lain harus tetap menerapkan aturan akses.
Biaya: gratis dan berlisensi GPL 3.0.
Platform: Docker atau biner di Linux, dan Docker di Windows dan macOS.
Unduh: GitHub
Garis bawah: pasangkan dengan Authelia atau Tinyauth saat Anda menginginkan direktori bersama tanpa menjalankan penerapan LDAP yang sebenarnya, dan lewati sama sekali jika penyedia identitas Anda sudah memiliki pengguna Anda.
5. oauth2-proxy: terbaik untuk menempatkan IdP yang sudah Anda jalankan di depan satu aplikasi
oauth2-proxy tidak memiliki akun sendiri. Ini adalah klien yang mengirim pengunjung ke penyedia OIDC atau OAuth2 yang sudah Anda miliki, memeriksa hasilnya, dan kemudian baik proxy permintaan ke aplikasi Anda atau menjawab auth_request nginx dengan ya atau tidak. Ini mendukung OIDC generik bersama dengan integrasi khusus untuk Google, Microsoft Entra ID, GitHub, dan lainnya, dan implementasi khusus penyedia dapat menarik keanggotaan kelompok dan meneruskannya ke bawah sebagai header. Ini adalah proyek CNCF Sandbox dan telah secara diam-diam melakukan pekerjaan ini selama bertahun-tahun.
Dimana kekurangannya: itu memecahkan tepat satu masalah dan mengharapkan Anda telah memecahkan yang lain. Tidak ada manajemen pengguna, tidak ada MFA sendiri, dan tidak ada mesin kebijakan di luar daftar izin email, domain, dan grup. Mendapatkan klaim kelompok melalui aplikasi berarti mencocokkan nama klaim penyedia Anda dengan tangan, dan mode kegagalan adalah login berhasil tanpa izin.
Biaya: gratis dan berlisensi MIT.
Platform: Docker atau biner di Linux, macOS, dan Windows.
Unduh: oauth2-proxy docs · GitHub
Garis bawah: pilihan yang tepat saat Anda sudah menjalankan Authentik, Keycloak, atau Zitadel dan membutuhkan satu aplikasi keras kepala untuk menghormatinya.
6. Zitadel: terbaik saat Anda menginginkan jejak audit dari setiap acara identitas
Zitadel adalah platform identitas Go yang dibangun pada sourcing acara, yang berarti setiap perubahan pada pengguna, peran, atau sesi disimpan sebagai acara yang tidak dapat diubah alih-alih baris yang diperbarui. Untuk lab rumah itu terdengar seperti over-engineering sampai pertama kali Anda perlu menjawab kapan akun dibuat dan oleh siapa. Ini mencakup OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0, dan LDAP, mendukung OTP melalui aplikasi, email, dan SMS, plus passkey U2F dan FIDO2, dan multi-tenant dari awal jika Anda menyelenggarakan layanan untuk lebih dari satu rumah tangga atau bisnis sampingan.
Dimana kekurangannya: itu memerlukan PostgreSQL 14 atau lebih baru, dan pengaturan mengasumsikan Anda memahami model organisasi dan proyek sebelum membuat aplikasi pertama Anda. Desain API-pertama luar biasa jika Anda membuat skrip infrastruktur Anda dan lebih berat dari yang diperlukan jika Anda hanya menginginkan halaman login. Self-hosting adalah AGPL 3.0, yang patut dibaca jika Anda berencana untuk membangun apa pun yang komersial di atasnya.
Biaya: gratis untuk self-host. Layanan yang dihosting ditagih secara terpisah.
Platform: Docker atau Kubernetes di Linux, plus biner untuk Linux dan macOS.
Unduh: zitadel.com · GitHub
Garis bawah: pilih Zitadel daripada Authentik saat logging gaya kepatuhan atau multi-tenancy adalah persyaratan nyata daripada ide bagus.
7. Keycloak: terbaik untuk cakupan protokol dan federasi yang paling luas
Keycloak adalah opsi perusahaan, sekarang proyek CNCF dengan lebih dari satu dekade penggunaan produksi di belakangnya. Jika sesuatu perangkat lunak mendukung SSO sama sekali, itu hampir pasti mendokumentasikan integrasi Keycloak. Ini berfederasi terhadap LDAP dan Active Directory yang ada, broker ke penyedia eksternal, melakukan otorisasi fine-grained dengan mesin kebijakan sendiri, dan menangani sudut SAML yang canggih yang alat yang lebih ringan lewati. Memulai sungguh-sungguh cepat dengan start-dev di Docker, yang berjalan terhadap database tertanam untuk evaluasi.
Dimana kekurangannya: start-dev bukanlah konfigurasi produksi, dan pindah ke satu berarti database eksternal, konfigurasi nama host yang membuat hampir semua orang tersandung pertama kali, dan runtime Java yang penggunaan memorinya dimulai di mana Authelia berakhir. Itu tidak memiliki mode forward-auth sendiri, jadi aplikasi yang tidak berbicara OIDC atau SAML memerlukan oauth2-proxy di depan mereka. Konsol admin mengasumsikan kosakata (realms, clients, mappers) yang tidak akan diajarkan oleh panduan lab rumah mana pun.
Biaya: gratis dan berlisensi Apache 2.0.
Platform: Docker atau distribusi Java di Linux, Windows, dan macOS.
Unduh: keycloak.org · GitHub
Garis bawah: layak biaya setup jika Anda membutuhkan federasi SAML atau Anda berlatih untuk tumpukan yang sama di tempat kerja, dan sulit untuk membenarkan enam kontainer di belakang Traefik.
8. Pomerium: terbaik untuk kebijakan yang diputuskan per permintaan, bukan per login
Pomerium membalikkan pengaturan biasa. Alih-alih penyedia identitas yang memberikan sesi dan proxy yang mempercayainya, Pomerium adalah proxy, dan ia mengevaluasi kebijakan pada setiap permintaan tunggal menggunakan identitas dari penyedia OIDC hulu plus konteks tentang permintaan itu sendiri. Kebijakan ditulis sebagai konfigurasi alih-alih diklik bersama, jadi aturan akses tinggal di repositori yang sama dengan sisa infrastruktur Anda. Ini tanpa klien, berarti tidak ada yang harus memasang aplikasi VPN untuk mencapai layanan internal, dan itu berlisensi Apache 2.0 dengan bidang kontrol yang dikelola terpisah untuk organisasi yang menginginkan GUI.
Dimana kekurangannya: itu tidak memiliki pengguna, jadi Anda masih memerlukan Authentik, Keycloak, Zitadel, atau penyedia yang dihosting di belakangnya. Penerapan khas lebih dari satu kontainer dengan penyimpanan persisten. Dan karena itu menggantikan proxy terbalik Anda daripada duduk di sampingnya, mengadopsi Pomerium berarti mengerjakan kembali perutean dan sertifikat yang sudah berfungsi, yang merupakan banyak gangguan untuk lab rumah yang hanya menginginkan halaman login.
Biaya: gratis dan open source untuk self-host. Bidang kontrol yang dihosting adalah produk berbayar.
Platform: Docker atau Kubernetes di Linux, plus biner untuk Linux dan macOS.
Unduh: pomerium.com · GitHub
Garis bawah: pilih saat keputusan akses perlu memperhitungkan lebih dari “orang ini login satu jam yang lalu,” dan over-engineer untuk apa pun yang lebih kecil.
Gesekan yang tidak ada orang sebutkan dalam panduan pengaturan
Separuh aplikasi Anda tidak berbicara OIDC. Forward auth adalah fallback: proxy terbalik bertanya kepada penyedia identitas, dan pada keberhasilan meneruskan header seperti Remote-User dan Remote-Email ke aplikasi. Itu hanya bekerja jika aplikasi dapat dikonfigurasi untuk mempercayai header tersebut, dan itu hanya aman jika aplikasi tidak dapat dicapai kecuali melalui proxy. Ikat kontainer ke jaringan Docker internal daripada port host, karena aplikasi yang mempercayai header identitas akan mempercayai mereka dari siapa saja yang dapat menjangkaunya secara langsung.
Ketika penyedia identitas tidak aktif, semuanya tidak aktif. Postgres mengisi disk, update kontainer gagal, sertifikat berakhir, dan tiba-tiba tidak ada yang di rumah login. Tentukan jalur pemecahan kaca sebelum Anda membutuhkannya: simpan setidaknya satu rute ke infrastruktur Anda yang tidak melintasi penyedia identitas, seperti SSH melalui mesh VPN atau akses konsol di jaringan lokal, dan ketahui layanan mana yang akan Anda sementara kecualikan dari forward auth untuk mengembalikan sisanya. Tulis di suatu tempat yang tidak di belakang login yang baru saja Anda hilangkan.
Backup harus mencakup toko identitas, bukan hanya konfigurasi. Untuk Authelia keadaannya adalah file YAML plus database kecil pendaftaran TOTP dan WebAuthn. Untuk Authentik, Zitadel, atau Keycloak itu database Postgres plus kunci rahasia, dan mengembalikan database tanpa rahasia yang cocok memberi Anda layanan yang dimulai dan kemudian menolak setiap sesi. Dump database sesuai jadwal, simpan rahasia secara terpisah, dan uji pemulihan sekali daripada menemukan celah selama pemadaman.
SSO di depan server media menghancurkan aplikasi native. Ini adalah perangkap spesifik dalam skenario Plex. Aplikasi televisi atau klien seluler tidak dapat menyelesaikan alur login berbasis browser, jadi menempatkan forward auth di seluruh hostname menghentikan klien tersebut terhubung sama sekali. Solusi biasa adalah mengecualikan jalur API dari SSO, yang secara diam-diam membawa Anda kembali ke autentikasi server media sendiri untuk tepat lalu lintas yang membawa perpustakaan Anda. Jawaban yang lebih bersih adalah menjaga lalu lintas klien asli di mesh VPN dan menerapkan SSO ke antarmuka web saja, atau menggunakan penyedia identitas yang didukung server media secara langsung daripada membungkusnya dari luar.
Jangan pernah buat penyedia identitas menjadi tautan terlemah. Antarmuka adminnya harus dapat dijangkau hanya dari jaringan internal Anda atau melalui VPN, MFA harus wajib untuk setiap akun yang dapat mengubah kebijakan, dan verifikasi sertifikat tetap ada di mana-mana. Penyedia identitas yang dikonfigurasi dengan salah lebih buruk daripada tidak ada, karena itu memusatkan akses alih-alih mendistribusikannya.
Cara memilih yang tepat
- Jika Anda menginginkan satu sistem yang mencakup aplikasi OIDC dan aplikasi header-only: Authentik.
- Jika Anda menginginkan seluruh kebijakan akses Anda dalam file yang dapat Anda backup dan diff: Authelia.
- Jika tidak ada yang memiliki login dan Anda menginginkan itu diperbaiki malam ini: Tinyauth.
- Jika Anda sudah memiliki beberapa aplikasi yang membaca LDAP dan tidak ada direktori pusat: LLDAP.
- Jika Anda sudah menjalankan penyedia identitas dan satu aplikasi menolak menggunakannya: oauth2-proxy.
- Jika Anda memerlukan jejak audit atau Anda menyelenggarakan layanan untuk lebih dari satu kelompok orang: Zitadel.
- Jika Anda memerlukan federasi SAML atau Anda ingin belajar tumpukan yang sama dengan tempat kerja Anda: Keycloak.
- Jika akses harus dievaluasi ulang per permintaan daripada per sesi: Pomerium.
Untuk sebagian besar orang yang membuka home server ke internet untuk pertama kalinya, jawaban yang jujur adalah Authentik jika perangkat keras dapat membawanya, dan Authelia jika tidak bisa. Keduanya memberi Anda satu login, MFA yang diterapkan, dan satu tempat untuk mencabut akses, yang poin keseluruhannya.
FAQ
Apa solusi SSO self-hosted terbaik untuk lab rumah?
Authentik mencakup berbagai situasi yang paling luas, karena berfungsi sebagai penyedia identitas penuh untuk aplikasi yang berbicara OIDC atau SAML dan sebagai gateway forward-auth untuk aplikasi yang tidak berbicara keduanya. Authelia adalah kecocokan yang lebih baik pada perangkat keras terbatas atau saat Anda menginginkan seluruh konfigurasi dalam file yang dikontrol versi. Keduanya gratis dan keduanya menerapkan MFA di setiap layanan di belakang mereka.
Apakah saya perlu SSO jika proxy terbalik saya sudah memiliki TLS dan sandi?
Mereka memecahkan masalah yang berbeda. TLS melindungi lalu lintas dalam transit dan basic auth melindungi hostname tunggal dengan rahasia bersama yang tidak dapat dicabut per orang atau didukung oleh MFA. SSO memberikan setiap orang identitas mereka sendiri, menerapkan faktor kedua sekali untuk segalanya, dan memungkinkan Anda menghapus akses di satu tempat. Proxy terbalik adalah tempat SSO diterapkan, bukan pengganti untuknya.
Bisakah saya menempatkan SSO di depan Plex atau Jellyfin?
Sebagian. Antarmuka web bekerja dengan baik di belakang forward auth. Aplikasi asli di ponsel, televisi, dan kotak streaming tidak dapat menyelesaikan login berbasis browser, jadi mereka rusak kecuali Anda mengecualikan jalur API, yang melemahkan perlindungan untuk lalu lintas yang paling penting. Jaga klien asli di mesh VPN dan lindungi antarmuka web dengan SSO, atau gunakan penyedia identitas yang terintegrasi server media dengan langsung.
Apa yang terjadi jika penyedia identitas saya offline?
Setiap layanan di belakangnya berhenti menerima login, dan sesi yang ada berakhir pada jadwal normal mereka. Rencanakan: simpan akses jaringan lokal atau VPN ke host Anda yang tidak bergantung pada penyedia identitas, simpan cara yang terdokumentasi untuk menonaktifkan forward auth pada satu layanan, dan simpan kode pemulihan dan backup database di suatu tempat yang dapat dijangkau tanpa login.
Apakah Keycloak berlebihan untuk home server?
Biasanya ya. Kekuatan Keycloak adalah federasi SAML, brokering ke penyedia eksternal, dan otorisasi fine-grained pada skala organisasi, dan biayanya adalah runtime Java, database eksternal, dan kosakata yang harus Anda pelajari terlebih dahulu. Untuk selusin kontainer di belakang proxy terbalik, Authentik atau Authelia memberikan hasil praktis yang sama dengan setup jauh lebih sedikit.
Apakah alat ini menyimpan sandi saya, dan bagaimana cara saya membuat backup?
Authentik, Authelia, Zitadel, Keycloak, LLDAP, dan Tinyauth semuanya menyimpan kredensial dalam beberapa bentuk. oauth2-proxy dan Pomerium tidak menyimpan apa pun dan mendelegasikan hulu. Untuk yang melakukannya, backup database atau file konfigurasi bersama dengan kunci rahasia instance, karena restore tanpa rahasia yang cocok membuat setiap sesi dan faktor kedua terdaftar tidak valid.
