Authentik को Docker Compose पर सेटअप कैसे करें

आपके द्वारा होस्ट किए जाने वाले प्रत्येक ऐप के लिए एक लॉगिन

Authentik एक सेल्फ-होस्टेड SSO (सिंगल साइन-ऑन) सर्वर है: आपके उपयोगकर्ता एक बार साइन इन करते हैं, और इसके पीछे का प्रत्येक ऐप अपना पासवर्ड मांगने के बजाय उस सत्र (session) को स्वीकार कर लेता है। इसका इंस्टॉलेशन एक आधिकारिक Docker Compose फ़ाइल और दो जनरेट किए गए सीक्रेट्स के माध्यम से होता है। असली काम इसके बाद आता है: इसकी ओर एक रिवर्स प्रॉक्सी पॉइंट करना, और एक मौजूदा ऐप को फॉरवर्ड ऑथ (forward auth) के पीछे रखना।

Authentik उस Compose फ़ाइल में तीन सेवाओं के रूप में आता है: एक PostgreSQL डेटाबेस, एक server प्रोसेस, और एक worker प्रोसेस। सर्वर कंटेनर एम्बेडेड आउटपोस्ट को भी चलाता है, जो वह घटक है जो प्रत्येक सुरक्षित ऐप के लिए "क्या यह अनुरोध साइन इन है?" का उत्तर देता है। जुलाई 2026 तक संस्करण 2026.5 वर्तमान रिलीज़ है, और प्रोजेक्ट के लिए कम से कम 2 CPU कोर और 2 GB RAM वाले होस्ट की आवश्यकता है। इसे न्यूनतम आवश्यकता मानें। एक दिन तक चलने के बाद PostgreSQL और वर्कर दोनों मेमोरी का उपयोग करते हैं।

शुरू करने से पहले आपको क्या चाहिए

आपको Docker Engine के साथ Compose v2 प्लगइन की आवश्यकता है, जिसकी पुष्टि आप docker compose version से कर सकते हैं। यदि यह कमांड वर्ज़न के बजाय कोई त्रुटि दिखाती है, तो आगे बढ़ने से पहले प्लगइन इंस्टॉल करें; इसकी बुनियादी जानकारी running apps with Docker Compose on a VPS में दी गई है। आपको एक DNS A रिकॉर्ड की भी आवश्यकता है जो सर्वर की ओर इशारा करता हो, जिसे नीचे दिए गए उदाहरणों में auth.example.com कहा गया है, क्योंकि Authentik अपने रीडायरेक्ट URL उसी होस्टनेम से बनाता है जिसका उपयोग ब्राउज़र ने किया है।

स्टैक को root के बजाय docker समूह के एक सामान्य उपयोगकर्ता के रूप में चलाएं। इस समूह की सदस्यता होस्ट पर root के बराबर होती है, इसलिए इसे केवल एक डिप्लॉय अकाउंट को दें और किसी अन्य को नहीं, जैसा कि least-privilege user accounts on a VPS में बताया गया है।

आधिकारिक 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 और server और worker में running चल रहा है। पहली बार शुरू करने पर डेटाबेस माइग्रेशन चलता है, इसलिए वेब इंटरफ़ेस के उत्तर देने से पहले इसे एक मिनट का समय दें।

दोनों जनरेट किए गए मान अलग-अलग कारणों से महत्वपूर्ण हैं। PG_PASS PostgreSQL पासवर्ड है, और इसकी अधिकतम सीमा 99 वर्णों की है। AUTHENTIK_SECRET_KEY सत्रों और टोकन को साइन करता है, इसलिए इसे बाद में बदलने से प्रत्येक उपयोगकर्ता लॉग आउट हो जाएगा और आपके द्वारा जारी किया गया प्रत्येक API टोकन अमान्य हो जाएगा। .env को मोड 600 पर रखें और इसकी एक प्रति सुरक्षित स्थान पर रखें, क्योंकि बिना अपनी मेल खाती सीक्रेट की के रिस्टोर किया गया डेटाबेस ऐसा डेटाबेस होता है जिसमें कोई भी लॉग इन नहीं कर सकता।

Compose फ़ाइल दोनों मानों को ${PG_PASS:?database password required} फ़ॉर्म के साथ पढ़ती है, जिसका अर्थ है कि फ़ाइल गायब होने पर Compose शुरू होने से इनकार कर देता है। गलत डायरेक्टरी से docker compose up -d चलाने पर required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required प्रिंट होता है और प्रक्रिया रुक जाती है। वह संदेश एक पाथ संबंधी समस्या है, कॉन्फ़िगरेशन संबंधी समस्या नहीं।

महत्वपूर्ण एनवायरनमेंट वैल्यूज़

बाकी सब कुछ उसी .env फ़ाइल में जाता है। Authentik एक डबल अंडरस्कोर को नेस्टेड कॉन्फ़िगरेशन की (key) के रूप में मैप करता है, इसलिए AUTHENTIK_EMAIL__HOST से email.host सेट होता है। एक सिंगल अंडरस्कोर को बिना किसी चेतावनी के अनदेखा कर दिया जाता है, जो सबसे आम कारण है कि कोई सेटिंग काम नहीं करती है।

• AUTHENTIK_BOOTSTRAP_PASSWORD पहली बार शुरू होने पर इन-बिल्ट akadmin यूज़र का पासवर्ड सेट करता है, ताकि आपको इसे कभी भी पब्लिक वेब फ़ॉर्म में टाइप न करना पड़े। AUTHENTIK_BOOTSTRAP_EMAIL और AUTHENTIK_BOOTSTRAP_TOKEN उसी तरह उस यूज़र का ईमेल पता और एक API टोकन सेट करते हैं।
• COMPOSE_PORT_HTTP और COMPOSE_PORT_HTTPS पब्लिश्ड पोर्ट्स को डिफ़ॉल्ट 9000 और 9443 से हटाकर दूसरी जगह ले जाते हैं।
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS और AUTHENTIK_EMAIL__FROM आउटबाउंड मेल को कॉन्फ़िगर करते हैं। इनके बिना Authentik पोर्ट 25 पर localhost का प्रयास करता है, इसलिए पासवर्ड-रीसेट मेल वर्कर लॉग में कनेक्शन एरर के रूप में दिखाई देते हैं।
• AUTHENTIK_LOG_LEVEL=debug लॉगिन फ़्लो के गलत व्यवहार करने पर आवश्यक विवरण को चालू करता है। बाद में इसे वापस info पर सेट कर दें।
• AUTHENTIK_ERROR_REPORTING__ENABLED डिफ़ॉल्ट रूप से false होता है। इसे केवल तभी true पर सेट करें यदि आप अपस्ट्रीम क्रैश रिपोर्ट भेजने के लिए सहमत हैं।

ये एक प्लेन फ़ाइल में मौजूद सीक्रेट्स हैं, इसलिए इस डायरेक्टरी को वैसे ही सुरक्षित रखें जैसे आप किसी अन्य क्रेडेंशियल स्टोर को रखते हैं। अपने लैपटॉप पर किसी नोट के बजाय, सेल्फ़-होस्टेड Vaultwarden इंस्टेंस जैसा पासवर्ड मैनेजर रिकवरी कॉपी के लिए एक बेहतर जगह है।

पहला लॉगिन और एडमिन अकाउंट

अपने ब्राउज़र में http://SERVER_IP:9000 खोलें। Authentik अपना प्रारंभिक सेटअप फ्लो दिखाता है और आपसे डिफ़ॉल्ट akadmin यूज़र के लिए पासवर्ड सेट करने को कहता है। यदि आपने पहले ही AUTHENTIK_BOOTSTRAP_PASSWORD सेट कर लिया है, तो वह चरण पूरा हो चुका है और आप सीधे लॉगिन पेज पर पहुँच जाएंगे।

Directory और फिर Users के अंतर्गत अपने लिए एक सामान्य एडमिन यूज़र बनाएं, उसे authentik Admins ग्रुप में जोड़ें, और उस अकाउंट से साइन इन करें। akadmin को एक ब्रेक-ग्लास अकाउंट के रूप में छोड़ दें, जिसका लंबा पासवर्ड ऑफ़लाइन सुरक्षित रखा गया हो। साझा इन-बिल्ट अकाउंट के तहत दैनिक कार्य करने से ऑडिट लॉग खराब हो जाता है, क्योंकि प्रत्येक इवेंट में akadmin दिखाई देता है और यह पता नहीं चलता कि वह कार्य किसने किया है।

Authentik को अपने रिवर्स प्रॉक्सी के पीछे रखें

पोर्ट 9000 को इंटरनेट पर पब्लिश करना काम करता है, लेकिन आपको TLS (transport layer security) और एक वास्तविक होस्टनेम की आवश्यकता है। यदि आप पहले से ही Traefik as a reverse proxy for multiple Compose apps से सेटअप चला रहे हैं, तो एक ओवरराइड फ़ाइल के साथ Authentik को उसी बाहरी proxy नेटवर्क से जोड़ें। 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 स्वचालित रूप से ओवरराइड को मर्ज कर देता है, इसलिए server सर्विस आधिकारिक फ़ाइल से सब कुछ बरकरार रखती है और लेबल प्राप्त कर लेती है। curl -I https://auth.example.com/if/user/ के साथ जाँच करें, जिसे HTTP/2 200 का उत्तर देना चाहिए। Traefik से 404 page not found का मतलब है कि कंटेनर proxy नेटवर्क पर नहीं है, और Traefik उस कंटेनर तक रूट नहीं कर सकता जिस तक वह पहुँच नहीं सकता।

एक बार होस्टनेम काम करने के बाद, पब्लिश किए गए पोर्ट्स को ओवरराइड में 127.0.0.1 पर बाइंड करें, ताकि अंदर आने का एकमात्र रास्ता प्रॉक्सी के माध्यम से ही हो।

Forward auth के साथ एक ऐप को सुरक्षित करना

Authentik के proxy provider में तीन मोड होते हैं, और गलत मोड चुनने पर आपका एक घंटा बर्बाद हो सकता है। Proxy का अर्थ है कि outpost स्वयं upstream ऐप को ट्रैफ़िक भेजता है। Forward auth (single application) का अर्थ है कि आपका अपना reverse proxy अभी भी ट्रैफ़िक को संभालता है और केवल Authentik से पूछता है कि क्या अनुरोध (request) साइन-इन है। Forward auth (domain level) एक ही provider के साथ एक पैरेंट डोमेन के अंतर्गत आने वाले प्रत्येक ऐप को सुरक्षित करता है, लेकिन इसमें प्रति-एप्लिकेशन ऑथराइजेशन नियमों की कमी होती है। Traefik के साथ, आप forward auth (single application) का उपयोग करना चाहेंगे।

वेब इंटरफ़ेस में, Applications और फिर Providers खोलें, एक Proxy Provider बनाएं, forward auth single application मोड चुनें, और external host को https://app.example.com पर सेट करें। एक Application बनाएं जो उस provider की ओर इशारा करे। फिर Outposts खोलें, authentik Embedded Outpost को एडिट करें, और नए एप्लिकेशन को उसके selected applications में ले जाएं। outpost केवल उन एप्लिकेशनों के लिए उत्तर देता है जो उसे दिए गए हैं, इसलिए उस अंतिम चरण को छोड़ देने के कारण ही सही ढंग से कॉन्फ़िगर किया गया provider भी कोई परिणाम नहीं देता है।

Middleware को एक बार Authentik कंटेनर पर परिभाषित करें, और प्रत्येक सुरक्षित ऐप से इसे रेफरेंस करें:

      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 उन हेडर्स की सूची है जिन्हें Traefik, Authentik के उत्तर से कॉपी करके उस अनुरोध पर लगाता है जिसे वह upstream भेजता है। यदि आप इसे छोड़ देते हैं, तो ऐप अभी भी सुरक्षित रहेगा, लेकिन उसे यह कभी पता नहीं चलेगा कि उपयोगकर्ता कौन है, इसलिए जो कुछ भी स्वचालित लॉगिन के लिए X-authentik-username को पढ़ता है, वह लॉग-आउट ही रहेगा।

स्वयं सुरक्षित ऐप को एक नहीं, बल्कि दो 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 वह हिस्सा है जिसे हर कोई छोड़ देता है। साइन-इन के बाद, Authentik ब्राउज़र को ऐप के होस्टनेम पर /outpost.goauthentik.io/ के अंतर्गत एक पाथ पर वापस भेजता है, न कि auth.example.com पर। यदि कोई router उस पाथ प्रीफिक्स को Authentik सर्विस पर नहीं भेजता है, तो अनुरोध आपके ऐप पर पहुंच जाता है, जो 404 उत्तर देता है, और लॉगिन कभी पूरा नहीं होता है। उच्च priority ही वह कारण है जिससे एक ही डोमेन पर विशिष्ट पाथ नियम, सामान्य Host() नियम पर प्रभावी होता है।

इसे एक प्राइवेट ब्राउज़र विंडो में टेस्ट करें। आपको auth.example.com पर भेजा जाना चाहिए, साइन इन करना चाहिए, और वापस ऐप पर आना चाहिए। Authentik साइड पर docker compose logs -f server प्रत्येक प्रयास के लिए एक ऑथराइजेशन इवेंट प्रिंट करता है, जो आपको बताता है कि क्या अनुरोध Authentik तक पहुंचा भी है या नहीं।

जिन विफलताओं का आप वास्तव में सामना करेंगे

ऐप और लॉगिन पेज के बीच अंतहीन रीडायरेक्ट लूप। प्रदाता पर बाहरी होस्ट ब्राउज़र द्वारा उपयोग किए जाने वाले होस्ट से मेल नहीं खाता है, आमतौर पर प्रदाता में http:// और एड्रेस बार में https:// होता है। सत्र कुकी (session cookie) तब एक अलग ओरिजिन के लिए सेट हो जाती है, इसलिए हर बार वापस आने पर यह एक नया अनाम अनुरोध (anonymous request) दिखाई देता है। बाहरी होस्ट को ठीक करें और पुनः परीक्षण करने से पहले दोनों डोमेन के लिए कुकीज़ साफ़ करें।

/outpost.goauthentik.io/start पर 404 त्रुटि। आउटपोस्ट राउटर गायब है, या उस होस्ट के लिए कैच-ऑल राउटर की तुलना में इसकी प्राथमिकता कम है।

ऐप बिना लॉगिन मांगे लोड हो जाता है। middlewares लेबल एक ऐसे मिडलवेयर का नाम बताता है जो मौजूद नहीं है। Traefik इसके बारे में चेतावनी नहीं देता है, इसलिए authentik@docker में टाइपिंग की गलती का मतलब है कि कोई मिडलवेयर नहीं चल रहा है। Traefik डैशबोर्ड खोलें और पुष्टि करें कि राउटर में मिडलवेयर सूचीबद्ध है।

सफल लॉगिन के बाद Authentik से 403 त्रुटि। उपयोगकर्ता प्रमाणित है लेकिन अधिकृत नहीं है: एप्लिकेशन में एक पॉलिसी बाइंडिंग, या समूह की आवश्यकता है, जिसे यह उपयोगकर्ता पूरा नहीं करता है। एडमिन इंटरफ़ेस में इवेंट्स लॉग उस पॉलिसी का नाम बताता है जिसने इसे अस्वीकार कर दिया।

Keycloak कब बेहतर विकल्प है

Keycloak एक पुराना प्रोजेक्ट है, जिसे Red Hat का समर्थन प्राप्त है। यह क्लासिक एंटरप्राइज आइडेंटिटी कार्यों के लिए एक मजबूत विकल्प है: जैसे कि व्यापक SAML फेडरेशन, एक साथ कई बाहरी आइडेंटिटी प्रोवाइडर्स से लॉगिन को ब्रोकर करना, और माइग्रेशन के लिए डॉक्यूमेंटेड तरीके के रूप में realm एक्सपोर्ट और इम्पोर्ट करना। कुछ संगठनों के लिए कागजों पर इसका कमर्शियल सपोर्ट मायने रखता है। इसकी कमी यह है कि Keycloak का अपना कोई प्रॉक्सी नहीं है। इसलिए, जो एप्लिकेशन OIDC (OpenID Connect) का उपयोग नहीं करते, उन्हें सुरक्षित करने के लिए oauth2-proxy जैसे किसी टूल को साथ में चलाना पड़ता है। Authentik का इन-बिल्ट प्रॉक्सी प्रोवाइडर यही कार्य करता है और पहले से ही इंटीग्रेटेड है। यही कारण है कि अधिकांश सेल्फ-होस्टर्स, जिनके पास विभिन्न प्रकार के एप्लिकेशन का समूह है, Authentik को चुनते हैं।

बैकअप और अपग्रेड

तीन चीजें रिस्टोर को संभव बनाती हैं: PostgreSQL डेटाबेस, ./data डायरेक्टरी, और .env।

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

उस डंप और .env को एक साथ स्टोर करें। केवल डंप पर्याप्त नहीं है, क्योंकि सेशन और टोकन डेटा को सुरक्षित रखने वाली सीक्रेट की .env में रहती है।

अपग्रेड एक टैग परिवर्तन है। .env में AUTHENTIK_TAG को उस रिलीज पर सेट करें जिसे आप चाहते हैं, फिर docker compose pull चलाएं और उसके बाद docker compose up -d चलाएं। पहले रिलीज नोट्स पढ़ें, क्योंकि Authentik तारीख-आधारित वर्ज़न का उपयोग करता है और कुछ रिलीज में माइग्रेशन होते हैं जिनके लिए यह आवश्यक है कि आप पिछले वर्ज़न से आएं। पुल करने से पहले डेटाबेस डंप लें, बाद में नहीं।

FAQ

क्या Authentik को स्वयं होस्ट करना निःशुल्क है?

ओपन सोर्स संस्करण निःशुल्क है और ऊपर बताई गई सभी चीज़ों को कवर करता है: प्रॉक्सी प्रोवाइडर, फॉरवर्ड ऑथ, OIDC (OpenID Connect), SAML, और फ्लो इंजन। एक सशुल्क एंटरप्राइज़ टियर में सपोर्ट और कुछ एंटरप्राइज़ फीचर्स मिलते हैं, लेकिन यहाँ किसी भी चीज़ के लिए लाइसेंस की आवश्यकता नहीं है।

क्या Authentik का उपयोग करने के लिए मुझे Traefik की आवश्यकता है?

नहीं। फॉरवर्ड ऑथ, nginx के साथ auth_request के माध्यम से और Caddy के साथ forward_auth के माध्यम से काम करता है। हर मामले में पैटर्न एक ही है: रिवर्स प्रॉक्सी प्रत्येक अनुरोध के बारे में Authentik से पूछता है, और सुरक्षित होस्टनाम पर पाथ प्रीफिक्स /outpost.goauthentik.io/ को ऐप के बजाय Authentik पर रूट करना चाहिए।

मेरा सुरक्षित ऐप लॉगिन और एरर के बीच बार-बार क्यों घूमता रहता है?

प्रॉक्सी प्रोवाइडर पर कॉन्फ़िगर किया गया एक्सटर्नल होस्ट उस URL से मेल नहीं खाता है जिसका उपयोग ब्राउज़र कर रहा है, अक्सर http बनाम https। सेशन कुकी एक ओरिजिन के लिए जारी की जाती है और दूसरे पर पढ़ी जाती है, इसलिए Authentik हर बार एक अनाम अनुरोध देखता है। एक्सटर्नल होस्ट को सही करें, फिर दोबारा टेस्ट करने से पहले दोनों होस्टनाम के लिए कुकीज़ क्लियर करें।

Authentik को कितनी RAM की आवश्यकता है?

जुलाई 2026 तक प्रलेखित न्यूनतम आवश्यकता 2 CPU कोर और 2 GB RAM है, जिसमें PostgreSQL, सर्वर और वर्कर सभी शामिल हैं। 2 GB वाले बॉक्स पर, मेमोरी दबाव होने पर वर्कर वह पहला प्रोसेस है जिसे कर्नेल बंद कर देता है, और इसका लक्षण यह है कि बैकग्राउंड टास्क और आउटबाउंड ईमेल रुक जाते हैं जबकि लॉगिन पेज अभी भी काम करता है। यदि उसी सर्वर पर आप उन ऐप्स को भी चला रहे हैं जिन्हें आप सुरक्षित कर रहे हैं, तो इसे 4 GB RAM दें।