Authéntik self-hosted SSO para sa lahat ng app

Isang login para sa bawat app na naka-host mo

Ang Authentik ay isang self-hosted SSO (single sign-on) server: isang beses lang mag-sign in ang mga user, at tatanggapin ng bawat app na nasa likod nito ang session na iyon sa halip na humingi ng sarili nitong password. Ang installation ay binubuo ng official Docker Compose file at dalawang generated secret. Ang bahaging nangangailangan ng masusing pag-iisip ay nasa kasunod na proseso: pagtuturo ng reverse proxy rito at paglalagay ng isang umiiral na app sa likod ng forward auth.

Tatlong service ang inilalabas ng Authentik sa Compose file na iyon: isang PostgreSQL database, isang server process, at isang worker process. Tumatakbo rin sa server container ang embedded outpost, na siyang component na sumasagot sa tanong na “signed in ba ang request na ito?” para sa bawat protected app. Ang Version 2026.5 ang kasalukuyang release noong July 2026, at inirerekomenda ng project ang host na may hindi bababa sa 2 CPU cores at 2 GB ng RAM. Ituring ito bilang minimum. Parehong gumagamit ng memory ang PostgreSQL at worker matapos nang isang araw na tumatakbo ang server.

Ano ang kailangan bago magsimula

Kailangan mo ng Docker Engine na may Compose v2 plugin. Makukumpirma mo ito gamit ang docker compose version. Kung error ang lumabas sa halip na version, i-install muna ang plugin bago magpatuloy. Tinalakay ang mga pangunahing hakbang sa pagpapatakbo ng mga app gamit ang Docker Compose sa isang VPS. Kailangan mo rin ng DNS A record na nakaturo sa server, gaya ng auth.example.com sa mga halimbawa sa ibaba, dahil binubuo ng Authentik ang redirect URLs nito batay sa hostname na ginamit ng browser.

Patakbuhin ang stack bilang ordinaryong user na kabilang sa docker group, hindi bilang root. Ang pagiging miyembro ng group na iyon ay katumbas ng root access sa host. Kaya ibigay ito sa isang deploy account lamang at huwag sa iba, alinsunod sa mga user account na may least privilege sa isang VPS.

Mag-install gamit ang opisyal na Compose file

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

Dapat maglista ang docker compose ps ng tatlong container. Dapat iulat ng postgresql ang healthy, at dapat iulat ng server ang worker at running. Sa unang pag-start, isinasagawa ang database migrations, kaya maghintay nang isang minuto bago sumagot ang web interface.

Mahalaga ang dalawang value na nabuo, ngunit magkaiba ang dahilan. Ang PG_PASS ang PostgreSQL password, at may hard limit itong 99 character. Ginagamit ang AUTHENTIK_SECRET_KEY sa pag-sign ng sessions at tokens. Kapag binago ito sa ibang pagkakataon, ma-la-log out ang lahat ng user at mai-invalidate ang lahat ng API token na na-issue mo. Panatilihin ang .env sa mode 600 at magtabi ng kopya sa ligtas na lugar. Kapag na-restore ang database nang walang katugmang secret key, walang makakapag-login sa database.

Binabasa ng Compose file ang dalawang value gamit ang anyong ${PG_PASS:?database password required}. Dahil dito, tatangging mag-start ang Compose kapag wala ang file. Kapag pinatakbo ang docker compose up -d mula sa maling directory, ipi-print nito ang required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required at hihinto. Path problem ang mensaheng iyon, hindi config problem.

Mga environment value na mahalaga

Lahat ng iba pa ay inilalagay sa parehong .env file. Tinutumbasan ng Authentik ang double underscore ng nested configuration key, kaya itinatakda ng AUTHENTIK_EMAIL__HOST ang email.host. Binabalewala ang single underscore nang walang warning. Ito ang pinakakaraniwang dahilan kung bakit tila walang epekto ang isang setting.

• Itinatakda ng AUTHENTIK_BOOTSTRAP_PASSWORD ang password ng built-in na akadmin user sa unang pagsisimula, kaya hindi mo kailangang mag-type ng password sa public web form. Sa parehong paraan, itinatakda ng AUTHENTIK_BOOTSTRAP_EMAIL at AUTHENTIK_BOOTSTRAP_TOKEN ang address ng user na iyon at isang API token.
• Inililipat ng COMPOSE_PORT_HTTP at COMPOSE_PORT_HTTPS ang published ports mula sa default na 9000 at 9443.
• Kino-configure ng AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS at AUTHENTIK_EMAIL__FROM ang outbound mail. Kung wala ang mga ito, sinusubukan ng Authentik na gamitin ang localhost sa port 25, kaya nagtatapos bilang connection error sa worker log ang mga email para sa password reset.
• Ino-on ng AUTHENTIK_LOG_LEVEL=debug ang detalye na kailangan mo habang may problema ang login flow. Ibalik ito sa info pagkatapos.
• Ang default ng AUTHENTIK_ERROR_REPORTING__ENABLED ay false. Itakda lamang ito sa true kung ayos sa iyo na magpadala ng crash reports sa upstream project.

Mga secret ang mga ito sa isang plain file, kaya pangasiwaan ang directory na ito gaya ng iba pang credential store. Mas mainam na ilagay ang recovery copy sa isang self-hosted na Vaultwarden instance kaysa sa isang note sa iyong laptop.

Unang pag-login at ang admin account

Buksan ang http://SERVER_IP:9000 sa isang browser. Ipinapakita ng Authentik ang initial setup flow nito at hinihiling nitong magtakda ka ng password para sa default na akadmin user. Kung naitakda mo na ang AUTHENTIK_BOOTSTRAP_PASSWORD, tapos na ang hakbang na iyon at direkta kang mapupunta sa login page.

Gumawa ng normal na admin user para sa sarili mo sa ilalim ng Directory at pagkatapos ay Users, idagdag ito sa grupong authentik Admins, at mag-sign in gamit ang account na iyon. Iwan ang akadmin bilang break-glass account, na may mahaba at offline na nakaimbak na password. Sinisira ng pang-araw-araw na paggamit ng shared built-in account ang audit log, dahil akadmin ang nakalagay sa bawat event at walang nagsasabi kung sino ang aktuwal na gumawa nito. Umaabot din ang argumentong ito sa downstream ng Authentik: ang gaya ng self-hosted na OneCLI harness na nagbibigay sa bawat tao ng sarili nilang agent ay makapag-iiwan lamang ng malinaw na trail kung ang identity na dumarating dito ay pagmamay-ari ng isang tao, sa halip na login na pinagsasaluhan ng buong team.

Ilagay ang Authentik sa likod ng reverse proxy

Gumagana ang pag-publish ng port 9000 sa internet, pero kailangan mo ng TLS (transport layer security) at aktuwal na hostname. Kung ginagamit mo na ang setup mula sa Traefik bilang reverse proxy para sa maraming Compose app, isama ang Authentik sa parehong external na proxy network gamit ang override file. Gumawa ng docker-compose.override.yml sa tabi ng compose.yml:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

Ilapat ito gamit ang docker compose up -d. Awtomatikong pinagsasama ng Compose ang override, kaya mananatili sa server service ang lahat ng nasa official file at madaragdagan ito ng mga label. Suriin gamit ang curl -I https://auth.example.com/if/user/; dapat itong sumagot ng HTTP/2 200. Ang 404 page not found mula sa Traefik ay nangangahulugang wala ang container sa proxy network, kaya hindi maire-route ng Traefik ang container na hindi nito maabot.

Kapag gumagana na ang hostname, i-bind ang mga published port sa 127.0.0.1 sa override, para proxy lamang ang tanging paraan ng pag-access.

Protektahan ang isang app gamit ang forward auth

May tatlong mode ang Authentik proxy provider, at maaaring umabot ng isang oras ang masasayang kapag mali ang napili. Ang Proxy ay nangangahulugang ang outpost mismo ang nagpapasa ng traffic sa upstream app. Sa Forward auth (single application), ang sarili mong reverse proxy pa rin ang nagpapasa ng traffic at tinatanong lamang nito ang Authentik kung naka-sign in ang request. Pinoprotektahan ng Forward auth (domain level) ang bawat app sa ilalim ng iisang parent domain gamit ang isang provider, kapalit ng kawalan ng hiwalay na authorization rules para sa bawat application. Kung Traefik ang nasa harap, piliin ang Forward auth (single application). Kung kailangan mo ng konkretong app na mapag-eensayuhan, magandang unang kandidato ang isang self-hosted na AFFiNE workspace, dahil uri ito ng internal tool na dapat ma-access mula sa sarili mong mga device at mula sa wala nang iba. Mas malinaw pa ang pakinabang para sa isang team tool: ilagay ang isang self-hosted na Chatwoot support desk sa likod ng parehong provider, upang isang beses lang mag-sign in sa buong araw ang bawat sumasagot sa inbox sa halip na magbahagi na naman ng isa pang password.

Sa web interface, buksan ang Applications at pagkatapos ay Providers, gumawa ng Proxy Provider, piliin ang forward auth single application mode, at itakda ang external host sa https://app.example.com. Gumawa ng Application na tumutukoy sa provider na iyon. Pagkatapos, buksan ang Outposts, i-edit ang authentik Embedded Outpost, at ilipat ang bagong application sa selected applications nito. Sumasagot lamang ang outpost para sa mga application na itinalaga rito, kaya kapag nilaktawan ang huling hakbang, walang ibinabalik ang provider kahit tama ang configuration nito.

I-define nang isang beses ang middleware sa Authentik container, at i-reference ito mula sa bawat protected app:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

Ang authResponseHeaders ang listahan ng mga header na kinokopya ng Traefik mula sa sagot ng Authentik papunta sa request na ipinapadala nito upstream. Kapag inalis ito, protected pa rin ang app, pero hindi nito malalaman kung sino ang user. Dahil dito, mananatiling naka-logout ang anumang bumabasa sa X-authentik-username para sa automatic login.

Ang mismong protected app ay nangangailangan ng dalawang router, hindi isa:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

Ang pangalawang router ang madalas nakakaligtaan. Pagkatapos ng sign-in, ibinabalik ng Authentik ang browser sa path sa ilalim ng /outpost.goauthentik.io/ sa hostname ng app, hindi sa auth.example.com. Kung walang router na nagpapasa ng path prefix na iyon sa Authentik service, mapupunta ang request sa app. 404 ang isasagot nito, kaya hindi matatapos ang login. Ang mas mataas na priority ang dahilan kung bakit nananalo ang partikular na path rule laban sa simpleng Host() rule sa parehong domain.

Subukan ito sa private browser window. Dapat kang ipadala sa auth.example.com, mag-sign in, at bumalik sa app. Sa panig ng Authentik, ang docker compose logs -f server ay nagpi-print ng authorization event para sa bawat attempt. Ipinapakita nito kung nakarating man lang sa Authentik ang request.

Mga failure na aktuwal mong mararanasan

Walang katapusang redirect loop sa pagitan ng app at login page. Hindi tugma ang external host sa provider at ang ginagamit ng browser; karaniwan, http:// ang nasa provider samantalang https:// ang nasa address bar. Itinatakda ang session cookie para sa ibang origin, kaya ang bawat balik ay itinuturing na bagong anonymous request. Ayusin ang external host at i-clear ang cookies para sa parehong domain bago muling mag-test.

404 sa /outpost.goauthentik.io/start. Nawawala ang outpost router, o mas mababa ang priority nito kaysa sa catch-all router para sa host na iyon.

Naglo-load ang app nang hindi kailanman humihingi ng login. Ang label na middlewares ay tumutukoy sa middleware na hindi umiiral. Hindi naglalabas ng warning ang Traefik tungkol dito, kaya ang typo sa authentik@docker ay nangangahulugang walang middleware na tumatakbo. Buksan ang Traefik dashboard at tiyaking nakalista ang middleware sa router.

403 mula sa Authentik matapos ang matagumpay na login. Authenticated ang user pero hindi authorized: may policy binding o group requirement ang application na hindi natutugunan ng user na ito. Tinutukoy sa Events log ng admin interface ang policy na tumanggi sa request.

Kapag mas angkop ang Keycloak

Ang Keycloak ang mas matagal nang proyekto, sinusuportahan ng Red Hat, at mas mahusay na pagpipilian para sa klasikong enterprise identity work: malawakang SAML federation, pag-broker ng mga login mula sa maraming external identity provider nang sabay-sabay, at realm export at import bilang dokumentadong migration path. Mahalaga sa ilang organisasyon ang commercial support nito, lalo na sa pormal na dokumentasyon. Ang kapalit nito ay walang sariling proxy ang Keycloak. Kaya kung ang isang app ay hindi nagsasalita ng OIDC (OpenID Connect), kailangan mong magpatakbo ng gaya ng oauth2-proxy kasama nito. Ang built-in proxy provider ng Authentik ang gumaganap sa bahaging iyon at integrated na ito. Dahil dito, dito karaniwang napupunta ang karamihan sa self-hoster na gumagamit ng iba-ibang app.

Mga backup at upgrade

Tatlong bagay ang kailangan para maging posible ang pag-restore: ang PostgreSQL database, ang ./data directory, at ang .env.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

I-store nang magkasama ang dump at .env. Hindi sapat ang dump lang dahil nasa .env ang secret key na nagpoprotekta sa session at token data.

Ang mga upgrade ay pagbabago ng tag. Itakda ang AUTHENTIK_TAG sa .env sa release na gusto mo, pagkatapos ay patakbuhin ang docker compose pull na sinusundan ng docker compose up -d. Basahin muna ang release notes dahil gumagamit ang Authentik ng date-based versions, at may ilang release na may migrations na nangangailangan na mula ka sa naunang release. Gawin ang database dump bago ang pull, hindi pagkatapos.

FAQ

Libre bang i-self-host ang Authentik?

Libre ang open source edition at saklaw nito ang lahat ng nabanggit sa itaas: proxy provider, forward auth, OIDC (OpenID Connect), SAML, at flows engine. May support at ilang enterprise feature ang bayad na enterprise tier, pero walang bahagi rito na nangangailangan ng license.

Kailangan ba ang Traefik para magamit ang Authentik?

Hindi. Gumagana ang forward auth sa nginx sa pamamagitan ng auth_request at sa Caddy sa pamamagitan ng forward_auth. Pareho ang pattern sa lahat ng kaso: tinatanong ng reverse proxy ang Authentik tungkol sa bawat request, at dapat i-route sa Authentik ang path prefix na /outpost.goauthentik.io/ sa protected hostname sa halip na sa app.

Bakit paulit-ulit na bumabalik ang protected app sa login at error?

Hindi tugma ang external host na naka-configure sa proxy provider sa URL na ginagamit ng browser, kadalasan ay http laban sa https. Ini-issue ang session cookie para sa isang origin at binabasa sa iba, kaya itinuturing ng Authentik na anonymous ang request sa bawat pagkakataon. Ayusin ang external host, pagkatapos ay i-clear ang cookies para sa parehong hostname bago muling mag-test.

Gaano karaming RAM ang kailangan ng Authentik?

Ang dokumentadong minimum ay 2 CPU core at 2 GB RAM noong July 2026, para sa PostgreSQL, server, at worker nang magkakasama. Sa isang 2 GB na machine, ang worker ang unang pinapatay ng kernel kapag kulang ang memory, kaya humihinto ang background task at outbound email habang gumagana pa ang login page. Bigyan ito ng 4 GB kung tumatakbo rin sa parehong server ang mga app na pinoprotektahan mo.