Authenik self-hosted SSO para sa lahat ng app

Isang login para sa bawat app na iyong hinahost

Ang Authentik ay isang self-hosted na SSO (single sign-on) server: isang beses lang mag-sign in ang iyong 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 gumagamit ng opisyal na Docker Compose file at dalawang nabuong secret. Ang bahaging nangangailangan ng maingat na pag-configure ay pagkatapos nito: ituro rito ang isang reverse proxy, at ilagay ang isang umiiral na app sa likod ng forward auth.

Ang Authentik ay inilalabas bilang tatlong service sa Compose file na iyon: isang PostgreSQL database, isang server process, at isang worker process. Pinapatakbo rin ng server container ang embedded outpost, ang component na sumasagot sa tanong na “signed in ba ang request na ito?” para sa bawat protected app. Ang bersyong 2026.5 ang kasalukuyang release noong Hulyo 2026, at inirerekomenda ng project ang host na may hindi bababa sa 2 CPU core at 2 GB ng RAM. Ituring iyon bilang minimum. Parehong kumokonsumo ng memory ang PostgreSQL at worker kapag isang araw nang umaandar ang server.

Mga 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 bersyon, i-install ang plugin bago magpatuloy. Makikita 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, auth.example.com sa mga halimbawa sa ibaba, dahil binubuo ng Authentik ang mga redirect URL nito batay sa hostname na ginamit ng browser.

Patakbuhin ang stack bilang ordinaryong user na kabilang sa docker group, hindi bilang root. Katumbas ng root sa host ang pagiging miyembro ng group na ito. Kaya ibigay ito sa isang deploy account lamang at huwag sa iba, gaya ng inilalarawan sa mga user account na may pinakamaliit na pribilehiyo 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, kung saan nag-uulat ang postgresql ng healthy at server, at nag-uulat ang worker ng running. Isinasagawa ng unang pag-start ang mga database migration, kaya maghintay nang isang minuto bago tumugon ang web interface.

Mahalaga ang dalawang nabuong value, ngunit magkaiba ang dahilan. Ang PG_PASS ang PostgreSQL password, at may hard limit itong 99 character. Ang AUTHENTIK_SECRET_KEY ang lumalagda sa mga session at token, kaya kapag binago ito sa hinaharap, mala-log out ang lahat ng user at magiging invalid ang bawat API token na na-issue mo. Panatilihin ang .env sa mode 600 at magtabi ng kopya sa ligtas na lugar, dahil ang database na na-restore nang walang katugmang secret key ay database na walang makakapag-log in.

Binabasa ng Compose file ang dalawang value gamit ang anyong ${PG_PASS:?database password required}, kaya 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.

Mahahalagang value ng environment

Ang lahat ng iba pa ay inilalagay sa parehong .env file. Itinatakda ng Authentik ang double underscore bilang nested configuration key, kaya itinatakda ng AUTHENTIK_EMAIL__HOST ang email.host. Binabalewala ang single underscore nang walang babala. Ito ang pinakakaraniwang dahilan kung bakit mukhang walang epekto ang isang setting.

• Itinatakda ng AUTHENTIK_BOOTSTRAP_PASSWORD ang password ng built-in na akadmin user sa unang pag-start, kaya hindi mo kailangang mag-type ng password sa isang pampublikong 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 ang localhost sa port 25, kaya nagtatapos bilang connection error sa worker log ang mga password-reset mail.
• Ina-activate ng AUTHENTIK_LOG_LEVEL=debug ang detalye na kailangan mo habang may problema sa login flow. Ibalik ito sa info pagkatapos.
• Ang default na value ng AUTHENTIK_ERROR_REPORTING__ENABLED ay false. Itakda ito sa true kung sang-ayon kang magpadala ng crash reports sa upstream.

Mga secret ang mga ito sa isang plain file, kaya pangasiwaan ang directory tulad 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 admin account

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

Gumawa ng regular na admin user para sa iyong sarili sa ilalim ng Directory at pagkatapos ay Users, idagdag ito sa grupong authentik Admins, at mag-sign in gamit ang account na iyon. Panatilihin ang akadmin bilang break-glass account, na may mahabang password na naka-store offline. Sinisira ng pang-araw-araw na paggamit ng iisang built-in account ang audit log, dahil akadmin ang nakalagay sa bawat event at walang nagsasaad kung sino ang nagsagawa nito.

Ilagay ang Authentik sa likod ng iyong 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, idagdag ang Authentik sa parehong external na proxy network gamit ang override file. Gawin ang 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 opisyal na file at madaragdagan ito ng mga label. Suriin gamit ang curl -I https://auth.example.com/if/user/, na dapat sumagot sa HTTP/2 200. Ang 404 page not found mula sa Traefik ay nangangahulugang wala ang container sa proxy network, at hindi mai-route ng Traefik ang traffic sa container na hindi nito maabot.

Kapag gumagana na ang hostname, i-bind ang mga naka-publish na port sa 127.0.0.1 sa override, para ang proxy lamang ang maging daanan papasok.

Protektahan ang isang app gamit ang forward auth

May tatlong mode ang proxy provider ng Authentik, at maaaring umabot ng isang oras ang pag-debug kapag mali ang napili. Ang Proxy ay nangangahulugang ang outpost mismo ang nagfa-forward ng traffic sa upstream app. Sa Forward auth (single application), ang sarili mong reverse proxy pa rin ang naglilipat ng traffic at nagtatanong lamang sa Authentik kung naka-sign in ang request. Pinoprotektahan ng Forward auth (domain level) ang lahat ng app sa ilalim ng iisang parent domain gamit ang isang provider, kapalit ng hiwa-hiwalay na authorization rule para sa bawat application. Kapag Traefik ang nasa unahan, piliin ang forward auth (single application).

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 idagdag ang bagong application sa selected applications nito. Ang outpost ay sumasagot lamang para sa mga application na itinalaga rito. Kaya kapag nilaktawan ang huling hakbang, walang ibinabalik ang provider kahit tama ang configuration nito.

I-define ang middleware nang isang beses sa Authentik container, at i-reference ito mula sa bawat protektadong 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 ay listahan ng mga header na kinokopya ng Traefik mula sa sagot ng Authentik papunta sa request na ipinapadala nito sa upstream. Kapag inalis ito, protektado pa rin ang app, pero hindi nito malalaman kung sino ang user. Kaya mananatiling naka-log out ang anumang nagbabasa ng X-authentik-username para sa automatic login.

Kailangan ng mismong protektadong app 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 isang path sa ilalim ng /outpost.goauthentik.io/ sa hostname ng app, hindi sa auth.example.com. Kung walang router na nagpapadala ng path prefix na iyon sa Authentik service, mapupunta ang request sa app mo. Magbabalik ito ng 404, 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, nagpi-print ang docker compose logs -f server ng isang authorization event para sa bawat pagtatangka. Ipinapakita nito kung nakarating ba talaga 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 sa ginagamit ng browser; karaniwan, http:// ang nasa provider samantalang https:// ang nasa address bar. Itinatakda ang session cookie para sa ibang origin, kaya sa bawat pagbabalik ay itinuturing itong 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. Tinutukoy ng label na middlewares ang middleware na hindi umiiral. Hindi nagbibigay ng babala ang Traefik tungkol dito, kaya ang typo sa authentik@docker ay nangangahulugang walang middleware na tumatakbo. Buksan ang Traefik dashboard at kumpirmahing nakalista ang middleware sa router.

403 mula sa Authentik pagkatapos ng matagumpay na login. Authenticated ang user ngunit hindi authorized: may policy binding o requirement sa group 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, na sinusuportahan ng Red Hat. Mas mainam ito para sa klasikong enterprise identity work: malawakang SAML federation, sabay-sabay na pag-broker ng mga login mula sa ilang external identity provider, at pag-export at pag-import ng realm bilang dokumentadong migration path. Mahalaga rin sa ilang organisasyon ang commercial support na nakalaan dito. Ang kapalit nito ay walang sariling proxy ang Keycloak. Kaya para maprotektahan ang app na hindi gumagamit 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 ito at integrated na ito. Dahil dito, dito napupunta ang karamihan sa mga self-hoster na may magkakaibang 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

Itabi ang dump at ang .env nang magkasama. Hindi sapat ang dump lamang, 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 sinundan ng docker compose up -d. Basahin muna ang release notes, dahil gumagamit ang Authentik ng mga bersiyong batay sa petsa at may ilang release na naglalaman ng mga migration na inaasahang manggagaling ka sa naunang release. Gawin ang database dump bago ang pull, hindi pagkatapos.

FAQ

Libre ba ang Authentik para sa self-hosting?

Libre ang open source edition at kasama na rito ang lahat ng nabanggit sa itaas: ang 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 ang nangangailangan ng lisensya.

Kailangan ko ba ng 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: nagtatanong ang reverse proxy sa 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 ko 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. Ibinibigay ang session cookie para sa isang origin at binabasa sa isa pa, kaya itinuturing ng Authentik na anonymous ang request sa bawat pagkakataon. Itama 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. Saklaw nito ang PostgreSQL, server, at worker nang magkakasama. Sa isang 2 GB na server, ang worker ang unang process na pinapatay ng kernel kapag kapos ang memory. Ang sintomas nito ay paghinto ng background task at outbound email habang gumagana pa rin ang login page. Maglaan ng 4 GB kung pinapagana rin ng parehong server ang mga app na pinoprotektahan mo.