Authentik Docker Compose सह self-hosted SSO कसे सेट करावे

तुम्ही होस्ट करत असलेल्या प्रत्येक अॅपसाठी एकच login

Authentik हा self-hosted SSO (single sign-on) सर्व्हर आहे. वापरकर्ते एकदाच sign in करतात. त्यानंतर त्यामागील प्रत्येक अॅप स्वतःचा password विचारण्याऐवजी तेच session स्वीकारते. Installation साठी अधिकृत Docker Compose file आणि तयार केलेली दोन secrets आवश्यक आहेत. त्यानंतरचा भाग अधिक विचारपूर्वक करावा लागतो: reverse proxy ने त्याकडे निर्देश करणे आणि आधीपासून असलेल्या एका अॅपला forward auth मागे ठेवणे.

त्या Compose file मध्ये Authentik तीन services म्हणून उपलब्ध होतो: PostgreSQL database, server process आणि worker process. Server container मध्ये embedded outpost देखील चालतो. प्रत्येक संरक्षित अॅपसाठी "ही request sign in केलेल्या वापरकर्त्याकडून आली आहे का?" याचे उत्तर देणारा हा component आहे. July 2026 पर्यंत Version 2026.5 ही current release आहे. Project नुसार host वर किमान 2 CPU cores आणि 2 GB RAM असावी. ही किमान मर्यादा समजा. सर्व्हर एक दिवस चालू राहिल्यानंतर PostgreSQL आणि worker दोन्ही memory वापरत राहतात.

तुम्ही सुरू करण्यापूर्वी आवश्यक गोष्टी

तुमच्याकडे Compose v2 plugin सह Docker Engine असणे आवश्यक आहे. हे docker compose version वापरून पडताळता येते. आवृत्तीऐवजी यामुळे error दिसत असल्यास, पुढे जाण्यापूर्वी plugin install करा. मूलभूत माहिती VPS वर Docker Compose सह अॅप्स चालवणे येथे दिली आहे. तसेच server कडे निर्देश करणारा DNS A record आवश्यक आहे. खालील उदाहरणांमध्ये तो auth.example.com आहे. Authentik browser ने वापरलेल्या hostname वरून redirect URLs तयार करते.

Stack root म्हणून नव्हे, तर docker group मधील सामान्य user म्हणून चालवा. या group चे membership host वरील root इतकेच अधिकार देते. त्यामुळे हा अधिकार एका deploy account ला द्या आणि इतर कोणालाही देऊ नका. यासाठी VPS वरील किमान-अधिकार असलेली user accounts या मार्गदर्शक तत्त्वांचा वापर करा.

अधिकृत Compose फाइलसह स्थापना करा

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

docker compose ps मध्ये तीन containers दिसले पाहिजेत. त्यापैकी postgresql मध्ये healthy आणि server दिसले पाहिजेत, तर worker मध्ये running दिसले पाहिजेत. पहिल्यांदा सुरू केल्यावर database migrations चालतात. त्यामुळे web interface प्रतिसाद देईपर्यंत एक मिनिट प्रतीक्षा करा.

निर्माण केलेल्या दोन्ही मूल्यांचे वेगवेगळ्या कारणांसाठी महत्त्व आहे. PG_PASS हा PostgreSQL password आहे आणि त्याची कमाल मर्यादा 99 characters आहे. AUTHENTIK_SECRET_KEY sessions आणि tokens वर स्वाक्षरी करते. त्यामुळे ते नंतर बदलल्यास सर्व users logout होतात आणि तुम्ही जारी केलेले सर्व API tokens अवैध ठरतात. .env ला mode 600 ठेवा आणि त्याची एक प्रत सुरक्षित ठिकाणी ठेवा. कारण संबंधित secret key शिवाय restore केलेल्या database मध्ये कोणीही login करू शकत नाही.

Compose file दोन्ही मूल्ये ${PG_PASS:?database password required} form वापरून वाचते. त्यामुळे file उपलब्ध नसल्यास Compose सुरू होण्यास नकार देते. चुकीच्या directory मधून docker compose up -d चालवल्यास required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required दिसते आणि प्रक्रिया थांबते. हा path चा प्रश्न आहे, config चा नाही.

महत्त्वाची environment values

इतर सर्व मूल्ये त्याच .env file मध्ये द्या. Authentik मध्ये double underscore हे nested configuration key दर्शवते. त्यामुळे AUTHENTIK_EMAIL__HOST हे email.host सेट करते. Single underscore कोणतीही warning न देता दुर्लक्षित केला जातो. Setting लागू होत नसल्याचे दिसण्याचे हे सर्वात सामान्य कारण आहे.

• पहिल्यांदा सुरू होताना AUTHENTIK_BOOTSTRAP_PASSWORD built-in akadmin user चा password सेट करते. त्यामुळे public web form मध्ये password टाइप करण्याची गरज राहत नाही. AUTHENTIK_BOOTSTRAP_EMAIL आणि AUTHENTIK_BOOTSTRAP_TOKEN त्याच प्रकारे त्या user चा address आणि API token सेट करतात.
• COMPOSE_PORT_HTTP आणि COMPOSE_PORT_HTTPS प्रकाशित ports चे default 9000 आणि 9443 वरून इतर values कडे स्थलांतर करतात.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS आणि AUTHENTIK_EMAIL__FROM outbound mail configure करतात. ही values नसल्यास Authentik port 25 वर localhost शी संपर्क करण्याचा प्रयत्न करते. त्यामुळे password-reset mails साठी worker log मध्ये connection error नोंदवला जातो.
• Login flow मध्ये समस्या येत असताना आवश्यक detail दाखवण्यासाठी AUTHENTIK_LOG_LEVEL=debug वापरा. नंतर ते पुन्हा info वर सेट करा.
• AUTHENTIK_ERROR_REPORTING__ENABLED ची default value false आहे. Crash reports upstream पाठवण्यास तुम्ही तयार असाल, तरच ते true वर सेट करा.

ही secrets plain file मध्ये आहेत. त्यामुळे या directory कडे इतर कोणत्याही credential store प्रमाणेच पाहा. Laptop वरील note पेक्षा self-hosted Vaultwarden instance सारखा password manager recovery copy ठेवण्यासाठी अधिक सुरक्षित पर्याय आहे.

पहिला login आणि admin account

ब्राउझरमध्ये http://SERVER_IP:9000 उघडा. Authentik त्याचा प्रारंभिक setup flow दाखवतो आणि default akadmin user साठी password सेट करण्यास सांगतो. तुम्ही AUTHENTIK_BOOTSTRAP_PASSWORD आधीच सेट केला असल्यास, ही पायरी पूर्ण झालेली असते आणि तुम्ही थेट login page वर जाता.

Directory आणि त्यानंतर Users मध्ये स्वतःसाठी एक सामान्य admin वापरकर्ता तयार करा. त्याला authentik Admins गटात जोडा आणि त्या खात्याने sign in करा. akadmin हे break-glass खाते म्हणून ठेवा आणि त्याचा दीर्घ password offline साठवा. सर्वांकडून वापरल्या जाणाऱ्या built-in खात्याखाली रोजचे काम केल्यास audit log निरुपयोगी होतो, कारण प्रत्येक event मध्ये akadmin असेच दिसते आणि तो event नेमका कोणी केला हे कळत नाही. हा मुद्दा Authentik नंतरच्या प्रणालींनाही लागू होतो. उदाहरणार्थ, प्रत्येक व्यक्तीसाठी स्वतंत्र agent देणारे self-hosted OneCLI harness वापरत असाल, तर त्यापर्यंत पोहोचणारी identity संपूर्ण टीमने सामायिक केलेल्या login ऐवजी एका व्यक्तीशी संबंधित असेल तेव्हाच वाचनीय trail तयार होतो.

Reverse proxy मागे Authentik ठेवणे

9000 पोर्ट इंटरनेटवर प्रकाशित केल्यास ते कार्य करते; परंतु तुम्हाला TLS (transport layer security) आणि वास्तविक hostname हवा आहे. तुम्ही आधीपासून अनेक Compose अॅप्ससाठी Traefik reverse proxy म्हणून ही रचना चालवत असल्यास, override file वापरून Authentik ला त्याच external proxy network शी जोडा. compose.yml च्या शेजारी docker-compose.override.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

docker compose up -d वापरून ते लागू करा. Compose override आपोआप merge करते. त्यामुळे server service मध्ये official file मधील सर्व configuration कायम राहते आणि labels जोडले जातात. curl -I https://auth.example.com/if/user/ वापरून तपासा; त्यातून HTTP/2 200 चे उत्तर मिळाले पाहिजे. Traefik कडून 404 page not found मिळाल्यास container proxy network वर नाही. Traefik ज्या container पर्यंत पोहोचू शकत नाही त्याकडे traffic पाठवू शकत नाही.

Hostname कार्य करू लागल्यानंतर override मध्ये प्रकाशित ports 127.0.0.1 शी bind करा. त्यामुळे प्रवेशाचा एकमेव मार्ग proxy मधून राहील.

forward auth वापरून एका अॅपचे संरक्षण

Authentik च्या proxy provider मध्ये तीन modes आहेत. चुकीचा mode निवडल्यास एक तास वाया जाऊ शकतो. Proxy म्हणजे outpost स्वतः upstream app कडे traffic forward करतो. Forward auth (single application) मध्ये तुमचा reverse proxy traffic पुढे पाठवत राहतो आणि request मध्ये sign-in झाले आहे का, एवढेच Authentik ला विचारतो. Forward auth (domain level) एकाच provider द्वारे एका parent domain अंतर्गत असलेल्या प्रत्येक app चे संरक्षण करते. मात्र त्यासाठी प्रत्येक app साठी स्वतंत्र authorization rules ठेवता येत नाहीत. समोर Traefik असल्यास forward auth (single application) निवडा. प्रत्यक्ष सरावासाठी एखादा app हवा असल्यास self-hosted AFFiNE workspace हा चांगला पहिला उमेदवार आहे. तुमच्या स्वतःच्या devices वरून उपलब्ध असावा, पण इतर कोठूनही उपलब्ध नसावा, अशा internal tool साठी तो योग्य आहे. Team tool असल्यास हा उपयोग आणखी स्पष्ट होतो: self-hosted Chatwoot support desk त्याच provider मागे ठेवा. त्यामुळे inbox ला उत्तर देणारा प्रत्येक जण दिवसातून एकदा sign in करेल आणि आणखी एक password सर्वांमध्ये share करावा लागणार नाही.

Web interface मध्ये Applications आणि नंतर Providers उघडा. Proxy Provider तयार करा, forward auth single application mode निवडा आणि external host म्हणून https://app.example.com सेट करा. त्या provider कडे निर्देश करणारे Application तयार करा. त्यानंतर Outposts उघडा, authentik Embedded Outpost संपादित करा आणि नवीन application त्याच्या selected applications मध्ये हलवा. Outpost ला दिलेल्या applications साठीच तो प्रतिसाद देतो. त्यामुळे ही शेवटची पायरी वगळल्यास provider योग्यरीत्या configured असूनही कोणताही प्रतिसाद मिळत नाही.

Middleware एकदाच Authentik container वर define करा आणि प्रत्येक protected app मधून त्याचा reference द्या:

      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

authResponseHeaders ही headers ची list आहे. Traefik Authentik च्या उत्तरातून या headers घेऊन upstream कडे पाठवलेल्या request मध्ये जोडतो. ही list वगळल्यास app चे संरक्षण राहते, पण user कोण आहे हे app ला कळत नाही. त्यामुळे automatic login साठी X-authentik-username वाचणारे कोणतेही feature logged out राहते.

Protected app साठी एकाऐवजी दोन routers आवश्यक आहेत:

    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

दुसरा router बहुतेक जण वगळतात. Sign-in नंतर Authentik browser ला /outpost.goauthentik.io/ अंतर्गत असलेल्या path वर परत पाठवतो. हा path app च्या hostname वर असतो, auth.example.com वर नाही. हा path prefix Authentik service कडे पाठवणारा router नसल्यास request तुमच्या app कडे जाते. App 404 देते आणि login पूर्ण होत नाही. जास्त priority मुळे त्याच domain वरील साध्या Host() rule पेक्षा विशिष्ट path rule प्राधान्याने लागू होतो.

Private browser window मध्ये चाचणी करा. तुम्हाला auth.example.com कडे पाठवले गेले पाहिजे. Sign in केल्यानंतर तुम्ही app वर परत याल. Authentik च्या बाजूवरील docker compose logs -f server प्रत्येक प्रयत्नासाठी authorization event दाखवते. त्यामुळे request Authentik पर्यंत पोहोचली की नाही हे समजते.

तुम्हाला प्रत्यक्षात येणाऱ्या त्रुटी

अॅप आणि login page यांच्यात endless redirect loop. Provider वरील external host आणि browser वापरत असलेला host जुळत नाही. सामान्यतः provider मधील http:// आणि address bar मधील https:// वेगळे असतात. त्यामुळे session cookie वेगळ्या origin साठी सेट होते आणि प्रत्येक परतफेरी नवीन anonymous request म्हणून दिसते. External host दुरुस्त करा आणि पुन्हा चाचणी करण्यापूर्वी दोन्ही domains साठीच्या cookies काढून टाका.

/outpost.goauthentik.io/start येथे 404. Outpost router उपलब्ध नाही किंवा त्या host साठीच्या catch-all router पेक्षा त्याची priority कमी आहे.

Login साठी विचारणा न करताच app उघडते. middlewares label अशा middleware चे नाव दर्शवते जे अस्तित्वात नाही. Traefik याबाबत warning देत नाही. त्यामुळे authentik@docker मधील typo असल्यास कोणतेही middleware चालत नाही. Traefik dashboard उघडा आणि router मध्ये middleware सूचीबद्ध आहे का ते तपासा.

यशस्वी login नंतर Authentik कडून 403. User authenticated आहे, पण authorized नाही. Application ला policy binding किंवा group requirement लागू आहे आणि हा user ती अट पूर्ण करत नाही. Admin interface मधील Events log ने कोणत्या policy ने access नाकारला ते दाखवते.

Keycloak अधिक योग्य ठरण्याची परिस्थिती

Keycloak हा Red Hat च्या पाठबळावर विकसित झालेला जुना प्रकल्प आहे. पारंपरिक enterprise identity कामांसाठी तो अधिक सक्षम पर्याय आहे. यामध्ये मोठ्या प्रमाणावर SAML federation, एकाच वेळी अनेक बाह्य identity providers कडून login requests चे brokering आणि दस्तऐवजीकृत migration path म्हणून realm export आणि import यांचा समावेश होतो. काही organisations साठी त्यामागील commercial support हा औपचारिकदृष्ट्या महत्त्वाचा घटक असतो. बदल्यात, Keycloak मध्ये स्वतःचा proxy नाही. त्यामुळे OIDC (OpenID Connect) न वापरणाऱ्या अॅपचे संरक्षण करण्यासाठी त्याच्या बाजूला oauth2-proxy सारखे साधन चालवावे लागते. Authentik मधील built-in proxy provider हीच सुविधा आधीपासून integrated स्वरूपात देते. म्हणून विविध प्रकारची अॅप्स चालवणारे बहुतेक self-hosters शेवटी Authentik निवडतात.

बॅकअप आणि अपग्रेड

Restore करण्यासाठी तीन गोष्टी आवश्यक आहेत: PostgreSQL database, ./data directory आणि .env.

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

तो dump आणि .env एकत्र साठवा. फक्त dump पुरेसा नाही, कारण session आणि token data चे संरक्षण करणारी secret key .env मध्ये असते.

Upgrades म्हणजे tag बदलणे. तुम्हाला हवी असलेली release .env मधील AUTHENTIK_TAG मध्ये सेट करा. त्यानंतर docker compose pull आणि मग docker compose up -d चालवा. आधी release notes वाचा, कारण Authentik date-based versions वापरते आणि काही releases मध्ये अशा migrations असतात ज्यांसाठी आधीच्या release पासून upgrade करणे आवश्यक असते. Pull करण्यापूर्वी database dump घ्या; pull केल्यानंतर नाही.

FAQ

Authentik स्वयं host करणे विनामूल्य आहे का?

Open source edition विनामूल्य आहे आणि वर नमूद केलेल्या सर्व सुविधा देते: proxy provider, forward auth, OIDC (OpenID Connect), SAML आणि flows engine. सशुल्क enterprise tier मध्ये support आणि काही enterprise features मिळतात; परंतु येथे दिलेल्या कोणत्याही गोष्टीसाठी licence आवश्यक नाही.

Authentik वापरण्यासाठी Traefik आवश्यक आहे का?

नाही. auth_request द्वारे nginx सोबत आणि forward_auth द्वारे Caddy सोबत forward auth कार्य करते. प्रत्येक प्रकरणात रचना समान असते: reverse proxy प्रत्येक request विषयी Authentik कडे विचारणा करतो आणि protected hostname वरील /outpost.goauthentik.io/ path prefix ने app ऐवजी Authentik कडे route केले पाहिजे.

माझे protected app login आणि error यांच्यामध्ये सतत का फिरत राहते?

Proxy provider मध्ये configure केलेला external host browser वापरत असलेल्या URL शी जुळत नाही. सर्वाधिक सामान्यतः http आणि https यांच्यात जुळणी नसते. Session cookie एका origin साठी issue होते आणि दुसऱ्या origin वर read केली जाते. त्यामुळे Authentik ला प्रत्येक वेळी anonymous request दिसते. External host दुरुस्त करा. त्यानंतर पुन्हा चाचणी करण्यापूर्वी दोन्ही hostnames साठी cookies clear करा.

Authentik ला किती RAM आवश्यक आहे?

July 2026 पर्यंत documented minimum 2 CPU cores आणि 2 GB RAM आहे. यात PostgreSQL, server आणि worker यांचा एकत्रित समावेश होतो. 2 GB असलेल्या मशीनवर memory pressure आल्यास kernel सर्वप्रथम worker process बंद करते. यामुळे login page कार्यरत राहते, परंतु background tasks आणि outbound email थांबतात. त्याच server वर protected apps देखील चालत असल्यास Authentik ला 4 GB RAM द्या.