[Config Support]: Proxy Auth

[vcdx71]

Describe the problem you are having

I'm having an issue getting the role part of proxy auth working. User is working correctly, though any user who authenticates is given whatever my default role is set to. Using the whoami container passing through the same authentication app in authentik I see the correct headers as seen below. This test user gets admin access in frigate even though they're in the viewer group which is mapped in my frigate config.

Am I missing something? Is there a page in frigate, like api/stats that will show the headers being passed? The whoami container shows uppercase headers (X-Authentik-Groups) I've tried both in the config as well as adding this exact capitalization to the proxy_trusted_headers.conf, nothing seems to work for me.

Hostname: 4c12aabfbbc8
IP: 127.0.0.1
IP: ::1
IP: 172.19.0.2
RemoteAddr: 172.19.0.17:37576
GET / HTTP/1.1
Host: who.xxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cookie: authentik_proxy_2ec5b758=HGCRG5Q734VGVDUBIWZIASGNHQN2MYYAXIPJZS4WQSBWN6K3CP2Q
Dnt: 1
Priority: u=0, i
Sec-Ch-Ua: "Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Authentik-Email:
X-Authentik-Entitlements:
X-Authentik-Groups: viewer
X-Authentik-Meta-App: vcdx71
X-Authentik-Meta-Jwks: https://sso.xxxx/application/o/vcdx71/jwks/
X-Authentik-Meta-Outpost: authentik Embedded Outpost
X-Authentik-Meta-Provider: Provider for Domain Wide Catch All
X-Authentik-Meta-Version: goauthentik.io/outpost/2025.6.2
X-Authentik-Name: Test User
X-Authentik-Username: test
X-Forwarded-For: 192.168.2.1
X-Forwarded-Host: who.xxxx
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: 9c6eb32dea7b

Version

0.16.0-fd96cd5

Frigate config file

auth:
  enabled: false
  trusted_proxies:
    - 172.19.0.0/16

proxy:
  separator: '|'
  header_map:
    user: X-Authentik-Username
    role: X-Authentik-Groups
  default_role: admin

Relevant Frigate log output

n/a

Relevant go2rtc log output

n/a

Frigate stats

No response

Operating system

UNRAID

Install method

Docker CLI

docker-compose file or Docker CLI command

docker run
  -d
  --name='frigate'
  --net='proxy'
  --privileged=true
  -e TZ="America/Chicago"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="DarkKnight"
  -e HOST_CONTAINERNAME="frigate"
  -e 'FRIGATE_RTSP_PASSWORD'='xxx'
  -e 'PLUS_API_KEY'='xxx'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8971]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/yayitazale/unraid-templates/main/frigate.png'
  -l 'traefik.http.routers.frigate-rtr.middlewares'='authentik@file'
  -l 'traefik.http.routers.frigate-rtr.rule'='Host(`frigate.xxx`)'
  -l 'traefik.http.services.frigate.loadbalancer.server.port'='8971'
  -l 'traefik.enable'='true'
  -l 'traefik.http.services.frigate.loadbalancer.server.scheme'='https'
  -p '8971:8971/tcp'
  -p '8554:8554/tcp'
  -p '5000:5000/tcp'
  -p '8555:8555/tcp'
  -p '8555:8555/udp'
  -v '/mnt/zfscache/appdata/frigate':'/config':'rw'
  -v '/mnt/user/Frigate/':'/media/frigate':'rw'
  -v '/etc/localtime':'/etc/localtime':'rw'
  --device='/dev/bus/usb'
  --device='/dev/dri/renderD128'
  --shm-size=8G
  --mount type=tmpfs,target=/tmp/cache,tmpfs-size=5000000000
  --restart unless-stopped
  --pids-limit 10000 'ghcr.io/blakeblackshear/frigate:fd96cd5'
e641d416bf22cb49d9f4b42e13109485fb3be99a6b28dfa07937497ade60ade4

Object Detector

Coral

Screenshots of the Frigate UI's System metrics pages

No response

Any other information that may be helpful

No response

[hawkeye217]

So the current logic in this code that was introduced after 0.16 beta 1 was actually designed with the opposite case in mind, that the default role would be "viewer". It assigns "admin" to remote-role if the role contains "admin" as one of the |-separated values. If "admin" is not present, it falls back to proxy_config.default_role, which you have assigned as "admin".

frigate/frigate/api/auth.py

Line 275 in 5593495

# if comma-separated with "admin", use "admin", else use default role

So this means that all users, regardless of their actual roles in X-Authentik-Groups, will have remote-role set to "admin" unless "admin" is explicitly listed in their roles. In this case, the user’s role is "viewer", so with the current logic, remote-role is set to "admin".

I think changing the logic to something like this should work:

success_response.headers["remote-role"] = (
    "admin"
    if role and "admin" in [r.strip() for r in role.split(proxy_config.separator)]
    else "viewer"
    if role and "viewer" in [r.strip() for r in role.split(proxy_config.separator)]
    else proxy_config.default_role
)

I'll push up this fix and you can test in the next dev build or the next beta.

[vcdx71]

Nice thanks! I'll keep an eye out for the next dev build.

I had originally set the default role to viewer but my main account wasn't getting admin so I switched it to workaround my issue.

Just FYI though, my main account is in a group called "admin" and is an admin in Frigate.
Hostname: 4c12aabfbbc8
IP: 127.0.0.1
IP: ::1
IP: 172.19.0.2
RemoteAddr: 172.19.0.17:48158
GET / HTTP/1.1
Host: who.xxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Dnt: 1
Priority: u=0, i
Sec-Ch-Ua: "Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Authentik-Email: mike@xxx
X-Authentik-Entitlements:
X-Authentik-Groups: authentik Admins|Admins|admin
X-Authentik-Meta-App: vcdx71
X-Authentik-Meta-Jwks: https://sso.xxx/application/o/vcdx71/jwks/
X-Authentik-Meta-Outpost: authentik Embedded Outpost
X-Authentik-Meta-Provider: Provider for Domain Wide Catch All
X-Authentik-Meta-Version: goauthentik.io/outpost/2025.6.2
X-Authentik-Name: Mike Brown
X-Authentik-Uid: 0646123cddb2886f141add1f2990889b245e92ebe157f8af90ff821c6622db5a
X-Authentik-Username: mike@xxx
X-Forwarded-For: 192.168.2.1
X-Forwarded-Host: who.xxx
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: 9c6eb32dea7b

[hawkeye217]

Right, your account will continue to have admin privileges because you provided admin in the header role. Even if you didn't provide admin, your default role is admin, so as long as you didn't provide viewer in X-Authentik-Groups, your user would be an admin.

The changes for this are in #18897

[vcdx71]

Right, your account will continue to have admin privileges because you provided admin in the header role. Even if you didn't provide admin, your default role is admin, so as long as you didn't provide viewer in X-Authentik-Groups, your user would be an admin.

The changes for this are in #18897

Thanks, I misread your first comment, I read it as if I'm in an admin group I'll get viewer with the way the code is now and my config.

[hawkeye217]

I should note again that your use case (providing admin as a default role) is insecure because it grants admin access to users with invalid or missing roles, potentially allowing unauthorized access to sensitive endpoints like /users. Instead, it's recommended use a less privileged role like viewer as the default to ensure safer access control.

[vcdx71]

I agree, I'll go test that again. When I was doing that originally my admin user was getting the viewer role.

[hawkeye217]

The changes will still get merged because the code should support whatever users want to do when Frigate's auth is disabled, even if it means they shoot themselves in the foot :)