Authentik: तुमच्या ॲप्ससाठी self-hosted SSO

तुम्ही होस्ट करत असलेल्या प्रत्येक ॲपसाठी एकच लॉगिन

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

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

प्रारंभ करण्यापूर्वी आवश्यक गोष्टी

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

Stack root म्हणून नव्हे, तर docker group मधील सामान्य user म्हणून चालवा. या group चे membership host वरील root इतकेच अधिकार देते. त्यामुळे हे membership एका 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 वर स्वाक्षरी करतो. त्यामुळे तो नंतर बदलल्यास प्रत्येक user लॉग आउट होतो आणि तुम्ही जारी केलेले सर्व API tokens अवैध ठरतात. .env चा mode 600 कायम ठेवा आणि त्याची एक प्रत सुरक्षित ठिकाणी ठेवा. जुळणाऱ्या secret key शिवाय restore केलेल्या database मध्ये कोणीही log in करू शकत नाही.

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 संबंधी समस्या नाही.

महत्त्वाची पर्यावरणीय मूल्ये

इतर सर्व मूल्ये त्याच .env फाइलमध्ये लिहा. Authentik दुहेरी अंडरस्कोअरला नेस्टेड कॉन्फिगरेशन कीमध्ये रूपांतरित करते, त्यामुळे AUTHENTIK_EMAIL__HOST मुळे email.host सेट होते. एकेरी अंडरस्कोअरकडे कोणतीही सूचना न देता दुर्लक्ष केले जाते. सेटिंगचा काहीही परिणाम होत नसल्याचे हे सर्वात सामान्य कारण आहे.

• पहिल्यांदा सुरू होताना AUTHENTIK_BOOTSTRAP_PASSWORD अंगभूत akadmin वापरकर्त्याचा पासवर्ड सेट करते. त्यामुळे सार्वजनिक वेब फॉर्ममध्ये पासवर्ड टाइप करावा लागत नाही. AUTHENTIK_BOOTSTRAP_EMAIL आणि AUTHENTIK_BOOTSTRAP_TOKEN त्याच पद्धतीने त्या वापरकर्त्याचा पत्ता आणि API token सेट करतात.
• COMPOSE_PORT_HTTP आणि COMPOSE_PORT_HTTPS प्रकाशित ports चे default 9000 आणि 9443 वरून बदलतात.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS आणि AUTHENTIK_EMAIL__FROM बाहेर जाणारा mail configure करतात. ही मूल्ये नसल्यास Authentik port 25 वर localhost वापरण्याचा प्रयत्न करते. त्यामुळे password-reset mails worker log मध्ये connection error मुळे अयशस्वी होतात.
• login flow मध्ये समस्या येत असताना आवश्यक तपशील दाखवण्यासाठी 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 साठी स्वतः होस्ट केलेले Vaultwarden instance अधिक योग्य ठिकाण आहे.

पहिला login आणि admin account

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

Directory आणि त्यानंतर Users अंतर्गत स्वतःसाठी एक सामान्य admin user तयार करा. त्याला authentik Admins group मध्ये जोडा आणि त्या account ने sign in करा. akadmin हे break-glass account म्हणून ठेवा आणि त्याचा मोठा password offline साठवा. सामायिक built-in account वापरून दैनंदिन काम केल्यास audit log निरुपयोगी ठरतो, कारण प्रत्येक event मध्ये akadmin असेच दिसते आणि कृती कोणी केली हे समजत नाही.

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

इंटरनेटवर port 9000 प्रकाशित केल्यास ते कार्य करते. परंतु तुम्हाला TLS (transport layer security) आणि प्रत्यक्ष hostname हवा आहे. तुम्ही एकाधिक Compose अॅप्ससाठी Traefik reverse proxy म्हणून येथील setup आधीच चालवत असल्यास, 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 आपोआप विलीन करते. त्यामुळे server service मध्ये official file मधील सर्व गोष्टी कायम राहतात आणि labels जोडले जातात. curl -I https://auth.example.com/if/user/ वापरून तपासा. त्याने HTTP/2 200 ला उत्तर द्यावे. Traefik कडून मिळणारा 404 page not found म्हणजे container proxy network वर नाही. Traefik ज्या container पर्यंत पोहोचू शकत नाही त्याकडे traffic route करू शकत नाही.

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

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

Authentik च्या proxy provider मध्ये तीन मोड आहेत. चुकीचा मोड निवडल्यास एक तास वाया जाऊ शकतो. Proxy मोडमध्ये outpost स्वतः upstream app कडे traffic पाठवतो. Forward auth (single application) मोडमध्ये तुमचा reverse proxy traffic पाठवत राहतो आणि विनंती करणारा वापरकर्ता sign in आहे का, एवढेच Authentik ला विचारतो. Forward auth (domain level) मोडमध्ये एकाच provider द्वारे एका parent domain अंतर्गत असलेल्या प्रत्येक app चे संरक्षण केले जाते. मात्र प्रत्येक app साठी स्वतंत्र authorization rules ठेवता येत नाहीत. Traefik समोर असल्यास forward auth (single application) निवडा.

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 योग्यरित्या configure केलेला असूनही कोणताही प्रतिसाद मिळत नाही.

Middleware एकदाच Authentik container वर define करा आणि प्रत्येक संरक्षित 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 चे संरक्षण राहते. मात्र app ला वापरकर्ता कोण आहे हे कळत नाही. त्यामुळे automatic login साठी X-authentik-username वाचणारे कोणतेही app logged out राहते.

संरक्षित 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 वर, 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 पेजदरम्यान सतत 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 साठी विचारणा न करताच ॲप लोड होते. middlewares label अस्तित्वात नसलेल्या middleware चे नाव दर्शवते. Traefik याबाबत इशारा देत नाही. त्यामुळे authentik@docker मधील typo असल्यास कोणतेही middleware चालत नाही. Traefik dashboard उघडा आणि router मध्ये middleware सूचीबद्ध आहे याची खात्री करा.

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

Keycloak अधिक योग्य पर्याय असताना

Keycloak हा जुना प्रकल्प आहे आणि त्यामागे Red Hat चे समर्थन आहे. पारंपरिक एंटरप्राइझ ओळख व्यवस्थापनासाठी तो अधिक सक्षम पर्याय आहे. यामध्ये मोठ्या प्रमाणातील SAML federation, एकाच वेळी अनेक बाह्य identity providers कडून login चे brokering, तसेच दस्तऐवजीकरण केलेला migration मार्ग म्हणून realm export आणि import यांचा समावेश होतो. काही संस्थांसाठी त्यामागील commercial support हे कागदोपत्री महत्त्वाचे असते. मात्र, Keycloak मध्ये स्वतःचा proxy नाही. त्यामुळे OIDC (OpenID Connect) वापरत नसलेल्या app चे संरक्षण करण्यासाठी त्याच्या बाजूला oauth2-proxy सारखे साधन चालवावे लागते. Authentik मधील built-in proxy provider हे काम आधीपासून integrated स्वरूपात करतो. म्हणून विविध प्रकारचे apps वापरणाऱ्या बहुतेक 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 एकत्र साठवा. फक्त डंप पुरेसा नाही, कारण सेशन आणि टोकन डेटाचे संरक्षण करणारी गुप्त की .env मध्ये असते.

अपग्रेड म्हणजे टॅग बदलणे. तुम्हाला हवा असलेला रिलीज .env मध्ये AUTHENTIK_TAG म्हणून सेट करा. त्यानंतर docker compose pull आणि docker compose up -d चालवा. आधी रिलीज नोट्स वाचा, कारण Authentik दिनांक-आधारित आवृत्त्या वापरते आणि काही रिलीजमध्ये अशी माइग्रेशन असतात ज्यांसाठी मागील रिलीजमधून अपग्रेड करणे अपेक्षित असते. pull करण्यापूर्वी डेटाबेस डंप घ्या, pull केल्यानंतर नाही.

FAQ

Authentik स्वतः होस्ट करणे विनामूल्य आहे का?

मुक्त स्रोत आवृत्ती विनामूल्य आहे. वर नमूद केलेल्या सर्व सुविधा त्यात समाविष्ट आहेत: 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 कडे चौकशी करते. संरक्षित hostname वरील /outpost.goauthentik.io/ हा path prefix app ऐवजी Authentik कडे route झाला पाहिजे.

माझे संरक्षित 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 आवश्यक आहे?

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