Can't make auth work with pathprefix

[sgayda2]

I am having some issues setting up authentik OIDC + traefik where I use a path prefix. It seems that when the callback url is called it fails with a 404 because the callback url does not have the prefix. I am certain that I am missing a simple configuration change but I need assistance.

I have something like this in my file provider:

http:
  middlewares:
    oidc-auth:
      plugin:
        traefik-oidc-auth:
          Secret: "........."
          Provider:
            Url: https://auth.{{ env "DOMAIN" }}/application/o/traefik/
            ClientId: "......."
            ClientSecret: "....."
          Scopes: ["openid", "profile", "email"]

  routers:
    authentik:
      rule: Host(`auth.{{ env "DOMAIN" }}`)
      service: authentik
      tls:
        certresolver: le
      entryPoints:
        - websecure 

    foo:
      rule: Host(`foo.{{ env "DOMAIN" }}`)
      service: foo
      tls:
        certresolver: le
      entryPoints:
        - websecure 
      middlewares: ["oidc-auth"]

    bar-baz:
      rule: Host(`bar.{{ env "DOMAIN" }}`) && PathPrefix(`/baz`)
      service: bar-baz
      tls:
        certresolver: le
      entryPoints:
        - websecure 
      middlewares: ["oidc-auth"]

  services:
    authentik:
      loadBalancer:
        servers:
          - url: "http://server.local:9000/"

    foo:
      loadBalancer:
        servers:
          - url: "http://server.local:1234"

    bar-baz:
      loadBalancer:
        servers:
          - url: "http://server.local:5678/"

When I navigate to foo.example.com it correctly redirects me to auth.example.com I login and it correctly brings me back to what I would expect to see from http://server.local:1234 . However when I navigate to bar.example.com/baz it will correctly redirect me to auth.example.com I will login and then it will redirect me to bar.example.com/oidc/callback?..... which will produce a 404.

I am sure that this is a simple config change, but I am unable to figure it out, its also unclear if this is a traefik, middleware, or authentik issue. I hope you can help me.

[sevensolutions]

Hi @sgayda2,
when you're using PathPrefix(/baz) in your router-rule you need to ensure, that the callback also reaches the middleware.
The default callback uri of the middleware is /oidc/callback and this is basically just an overlay.
So in your case with the bar-subdomain only urls starting with /baz would reach the middleware.
To make this work you have two options:

Option A:
Use

rule: Host(`bar.{{ env "DOMAIN" }}`) && (PathPrefix(`/baz`) || PathPrefix(`/oidc/callback`))

Option B:
Change the callback url of the plugin to something behind the /baz route so that the overlay mechanism works.

http:
  middlewares:
    oidc-auth:
      plugin:
        traefik-oidc-auth:
          CallbackUri: "/baz/oidc/callback"

Personally i would suggest using option A.

[sgayda2]

I believe that neither option will work for me. I know that when i tried option B before, it would do an infinite redirect because it would keep trying to pass the /baz/oidc/callback path to the same rule that needed to be authenticated and that would forward it to my auth provider which was already logged in and it would forward me back to the same callback url and the cycle would repeat.

I do not believe that option A would work for me because i do intend to add more than one path rule for example i have bar.example.com/baz but i would also like to do bar.example.com/tar that redirects to something else. If i make my rule always go to the the baz service when /oidc/callback is called, then it would never forward to the second service when it goes to the callback.

Maybe I need to do some kind of combo, i will try again tonight and see what i can come up with.

[sgayda2]

I stand corrected, i tried option A and it worked for both paths, but I am unclear how the logic works, as I am not sure why it would select one or the other rule since they would both apply

[sevensolutions]

Yeah this is a little bit of traefik magic.
The rule with the higher priority will match. You can specify it explicitly and if you dont, then the default priority is the string-length of the rule.
So a "more complicated" rule has a higher default priority.