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

प्रत्येक अॅपसाठी एकच लॉगिन

Authentik हे एक self-hosted SSO (single sign-on) सर्व्हर आहे: तुमचे वापरकर्ते एकदाच साइन इन करतात आणि त्यामागील प्रत्येक अॅप स्वतःचा पासवर्ड विचारण्याऐवजी ते सत्र स्वीकारते. याचे इंस्टॉलेशन अधिकृत Docker Compose फाईल आणि दोन जनरेट केलेल्या सीक्रेट्सद्वारे होते. यानंतरचा खरा महत्त्वाचा भाग म्हणजे, त्याकडे reverse proxy निर्देशित करणे आणि एका अस्तित्वात असलेल्या अॅपला forward auth च्या मागे ठेवणे.

Authentik त्या Compose फाईलमध्ये तीन सेवा म्हणून उपलब्ध आहे: एक PostgreSQL डेटाबेस, एक server प्रक्रिया आणि एक worker प्रक्रिया. सर्व्हर कंटेनरमध्ये एम्बेड केलेले outpost देखील चालते, जे प्रत्येक संरक्षित अॅपसाठी "ही विनंती साइन इन केलेली आहे का?" या प्रश्नाचे उत्तर देते. 25 ऑक्टोबर 2026 पर्यंत, आवृत्ती 2026.8.5 ही सध्याची रिलीज आहे. ती 21 ऑक्टोबर 2026 रोजी 2026.8 मालिकेतील नवीनतम पॅच म्हणून प्रकाशित झाली, ज्याची सुरुवात 18 ऑगस्ट रोजी 2026.8.0 ने झाली होती. अधिकृत Compose फाईलमध्ये ती 14 ऑक्टोबरच्या 2026.8.4 ची जागा घेते. या प्रकल्पासाठी किमान 2 CPU कोअर्स आणि 2 GB RAM असलेला होस्ट आवश्यक आहे. हे किमान प्रमाण समजा. सर्व्हर एक दिवस चालू राहिल्यानंतर PostgreSQL आणि वर्कर दोन्ही मेमरी वापरतात.

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

तुमच्याकडे 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 ने तीनही कंटेनर चालू असल्याचे दर्शवले पाहिजे आणि postgresql ने तपासणी पूर्ण झाल्यावर healthy रिपोर्ट केले पाहिजे. पहिल्यांदा सुरू करताना डेटाबेस मायग्रेशन चालते, त्यामुळे वेब इंटरफेस प्रतिसाद देण्यापूर्वी एक मिनिट थांबा.

दोन्ही जनरेट केलेली मूल्ये वेगवेगळ्या कारणांसाठी महत्त्वाची आहेत. PG_PASS हा PostgreSQL पासवर्ड आहे. Authentik च्या इंस्टॉलेशन डॉक्युमेंटेशननुसार 99 पेक्षा जास्त लांबीचे पासवर्ड समर्थित नाहीत, त्यामुळे तुम्ही निवडलेला पासवर्ड त्या मर्यादेत ठेवा; जनरेट केलेला पासवर्ड त्यापेक्षा खूपच लहान आहे. AUTHENTIK_SECRET_KEY ही ती की (key) आहे जी Authentik कुकीज साइन करण्यासाठी वापरते. कॉन्फिगरेशन डॉक्युमेंटेशननुसार ती बदलल्यास सक्रिय सत्रे अवैध ठरतात, त्यामुळे नवीन की वापरल्यास सर्व साइन-इन केलेले वापरकर्ते लॉग आउट होतील. .env ला 600 मोडवर ठेवा आणि त्याची एक प्रत तुमच्या बॅकअपसह सुरक्षित ठिकाणी ठेवा, जेणेकरून रिस्टोर करताना तीच की वापरता येईल.

Compose फाईलमध्ये दोन्ही मूल्ये ${VAR:?message} फॉरमॅट वापरून आवश्यक म्हणून चिन्हांकित केली आहेत: PostgreSQL सेवेवर ${PG_PASS:?database password required} आणि सर्व्हर व वर्करवर ${AUTHENTIK_SECRET_KEY:?secret key required}. याचा अर्थ फाईल गहाळ असल्यास Compose सुरू होण्यास नकार देते. चुकीच्या डिरेक्टरीमधून docker compose up -d चालवल्यास required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required सारखी ओळ प्रिंट होते आणि प्रक्रिया थांबते. हा संदेश पाथशी संबंधित समस्या आहे, कॉन्फिगरेशनची नाही.

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

उर्वरित सर्व values त्याच .env file मध्ये द्या. Authentik double underscore ला nested configuration key शी जोडते, त्यामुळे AUTHENTIK_EMAIL__HOST मुळे email.host सेट होते. Single underscore nested key शी जोडला जात नाही. एखादी 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 चे defaults 9000 आणि 9443 ऐवजी वेगळे करता येतात.
• 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 मूल्य false आहे. Crash reports upstream पाठवण्यास आपण सहमत असाल, तरच ते true वर सेट करा.

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

पहिले लॉगिन आणि ॲडमिन खाते

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

Directory आणि त्यानंतर Users मध्ये स्वतःसाठी एक सामान्य ॲडमिन वापरकर्ता तयार करा, त्याला authentik Admins ग्रुपमध्ये जोडा आणि त्या खात्यासह साइन इन करा. akadmin ला ब्रेक-ग्लास खाते म्हणून ठेवा आणि त्याचा लांब पासवर्ड ऑफलाइन साठवा. जर एखादा बिघडलेला फ्लो किंवा स्टेज तुम्हाला लॉक करत असेल, तर docker compose run --rm server create_recovery_key 10 akadmin, जे /opt/authentik वरून चालवले जाते, एक लिंक प्रिंट करते जी तुम्हाला थेट akadmin म्हणून साइन इन करते. ज्याच्याकडे ती लिंक आहे त्याला समान प्रवेश मिळतो, त्यामुळे ती पासवर्डप्रमाणेच सुरक्षित ठेवा. दररोजचे काम इन-बिल्ट खात्यावरून केल्यास ऑडिट लॉग खराब होतो, कारण प्रत्येक इव्हेंटमध्ये akadmin दिसते आणि कोणी काम केले हे समजत नाही. हा तर्क Authentik च्या पुढील सेवांनाही लागू होतो: उदा. प्रत्येक व्यक्तीला स्वतःचा एजंट देणारे self-hosted OneCLI harness तेव्हाच वाचनीय ट्रेल सोडते जेव्हा तिथे पोहोचणारी ओळख संपूर्ण टीमच्या सामायिक लॉगिनऐवजी एका व्यक्तीची असते.

तुमच्या reverse proxy मागे Authentik ठेवा

इंटरनेटवर port 9000 प्रकाशित केल्यास ते कार्य करते; परंतु तुम्हाला TLS (transport layer security) आणि प्रत्यक्ष hostname हवा आहे. तुम्ही एकाधिक Compose अॅप्ससाठी reverse proxy म्हणून Traefik ची रचना आधीच चालवत असल्यास, override file वापरून Authentik ला त्याच बाह्य 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 मिळत असल्यास, request शी जुळणारा कोणताही router सापडलेला नाही. Labels container पर्यंत पोहोचले आहेत का, Host() rule hostname शी अचूक जुळतो का आणि router ऐकत असलेल्या HTTPS entry point वर request आली का ते तपासा.

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

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

Authentik च्या proxy provider मध्ये तीन modes आहेत. चुकीचा mode निवडल्यास troubleshooting मध्ये एक तास जाऊ शकतो. Proxy mode मध्ये outpost स्वतः upstream app कडे traffic forward करतो. Forward auth (single application) mode मध्ये तुमचा reverse proxy traffic forward करतो आणि request मध्ये sign-in झाले आहे का, एवढेच Authentik कडून तपासतो. Forward auth (domain level) mode मध्ये एकाच 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-entitlements,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 मध्ये जोडतो. ती वगळल्यास app चे संरक्षण होते; परंतु user कोण आहे हे app ला कळत नाही. त्यामुळे automatic login साठी X-authentik-username वाचणारे कोणतेही feature logged out राहते. स्वतःचे sign-in राखणाऱ्या app समोर ही त्रुटी विशेषतः स्पष्ट दिसते. उदाहरणार्थ, self-hosted openGym workout tracker आणि त्याच्या passkey login मध्ये headers मुळे त्याच page साठी दोन prompts ऐवजी एकच prompt दिसतो.

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 पेक्षा specific 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, एकाच वेळी अनेक external identity providers कडून login requests चे brokering, तसेच दस्तऐवजीकृत migration path म्हणून realm export आणि import यांचा समावेश होतो. काही organisations साठी त्यामागील commercial support कागदोपत्री महत्त्वाचा ठरतो. मात्र यासाठी Keycloak कडे स्वतःचा proxy नाही. त्यामुळे OIDC (OpenID Connect) किंवा SAML पैकी कोणताही protocol न बोलणाऱ्या अॅपचे संरक्षण करण्यासाठी त्याच्या बाजूला oauth2-proxy सारखे साधन चालवावे लागते. Authentik मधील built-in proxy provider हीच भूमिका बजावतो आणि तो आधीपासून integrated आहे. त्यामुळे विविध प्रकारच्या अॅप्सचा संच चालवणारे बहुतेक self-hosters शेवटी Authentik निवडतात.

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

तीन गोष्टींमुळे रिस्टोर शक्य होते: PostgreSQL डेटाबेस, ./data डिरेक्टरी आणि .env.

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

तो डंप आणि .env एकत्र साठवा. डंपमध्ये AUTHENTIK_SECRET_KEY ची प्रत नसते आणि वेगळ्या की अंतर्गत रिस्टोर केल्यास सर्व सक्रिय सत्रे अवैध ठरतात, त्यामुळे मूळ की ठेवल्यास रिस्टोर केलेला सर्व्हर पूर्वीप्रमाणेच काम करतो.

अपग्रेड म्हणजे टॅग बदलणे. .env मधील AUTHENTIK_TAG ला तुम्हाला हव्या असलेल्या रिलीजवर सेट करा, त्यानंतर docker compose pull आणि त्यानंतर docker compose up -d चालवा. जर तुम्ही कधीही AUTHENTIK_TAG सेट केले नसेल, तर आवृत्ती compose.yml मध्ये लिहिलेल्या डीफॉल्टवरून येते, त्यामुळे त्या फाईलची नवीन प्रत डाउनलोड करणे म्हणजे अपग्रेड होय आणि अधिकृत अपग्रेड डॉक्युमेंटेशनमध्ये तोच मार्ग सांगितला आहे. आधी रिलीज नोट्स वाचा. Authentik तारखेवर आधारित आवृत्त्या वापरते आणि ऑक्टोबर 2026 पर्यंतच्या डॉक्युमेंटेशननुसार, अपग्रेड्स मुख्य रिलीजच्या क्रमानेच केले पाहिजेत: तुम्ही वापरत असलेल्या मालिकेतील नवीनतम पॅचवर जा, त्यानंतर कोणतीही मालिका न वगळता क्रमाने पुढील मालिकांवर जा. Authentik डाउनग्रेडिंगला समर्थन देत नाही, त्यामुळे पुल करण्यापूर्वी डेटाबेस डंप घ्या, नंतर नाही.

FAQ

Authentik स्वतः host करण्यासाठी मोफत आहे का?

Open source edition मोफत आहे आणि वर नमूद केलेल्या सर्व सुविधा देते: proxy provider, forward auth, OIDC (OpenID Connect), SAML आणि flows engine. Paid 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 Authentik कडे route झाला पाहिजे, app कडे नाही.

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

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

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

October 2026 नुसार documented minimum 2 CPU cores आणि 2 GB RAM आहे. यात PostgreSQL, server आणि worker या तिन्हींचा समावेश होतो. 2 GB च्या मशीनवर memory pressure मुळे kernel चा OOM killer सक्रिय होऊ शकतो. तो सर्वाधिक badness score असलेली process बंद करतो. हा score साधारणपणे process वापरत असलेल्या allowed memory च्या वाट्याइतका असतो आणि त्यात तिचा oom_score_adj देखील समाविष्ट असतो. Worker बंद होत असल्यास background tasks आणि outbound email थांबतात, परंतु login page कार्यरत राहते. त्याच server वर protected apps देखील चालत असतील, तर Authentik साठी 4 GB RAM द्या.