Authentik کو Docker Compose پر کیسے چلائیں؟

آپ کی میزبانی کردہ ہر ایپ کے لیے ایک ہی لاگ اِن

Authentik ایک خود میزبانی شدہ SSO (single sign-on) سرور ہے۔ صارفین ایک بار سائن اِن کرتے ہیں، اور اس کے پیچھے موجود ہر ایپ اپنی الگ password مانگنے کے بجائے اسی session کو قبول کرتی ہے۔ انسٹالیشن کے لیے سرکاری Docker Compose file اور دو generated secrets درکار ہیں۔ اصل منصوبہ بندی اس کے بعد ہوتی ہے: reverse proxy کو اس کی طرف بھیجنا، اور forward auth کے ذریعے ایک موجودہ ایپ کو اس کے پیچھے رکھنا۔

Authentik اس Compose file میں تین services کے طور پر چلتا ہے: PostgreSQL database، ایک server process، اور ایک worker process۔ server container میں embedded outpost بھی چلتا ہے۔ یہی component ہر محفوظ ایپ کے لیے یہ جانچتا ہے کہ "کیا یہ request سائن اِن ہے؟" Version 2026.5 جولائی 2026 تک موجودہ release ہے، اور project کم از کم 2 CPU cores اور 2 GB RAM والا host تجویز کرتا ہے۔ اسے کم از کم مطلوبہ سطح سمجھیں۔ box ایک دن چلنے کے بعد PostgreSQL اور worker دونوں memory استعمال کرتے رہتے ہیں۔

شروع کرنے سے پہلے آپ کو کیا درکار ہے

آپ کے پاس Compose v2 plugin کے ساتھ Docker Engine ہونا چاہیے۔ اس کی تصدیق آپ docker compose version سے کر سکتے ہیں۔ اگر یہ version کے بجائے error دکھائے تو آگے بڑھنے سے پہلے plugin install کریں۔ بنیادی طریقہ VPS پر Docker Compose کے ساتھ apps چلانا میں بیان کیا گیا ہے۔ آپ کو ایک DNS A record بھی درکار ہے جو server کی طرف اشارہ کرے۔ ذیل کی مثالوں میں یہ auth.example.com ہے، کیونکہ Authentik اپنے redirect URLs اس hostname کی بنیاد پر بناتا ہے جسے browser نے استعمال کیا ہو۔

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 کے جواب دینے سے پہلے ایک منٹ انتظار کریں۔

دونوں generate کی گئی values مختلف وجوہات کی بنا پر اہم ہیں۔ PG_PASS PostgreSQL password ہے، اور اس کی زیادہ سے زیادہ حد 99 characters ہے۔ AUTHENTIK_SECRET_KEY sessions اور tokens پر دستخط کرتا ہے، اس لیے اسے بعد میں تبدیل کرنے سے ہر user لاگ آؤٹ ہو جاتا ہے اور آپ کے جاری کردہ تمام API tokens غیر مؤثر ہو جاتے ہیں۔ .env کو mode 600 پر رکھیں اور اس کی ایک copy محفوظ جگہ پر رکھیں، کیونکہ matching secret key کے بغیر restore کیا گیا database ایسا database ہے جس میں کوئی لاگ اِن نہیں کر سکتا۔

Compose فائل دونوں values کو ${PG_PASS:?database password required} form کے ذریعے پڑھتی ہے۔ اس کا مطلب ہے کہ فائل موجود نہ ہونے پر Compose شروع ہونے سے انکار کرتا ہے۔ غلط directory سے docker compose up -d چلانے پر required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required ظاہر ہوتا ہے اور عمل رک جاتا ہے۔ یہ پیغام path کا مسئلہ بتاتا ہے، config کا نہیں۔

ماحول کی اہم اقدار

باقی تمام چیزیں اسی .env فائل میں شامل کی جاتی ہیں۔ Authentik دو انڈر اسکورز کو اندرونی configuration key میں تبدیل کرتا ہے، اس لیے AUTHENTIK_EMAIL__HOST، email.host مقرر کرتا ہے۔ ایک انڈر اسکور کو بغیر کسی انتباہ کے نظرانداز کیا جاتا ہے۔ یہی عموماً اس وجہ سے ہوتا ہے کہ کوئی setting اثرانداز ہوتی دکھائی نہیں دیتی۔

• AUTHENTIK_BOOTSTRAP_PASSWORD پہلی بار شروع ہونے پر built-in akadmin صارف کا password مقرر کرتا ہے، اس لیے آپ کو اسے کبھی public web form میں درج نہیں کرنا پڑتا۔ AUTHENTIK_BOOTSTRAP_EMAIL اور AUTHENTIK_BOOTSTRAP_TOKEN اسی طریقے سے اس صارف کا address اور API token مقرر کرتے ہیں۔
• COMPOSE_PORT_HTTP اور COMPOSE_PORT_HTTPS، published ports کو default ports 9000 اور 9443 سے تبدیل کرتے ہیں۔
• AUTHENTIK_EMAIL__HOST، AUTHENTIK_EMAIL__PORT، AUTHENTIK_EMAIL__USERNAME، AUTHENTIK_EMAIL__PASSWORD، AUTHENTIK_EMAIL__USE_TLS اور AUTHENTIK_EMAIL__FROM، outbound mail کو configure کرتے ہیں۔ ان کے بغیر Authentik، port 25 پر localhost سے رابطہ کرنے کی کوشش کرتا ہے، اس لیے password-reset mails، worker log میں connection error پر ختم ہو جاتی ہیں۔
• AUTHENTIK_LOG_LEVEL=debug اس وقت مطلوبہ detail کو فعال کرتا ہے جب login flow درست طور پر کام نہ کر رہا ہو۔ بعد میں اسے info پر واپس کر دیں۔
• AUTHENTIK_ERROR_REPORTING__ENABLED بطور default false ہے۔ اسے صرف true پر مقرر کریں اگر آپ crash reports upstream بھیجنے پر رضامند ہوں۔

یہ plain file میں موجود secrets ہیں، اس لیے directory کے ساتھ وہی احتیاط کریں جو کسی بھی دوسرے credential store کے ساتھ کرتے ہیں۔ self-hosted Vaultwarden instance جیسا password manager، recovery copy رکھنے کے لیے آپ کے laptop پر موجود note سے بہتر جگہ ہے۔

پہلی بار لاگ اِن اور منتظم اکاؤنٹ

براؤزر میں http://SERVER_IP:9000 کھولیں۔ Authentik اپنا ابتدائی سیٹ اپ فلو دکھاتا ہے اور آپ سے پہلے سے طے شدہ akadmin صارف کے لیے پاس ورڈ مقرر کرنے کو کہتا ہے۔ اگر آپ AUTHENTIK_BOOTSTRAP_PASSWORD پہلے ہی مقرر کر چکے ہیں، تو یہ مرحلہ مکمل ہو چکا ہے اور آپ براہِ راست لاگ اِن صفحے پر چلے جاتے ہیں۔

Directory اور پھر Users کے تحت اپنے لیے ایک عام منتظم صارف بنائیں، اسے authentik Admins گروپ میں شامل کریں، اور اسی اکاؤنٹ سے سائن اِن کریں۔ akadmin کو ہنگامی رسائی کے اکاؤنٹ کے طور پر برقرار رکھیں، اور اس کا طویل پاس ورڈ آف لائن محفوظ رکھیں۔ روزمرہ کا کام مشترکہ بلٹ اِن اکاؤنٹ کے ذریعے کرنے سے آڈٹ لاگ ناقابلِ اعتماد ہو جاتا ہے، کیونکہ ہر واقعہ میں akadmin درج ہوتا ہے اور یہ معلوم نہیں ہوتا کہ کارروائی کس نے کی۔

Authentik کو اپنے ریورس پراکسی کے پیچھے چلائیں

پورٹ 9000 کو انٹرنیٹ پر شائع کرنا کام کرتا ہے، لیکن آپ کو TLS (transport layer security) اور ایک حقیقی hostname چاہیے۔ اگر آپ پہلے ہی متعدد Compose ایپس کے لیے Traefik بطور ریورس پراکسی والا سیٹ اپ چلا رہے ہیں، تو override فائل کے ذریعے Authentik کو اسی بیرونی proxy network سے منسلک کریں۔ docker-compose.override.yml کو 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

اسے docker compose up -d کے ذریعے نافذ کریں۔ Compose خودکار طور پر override کو ضم کر دیتا ہے، اس لیے server service کو official فائل کی تمام ترتیبات برقرار رہتی ہیں اور 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 کو ٹریفک بھیجتا ہے۔ Forward auth (single application) کا مطلب ہے کہ آپ کا اپنا reverse proxy ٹریفک منتقل کرتا رہتا ہے اور صرف Authentik سے پوچھتا ہے کہ آیا درخواست میں صارف سائن ان ہے۔ Forward auth (domain level) ایک ہی parent domain کے تحت تمام apps کو ایک provider سے محفوظ کرتا ہے، لیکن ہر application کے لیے 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 کے لیے جواب دیتا ہے جو اسے تفویض کی گئی ہوں۔ اسی لیے آخری مرحلہ چھوڑنے پر درست طور پر configured provider بھی کوئی جواب نہیں دیتا۔

Middleware صرف ایک بار Authentik container پر define کریں، اور ہر محفوظ 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

authResponseHeaders ان headers کی فہرست ہے جنہیں Traefik Authentik کے جواب سے لے کر upstream کو بھیجی جانے والی درخواست میں شامل کرتا ہے۔ اسے چھوڑنے پر app محفوظ تو رہتی ہے، لیکن اسے صارف کی شناخت معلوم نہیں ہوتی۔ اس لیے جو بھی چیز خودکار login کے لیے X-authentik-username پڑھتی ہے، وہ 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 موجود نہ ہو تو درخواست آپ کی app تک پہنچتی ہے۔ app 404 کا جواب دیتی ہے اور login مکمل نہیں ہوتا۔ زیادہ priority کی وجہ سے اسی domain پر موجود سادہ Host() rule کے مقابلے میں مخصوص path rule کو ترجیح ملتی ہے۔

اسے private browser window میں test کریں۔ آپ کو auth.example.com پر بھیجا جانا چاہیے، وہاں sign in کریں، اور پھر app پر واپس آ جائیں۔ Authentik کی جانب موجود docker compose logs -f server ہر کوشش کے لیے authorization event دکھاتا ہے۔ اس سے معلوم ہوتا ہے کہ درخواست Authentik تک پہنچی بھی تھی یا نہیں۔

آپ کو درپیش آنے والی حقیقی ناکامیاں

ایپ اور login page کے درمیان لامتناہی redirect loop۔ provider پر موجود external host اس host سے مطابقت نہیں رکھتا جسے browser استعمال کرتا ہے۔ عموماً provider میں http:// اور address bar میں https:// ہوتا ہے۔ اس کے بعد session cookie مختلف origin کے لیے set ہوتی ہے، اس لیے ہر واپسی نئی anonymous request معلوم ہوتی ہے۔ دوبارہ جانچ سے پہلے external host درست کریں اور دونوں domains کی cookies صاف کریں۔

/outpost.goauthentik.io/start پر 404۔ outpost router موجود نہیں، یا اس کی priority اس host کے catch-all router سے کم ہے۔

ایپ load ہو جاتی ہے لیکن login کے لیے کبھی نہیں پوچھتی۔ middlewares label ایسے middleware کا نام ہے جو موجود نہیں۔ Traefik اس بارے میں warning نہیں دیتا، اس لیے authentik@docker میں typo کا مطلب صرف یہ ہے کہ کوئی middleware run نہیں ہوتا۔ Traefik dashboard کھولیں اور تصدیق کریں کہ router میں middleware درج ہے۔

کامیاب login کے بعد Authentik کی طرف سے 403۔ user authenticated ہے، لیکن authorized نہیں۔ ایپلیکیشن میں ایسی policy binding یا group requirement موجود ہے جسے یہ user پورا نہیں کرتا۔ admin interface میں Events log اس policy کا نام دکھاتا ہے جس نے رسائی مسترد کی۔

جب Keycloak زیادہ موزوں انتخاب ہے

Keycloak ایک پرانا پروجیکٹ ہے جسے Red Hat کی معاونت حاصل ہے۔ یہ روایتی انٹرپرائز شناختی کاموں کے لیے زیادہ مضبوط انتخاب ہے، جن میں وسیع SAML federation، بیک وقت متعدد بیرونی identity providers سے login بروکر کرنا، اور دستاویزی migration path کے طور پر realm export اور import شامل ہیں۔ کچھ اداروں کے لیے کمرشل سپورٹ کی دستیابی بھی اہم ہوتی ہے۔ اس کے بدلے، Keycloak کا اپنا proxy نہیں ہے۔ اس لیے ایسے app کو محفوظ بنانے کے لیے جو OIDC (OpenID Connect) استعمال نہیں کرتی، اس کے ساتھ oauth2-proxy جیسی سروس چلانا پڑتی ہے۔ Authentik کا built-in proxy provider یہی کام پہلے سے integrated صورت میں فراہم کرتا ہے۔ اسی وجہ سے مختلف قسم کی apps چلانے والے زیادہ تر self-hosters آخرکار Authentik کو منتخب کرتے ہیں۔

بیک اپ اور اپ گریڈ

بحالی کے لیے 3 چیزیں ضروری ہیں: PostgreSQL ڈیٹابیس، ./data ڈائریکٹری، اور .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 ڈیٹا کی حفاظت کرنے والی secret key .env میں موجود ہوتی ہے۔

اپ گریڈ tag کی تبدیلی ہے۔ .env میں AUTHENTIK_TAG کو مطلوبہ release پر سیٹ کریں، پھر docker compose pull چلائیں اور اس کے بعد docker compose up -d چلائیں۔ پہلے release notes پڑھیں، کیونکہ Authentik تاریخ پر مبنی versions استعمال کرتا ہے، اور بعض releases میں ایسی migrations شامل ہوتی ہیں جو توقع کرتی ہیں کہ آپ پچھلے release سے اپ گریڈ کر رہے ہیں۔ pull سے پہلے database dump لیں، بعد میں نہیں۔

FAQ

کیا Authentik کو خود میزبانی کے لیے مفت استعمال کیا جا سکتا ہے؟

اوپن سورس ایڈیشن مفت ہے اور اوپر بیان کردہ تمام چیزیں فراہم کرتا ہے: proxy provider، forward auth، OIDC (OpenID Connect)، SAML، اور flows engine۔ ادائیگی والا enterprise tier معاونت اور کچھ enterprise خصوصیات شامل کرتا ہے، لیکن یہاں کسی licence کی ضرورت نہیں۔

کیا Authentik استعمال کرنے کے لیے Traefik ضروری ہے؟

نہیں۔ forward auth، auth_request کے ذریعے nginx کے ساتھ اور forward_auth کے ذریعے Caddy کے ساتھ کام کرتا ہے۔ ہر صورت میں طریقہ ایک ہی ہے: reverse proxy ہر درخواست کے بارے میں Authentik سے پوچھتا ہے، اور محفوظ hostname پر موجود path prefix /outpost.goauthentik.io/ کو app کے بجائے Authentik کی طرف route ہونا چاہیے۔

میری محفوظ app بار بار login اور error کے درمیان کیوں جا رہی ہے؟

proxy provider پر configured external host، browser کے استعمال کردہ URL سے مطابقت نہیں رکھتا۔ عموماً مسئلہ http اور https کے درمیان فرق کا ہوتا ہے۔ session cookie ایک origin کے لیے جاری ہوتی ہے اور دوسرے origin پر پڑھی جاتی ہے، اس لیے Authentik ہر بار anonymous request دیکھتا ہے۔ external host درست کریں، پھر دوبارہ test کرنے سے پہلے دونوں hostnames کی cookies clear کریں۔

Authentik کو کتنی RAM درکار ہے؟

July 2026 تک دستاویزی minimum، 2 CPU cores اور 2 GB RAM ہے۔ اس میں PostgreSQL، server اور worker تینوں شامل ہیں۔ 2 GB والی مشین پر memory pressure کے دوران kernel سب سے پہلے worker process کو ختم کرتا ہے۔ اس کی علامت یہ ہے کہ login page کام کرتا رہتا ہے، لیکن background tasks اور outbound email رک جاتے ہیں۔ اگر یہی server محفوظ کی جانے والی apps بھی چلا رہا ہو تو اسے 4 GB RAM دیں۔