---
title: "Discussion on \"Implementing SSO with Traefik\" | Hashnode"
description: "Discussion on \"Implementing SSO with Traefik\". samdbmg/ansible-traefik-auth-proxy combines the Traefik reverse proxy with thomseddon/traefik-forward-auth to provide HTTP reverse proxying, certificate handling with LetsEncrypt and SSO login, either as an Ansible role or a Docker Compose project.\nT..."
url: "https://hashnode.com/posts/implementing-sso-with-traefik/66e2313932f7b362a2ec24ac"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Implementing SSO with Traefik](https://blog.samn.co.uk/implementing-sso-with-traefik?utm_source=hashnode&utm_medium=feed)

samdbmg/ansible-traefik-auth-proxy combines the Traefik reverse proxy with thomseddon/traefik-forward-auth to provide HTTP reverse proxying, certificate handling with LetsEncrypt and SSO login, either as an Ansible role or a Docker Compose project. T...

Sep 12, 2024 · 5 min read · blog.samn.co.uk  
Read the article

-   [#traefik](https://hashnode.com/tag/traefik)
-   [#reverse-proxy](https://hashnode.com/tag/reverse-proxy)
-   [#oidc](https://hashnode.com/tag/oidc)
-   [#homelab](https://hashnode.com/tag/homelab)

## Written by

[Sam Mesterton-Gibbons](https://hashnode.com/@samdbmg)

@samdbmg · Manchester, UK

  
[View profile](https://hashnode.com/@samdbmg)

Manchester-based techie, Senior R&D Engineer at BBC R&D

I'm a Manchester-based techie who likes building systems to solve interesting problems, with interests in media and video production and sustainability.

## Responses 1

Markdown supported · ⌘↵ to post

[Edge Ops](https://hashnode.com/@edgecacheops)

[Nov 5](https://hashnode.com/posts/implementing-sso-with-traefik/66e2313932f7b362a2ec24ac/comment/6aebfcda508c706ce4249a89)

Traefik forward-auth SSO holds up when the auth middleware sits on the public Host routers that need a login, while the IdP callback and auth service itself stay on a router that is not wrapped by that same middleware — otherwise you get a redirect loop the dashboard still reports as a matched route. Share one cookie domain across sibling apps on the same parent zone, keep ForwardAuth addressing the auth container by Compose DNS on the private network, and pass through X-Forwarded-Proto plus the original Host so the IdP redirect URI stays on the public name users actually typed. TLS should terminate on the websecure entrypoint before the auth hop; mixing cleartext internal callbacks with HTTPS public names is a common source of “works in curl, fails in the browser” sessions.

After applying labels I confirm which router and middleware chain each hostname hit, that an unauthenticated request gets a single redirect to the IdP rather than an app 401 page, and that a second tab on another Host under the same cookie domain reuses the session without a second prompt. Also probe the auth service health from Traefik’s network and the protected app separately — a 502 on the app with a healthy IdP is usually the ForwardAuth address or trust headers drifting after a compose rename, not the identity provider itself.