Authentik: உங்கள் apps-க்கு self-hosted SSO அமைப்பது

நீங்கள் host செய்யும் ஒவ்வொரு app-க்கும் ஒரே login

Authentik என்பது self-hosted SSO (single sign-on) server ஆகும். உங்கள் users ஒருமுறை sign in செய்தால், அதன் பின்னால் உள்ள ஒவ்வொரு app-மும் தனித்தனி password கேட்பதற்குப் பதிலாக அந்த session-ஐ ஏற்றுக்கொள்ளும். Installation என்பது அதிகாரப்பூர்வ Docker Compose file மற்றும் உருவாக்கப்படும் இரண்டு secrets-ஐ பயன்படுத்துகிறது. உண்மையான கவனம் தேவைப்படும் பகுதி அதன் பிறகுதான்: reverse proxy-ஐ அதற்குச் சுட்டிக்காட்டி, ஏற்கனவே உள்ள ஒரு app-ஐ forward auth-ன் பின்னால் வைப்பது.

அந்த Compose file-ல் Authentik மூன்று services-ஆக இயங்குகிறது: PostgreSQL database, ஒரு server process, மற்றும் ஒரு worker process. Server container embedded outpost-ஐயும் இயக்குகிறது. பாதுகாக்கப்பட்ட ஒவ்வொரு app-க்கும் “இந்த request-ல் sign in செய்யப்பட்டுள்ளதா?” என்பதற்குப் பதிலளிக்கும் component இதுவாகும். July 2026 நிலவரப்படி Version 2026.5 தற்போதைய release ஆகும். இந்த project குறைந்தது 2 CPU cores மற்றும் 2 GB RAM கொண்ட host-ஐக் கோருகிறது. இதையே குறைந்தபட்சத் தேவையாகக் கருதுங்கள். Box ஒரு நாள் இயங்கிய பிறகு PostgreSQL மற்றும் worker இரண்டும் memory-ஐ பயன்படுத்திக் கொண்டிருக்கும்.

தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை

docker compose version மூலம் உறுதிப்படுத்தக்கூடிய Compose v2 plugin உடன் Docker Engine தேவை. அது version-க்கு பதிலாக error-ஐ காட்டினால், அடுத்த படிக்குச் செல்லும் முன் plugin-ஐ install செய்யுங்கள்; அடிப்படைகள் VPS-ல் Docker Compose மூலம் applications-ஐ இயக்குதல் பகுதியில் உள்ளன. Server-ஐச் சுட்டிக்காட்டும் DNS A record-உம் தேவை. கீழேயுள்ள examples-ல் அது auth.example.com ஆகும். ஏனெனில் browser பயன்படுத்திய hostname-இலிருந்து Authentik அதன் redirect URLs-ஐ உருவாக்குகிறது.

Stack-ஐ root ஆக அல்லாமல் docker group-இல் உள்ள சாதாரண user ஆக இயக்குங்கள். அந்த group-இன் membership, host-இல் root permissions-க்கு இணையானது. ஆகவே VPS-ல் குறைந்த privilege கொண்ட user accounts வழிகாட்டுதலுக்கு ஏற்ப, அதை ஒரு deploy account-க்கு மட்டும் வழங்குங்கள்.

அதிகாரப்பூர்வ 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-ஐ report செய்ய வேண்டும். worker, running-ஐ report செய்ய வேண்டும். முதல் start-இல் database migrations இயக்கப்படும். ஆகவே web interface பதிலளிக்கத் தொடங்குவதற்கு முன் ஒரு நிமிடம் காத்திருக்கவும்.

வெவ்வேறு காரணங்களுக்காக உருவாக்கப்பட்ட இரண்டு values-உம் முக்கியமானவை. PG_PASS என்பது PostgreSQL password. இதன் அதிகபட்ச நீளம் 99 characters. AUTHENTIK_SECRET_KEY sessions மற்றும் tokens-ஐ sign செய்கிறது. எனவே இதை பின்னர் மாற்றினால் ஒவ்வொரு user-உம் logout செய்யப்படுவார். நீங்கள் வழங்கிய ஒவ்வொரு API token-உம் invalid ஆகும். .env-ஐ mode 600-ல் வைத்திருக்கவும். இதன் ஒரு copy-ஐ பாதுகாப்பான இடத்தில் வைத்திருக்கவும். அதற்குரிய secret key இல்லாமல் restore செய்யப்பட்ட database-ல் யாரும் login செய்ய முடியாது.

Compose file இரண்டு values-ஐயும் ${PG_PASS:?database password required} form மூலம் படிக்கிறது. எனவே file இல்லாதபோது Compose start ஆக மறுக்கும். தவறான directory-யிலிருந்து docker compose up -d இயக்கினால் required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required print செய்யப்பட்டு, செயல்பாடு நிறுத்தப்படும். அந்த message path problem-ஐ குறிக்கிறது; config problem-ஐ அல்ல.

முக்கியமான environment மதிப்புகள்

மீதமுள்ள அனைத்தும் அதே .env file-ல் சேரும். Authentik, double underscore-ஐ nested configuration key-ஆக map செய்கிறது. எனவே AUTHENTIK_EMAIL__HOST, email.host-ஐ அமைக்கிறது. Single underscore எந்த warning-மும் இல்லாமல் புறக்கணிக்கப்படுகிறது. ஒரு setting செயல்படாதது போல் தோன்றுவதற்கான பொதுவான காரணம் இதுவாகும்.

• முதல் start-இல் உள்ளமைக்கப்பட்ட akadmin user-இன் password-ஐ AUTHENTIK_BOOTSTRAP_PASSWORD அமைக்கிறது. எனவே public web form-ல் password-ஐ ஒருபோதும் உள்ளிட வேண்டியதில்லை. அதே முறையில், அந்த user-இன் address-ஐ AUTHENTIK_BOOTSTRAP_EMAIL அமைக்கிறது; API token-ஐ AUTHENTIK_BOOTSTRAP_TOKEN அமைக்கிறது.
• Published ports-ஐ இயல்புநிலை 9000 மற்றும் 9443-இலிருந்து மாற்ற COMPOSE_PORT_HTTP மற்றும் COMPOSE_PORT_HTTPS பயன்படுத்தப்படுகின்றன.
• Outbound mail-ஐ AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS மற்றும் AUTHENTIK_EMAIL__FROM அமைக்கின்றன. இவை இல்லையெனில், Authentik port 25-ல் localhost-ஐ முயற்சிக்கும். எனவே password-reset mails, worker log-ல் connection error-ஆக முடிவடையும்.
• Login flow சரியாக இயங்காதபோது தேவையான detail-ஐ AUTHENTIK_LOG_LEVEL=debug இயக்குகிறது. பின்னர் அதை மீண்டும் info-ஆக மாற்றவும்.
• இயல்புநிலையாக AUTHENTIK_ERROR_REPORTING__ENABLED, false ஆகும். Crash reports-ஐ upstream-க்கு அனுப்புவதில் உங்களுக்கு சம்மதம் இருந்தால் மட்டுமே அதை true-ஆக அமைக்கவும்.

இவை plain file-ல் உள்ள secrets. எனவே, மற்ற credential store-ஐ கையாளும் முறையிலேயே இந்த directory-ஐ கையாளவும். உங்கள் laptop-ல் உள்ள note-ஐ விட, self-hosted Vaultwarden instance போன்ற password manager-ல் recovery copy-ஐ வைத்திருப்பது சிறந்தது.

முதல் உள்நுழைவு மற்றும் admin account

உலாவியில் http://SERVER_IP:9000-ஐ திறக்கவும். Authentik அதன் ஆரம்ப அமைவு செயல்முறையைக் காட்டி, இயல்புநிலை 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 apps-களுக்கான reverse proxy ஆக Traefik அமைப்பை ஏற்கனவே இயக்கினால், 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-இல் உள்ள அனைத்தையும் வைத்திருப்பதுடன் labels-ஐயும் பெறும். curl -I https://auth.example.com/if/user/ மூலம் சரிபார்க்கவும். அது HTTP/2 200-க்கு பதிலளிக்க வேண்டும். Traefik-இலிருந்து வரும் 404 page not found, container proxy network-இல் இல்லை என்பதைக் குறிக்கும். Traefik-ஐ அடைய முடியாத container-க்கு network traffic-ஐ route செய்ய முடியாது.

Hostname செயல்படத் தொடங்கியதும், override-இல் வெளியிடப்பட்ட ports-ஐ 127.0.0.1-க்கு bind செய்யவும். இதனால் proxy வழியாக மட்டுமே அணுக முடியும்.

forward auth மூலம் ஒரு பயன்பாட்டைப் பாதுகாத்தல்

Authentik-ன் proxy provider-க்கு 3 முறைகள் உள்ளன. தவறான முறையைத் தேர்ந்தெடுத்தால் 1 மணி நேரம் வீணாகும். Proxy என்றால் outpost தானே upstream பயன்பாட்டுக்கு network traffic-ஐ forward செய்கிறது. Forward auth (single application) என்றால் உங்கள் reverse proxy network traffic-ஐத் தொடர்ந்து கையாளும். அது மட்டும் request sign in செய்யப்பட்டுள்ளதா என்பதை Authentik-இடம் கேட்கும். Forward auth (domain level) என்றால் ஒரே parent domain-ன் கீழ் உள்ள எல்லா பயன்பாடுகளையும் ஒரே provider மூலம் பாதுகாக்கும். ஆனால் ஒவ்வொரு பயன்பாட்டிற்குமான 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 எந்தப் பதிலும் வழங்காததற்கான காரணமாகும்.

Middleware-ஐ Authentik container-ல் ஒருமுறை வரையறுக்கவும். பாதுகாக்க வேண்டிய ஒவ்வொரு application-லிருந்தும் அதைக் குறிப்பிடவும்:

      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

Authentik வழங்கும் பதிலிலிருந்து upstream-க்கு அனுப்பும் request-ல் Traefik நகலெடுக்கும் headers-ன் பட்டியல் authResponseHeaders ஆகும். இதைத் தவிர்த்தால் application பாதுகாப்பாக இருக்கும். ஆனால் user யார் என்பதை அது அறியாது. எனவே automatic login-க்காக X-authentik-username-ஐப் படிக்கும் எதுவும் logged out நிலையிலேயே இருக்கும்.

பாதுகாக்கப்படும் application-க்கு 1 router போதாது; 2 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-ஐ auth.example.com-க்கு அல்ல, application-ன் hostname-ல் உள்ள /outpost.goauthentik.io/-ன் கீழ் இருக்கும் path-க்கு அனுப்பும். அந்த path prefix-ஐ Authentik service-க்கு அனுப்பும் router இல்லையெனில், request உங்கள் application-ஐ அடையும். அது 404 பதிலை வழங்கும். Login நிறைவடையாது. அதிகமான priority மதிப்புதான், அதே domain-ல் உள்ள சாதாரண Host() rule-ஐ விட குறிப்பிட்ட path rule முன்னுரிமை பெறுவதை உறுதிசெய்கிறது.

Private browser window-ல் இதைச் சோதிக்கவும். நீங்கள் auth.example.com-க்கு அனுப்பப்பட வேண்டும். Sign in செய்த பிறகு application-க்கு திரும்ப வேண்டும். Authentik பக்கத்தில் உள்ள docker compose logs -f server, ஒவ்வொரு முயற்சிக்கும் ஒரு authorization event-ஐ அச்சிடும். இதன் மூலம் request Authentik-ஐ அடைந்ததா என்பதை அறியலாம்.

நீங்கள் உண்மையில் எதிர்கொள்ளும் தோல்விகள்

app மற்றும் login page இடையே முடிவில்லாத redirect loop. provider-இல் உள்ள external host, browser பயன்படுத்தும் host-உடன் பொருந்தவில்லை. பொதுவாக provider-இல் உள்ள http://, address bar-இல் உள்ள https://-க்கு பொருந்தாது. அதன் பின்னர் session cookie வேறு origin-க்காக அமைக்கப்படுகிறது. எனவே ஒவ்வொரு திரும்பும் request-மும் புதிய anonymous request போலக் கருதப்படுகிறது. Retest செய்வதற்கு முன் external host-ஐச் சரிசெய்து, இரு domains-க்குமான cookies-ஐ clear செய்யவும்.

/outpost.goauthentik.io/start-இல் 404. outpost router இல்லை, அல்லது அந்த host-க்கான catch-all router-ஐவிட அதன் priority குறைவாக உள்ளது.

login கேட்காமல் app load ஆகிறது. middlewares label, இல்லாத middleware-ஐக் குறிப்பிடுகிறது. Traefik இதைப் பற்றி warning காட்டாது. எனவே authentik@docker-இல் உள்ள typo காரணமாக middleware எதுவும் இயங்காது. Traefik dashboard-ஐத் திறந்து, router middleware-ஐப் பட்டியலிடுகிறதா என்பதை உறுதிப்படுத்தவும்.

வெற்றிகரமான login-க்கு பிறகு Authentik-இலிருந்து 403. user authenticated நிலையில் உள்ளார், ஆனால் authorized நிலையில் இல்லை. application-க்கு இந்த user பூர்த்தி செய்யாத policy binding அல்லது group requirement உள்ளது. அதை மறுத்த policy-யின் பெயரை admin interface-இல் உள்ள Events log காட்டும்.

Keycloak சிறந்த தேர்வாக இருக்கும் போது

Keycloak என்பது Red Hat ஆதரவுடன் இருக்கும் பழைய project. Classic enterprise identity பணிகளுக்கு இது வலுவான தேர்வு. இதில் விரிவான SAML federation, ஒரே நேரத்தில் பல வெளிப்புற identity providers-இலிருந்து login-களை broker செய்வது, மேலும் ஆவணப்படுத்தப்பட்ட migration பாதையாக realm export மற்றும் import ஆகியவை அடங்கும். இதற்குப் பின்னால் இருக்கும் commercial support, சில organisations-க்கு ஆவணங்களில் முக்கியமானதாக இருக்கலாம். இதன் மாற்றுச் செலவு என்னவென்றால், Keycloak-க்கு சொந்தமான proxy இல்லை. எனவே OIDC (OpenID Connect) பேசாத app-ஐ பாதுகாக்க, அதனுடன் oauth2-proxy போன்ற ஒன்றை இயக்க வேண்டும். Authentik-ன் built-in proxy provider இந்தப் பகுதியை ஏற்கனவே ஒருங்கிணைத்துள்ளது. அதனால் பலவகை apps கொண்ட mixed self-hosting சூழலில் பெரும்பாலானவர்கள் Authentik-ஐத் தேர்வு செய்கிறார்கள்.

காப்புப்பிரதிகள் மற்றும் மேம்படுத்தல்கள்

மீட்டமைப்பைச் செய்ய மூன்று விஷயங்கள் தேவை: 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-ல் உள்ளது.

மேம்படுத்தல் என்பது tag மாற்றம் ஆகும். நீங்கள் விரும்பும் release-க்கு .env-ல் AUTHENTIK_TAG-ஐ அமைக்கவும். பின்னர் docker compose pull-ஐ இயக்கி, அதன்பின் docker compose up -d-ஐ இயக்கவும். முதலில் release notes-ஐப் படிக்கவும், ஏனெனில் Authentik date-based versions-ஐப் பயன்படுத்துகிறது. சில releases-ல், முந்தைய release-இலிருந்து மேம்படுத்தப்படுவதை எதிர்பார்க்கும் migrations இருக்கும். pull செய்வதற்கு முன் database dump எடுக்கவும்; pull செய்த பிறகு எடுக்க வேண்டாம்.

FAQ

Authentik-ஐ தானாக host செய்வது இலவசமா?

Open source பதிப்பு இலவசமாகும். இதில் மேலே குறிப்பிடப்பட்டுள்ள அனைத்தும் அடங்கும்: proxy provider, forward auth, OIDC (OpenID Connect), SAML மற்றும் flows engine. கட்டண enterprise tier மூலம் support மற்றும் சில enterprise அம்சங்கள் கிடைக்கும். ஆனால் இங்கு குறிப்பிடப்பட்டுள்ள எதற்கும் 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-ல் அமைக்கப்பட்ட external host, browser பயன்படுத்தும் URL-உடன் பொருந்தவில்லை. பொதுவாக http மற்றும் https இடையே இவ்வாறு பொருந்தாமை இருக்கும். Session cookie ஒரு origin-க்காக வழங்கப்பட்டு மற்றொரு origin-ல் வாசிக்கப்படுகிறது. அதனால் ஒவ்வொரு முறையும் Authentik anonymous request-ஐக் காண்கிறது. External host-ஐச் சரிசெய்து, மீண்டும் சோதிப்பதற்கு முன் இரு hostname-களுக்குமான cookies-ஐ அழிக்கவும்.

Authentik-க்கு எவ்வளவு RAM தேவை?

July 2026 நிலவரப்படி ஆவணப்படுத்தப்பட்ட குறைந்தபட்சத் தேவை 2 CPU cores மற்றும் 2 GB RAM ஆகும். இது PostgreSQL, server மற்றும் worker ஆகிய மூன்றையும் உள்ளடக்கும். 2 GB கொண்ட server-ல் memory pressure ஏற்பட்டால், kernel முதலில் worker process-ஐ நிறுத்தும். இதன் அறிகுறியாக background tasks மற்றும் outbound email நிற்கும். ஆனால் login page தொடர்ந்து செயல்படும். அதே server-ல் நீங்கள் பாதுகாக்கும் apps-களும் இயங்கினால், 4 GB RAM வழங்கவும்.