Replies: 5 comments 22 replies
|
Hello, I am attempting a similar setup but using Keycloak, Oauth2-proxy and Nginx. I have managed to get the proxy header mapping working and able to pull the roles (Admin/Viewer) and username from my Keycloak users. I am currently experiencing issues with the "Review" tab as thumbnails are not loading when I have authentication disabled and proxy mapping setup. Viewing the web browser console the thumbnail URL (https://mydomain.com/clips/review/thumb-driveway-1758747684.421608-wetqpi.webp) is returning a 401 authorization required error. If I remove the proxy setting and enable authentication within Frigate the thumbnails start loading fine. I was wondering if you are also experiencing similar issues or had any advice for this problem? |
|
There seems to be an issue with authentik passing headers to apps: Edit: fixed in 2025.10.1, just waiting for release. Edit 2: moving to another idP. This is ridiculous. How tf do you push a major release with 0 testing and break everyone's setup then drag your feet releasing the fix when your whole product is based around security. Push it out as a hotfix, since it breaks CORE functionality and drag your feet on the stuff that doesn't break working installs and isn't documented as a breaking fix. |
|
2025.10.1 released, installed and is now back to working again with Frigate. |
|
2025.10.2 - fix logout_url |
|
@baudneo - do you have any suggestions for another idP? Have you got others to work with Frigate? |
|
I'm switching to keycloak with traefik and oauth2-proxy. I will write a guide after I've got everything configured and working appropriately. It's more involved, but at least you know red hat isn't going to leave you hanging and you're decoupling the reverse proxy from the auth. Edit: I came back to authentik. Upgraded to 2025.12.2 and they broke api routes in the outposts, downgraded to 2025.12.1 in the interim and now 2025.12.3 has been released with a hotfix. So all is working under authentik. Just wanted to clarify why I never posted a keycloak how to. |
|
I've tried following your setup but i have frigate.mydomain.com and authentik.mydomain.com pointing at NginxProxyManager and that does my SSL offloading, Initially this works but then i start getting : Any pointers on where to look ? |
|
I dont use NPM so I have no advice for NPM based issues, sorry! Edit: Its a CORS issue, I am assuming you need to adjust some config in NPM related to CORS |
|
I'm using the same setup and what I did is just leave NPM as empty as possible. Another approach could be to just use Authentik for the authentication and then have NPM forward it to the :5000 port of frigate and only have Authentik authentication, nothing at frigate. This then doesn't allow for group setup, but if you don't need it you could leave it as simple as that. |
|
Superb - thanks!! |
|
This guide has been helpful - I've got it mostly working for me. But I'm still being given the viewer role despite having the frigate-admin group setup with the x-frigate-role header. I'm using traefik as my reverse proxy with a router for frigate.mydomain.com pointing to authentik. Any ideas on what to check? Edit: I'm not sure what's changed but I'm passing the admin role correctly now. What should the logout url be for frigate in this setup? Edit2: After a container restart, frigate sees me as viewer again - weird. |
|
traefik adds complexity and as I dont use it myself, I unfortunately can't offer any advice, sorry! From an anecdotal point of view, since it is flip-flopping, I would guess at a traefik config issue and would turn on debug logs and honestly use gemini or similar to debug the session through logs. |
|
I'm also seeing flip-flopping with Caddy ftr |
|
I just figure I'd add to this since I have a setup where Caddy is my reverse proxy. The documentation ended up being surprisingly easy to follow. The following is the idea of what we want to happen: Client → Caddy → Authentik (auth check) → Caddy → Frigate Initial SetupFollowing the documentation, generate a secret and toss it into your Frigate config. Take that same secret, and append it to the groups you've set up in Authentik for Frigate. You'll add this to the "Attributes" section while editing the group. additionalHeaders:
X-Proxy-Secret: <copy the frigate auth_secret here>In AuthentikIn Authentik, configure an application with the provider as a Forward Auth (Single Application). Authentik gives some nice templates for use with many common reverse-proxy providers, but it's important to append X-Proxy-Secret to the list of headers sent. The following is an example of my Caddyfile: frigate.TLD {
route {
# required for authentik outpost
reverse_proxy /outpost.goauthentik.io/* http://authentik-server-1:9000
# authentication check
forward_auth http://authentik-server-1:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers \
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 \
# APPEND THIS TO THE TEMPLATE
X-Proxy-Secret
trusted_proxies private_ranges
}
# yoinking it back to frigate
reverse_proxy http://frigate:8971
}
}Additional Frigate config:Your SSO provider will be sending over some headers, as you can see above. You will need to tell Frigate what the header for the username will be, and the header that will tell it what role to assign to the user. You'll also need to tell it what Authentik Groups you've assigned for the viewer and admin roles, respectively. proxy:
auth_secret: <secret key>
separator: "|" # This value defaults to a comma, but Authentik uses a pipe, for example. CHECK WHAT THIS IS FOR YOUR RESPECTIVE APPLICATION
header_map:
user: X-Authentik-Username
role: X-Authentik-Groups
role_map:
admin:
- <authentik_frigate_admin_group>
viewer:
- <authentik_frigate_user_group>...aaaand that's pretty much it. Much less complicated than it looks! |
|
Nice! |
|
Really appreciate you for taking the time to write this up - helped me see what i had missed and now it works as expected with Traefik. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Edit: I highly recommend using another idP. Authentik team likes to release buggy and broken software then drag their feet on releasing fixes. Join their discord and see the messages of everyone complaining that they consistently break instances on updates.
The breakdown
Frigate has its own auth with user based roles:
adminandviewer. In order to make use of these roles via authentik, you must disable frigate's auth and configure a header that has one of those roles in the value. Frigate has a predefined list of header keys that can be used to pass the role/username, or you can mount a file into the frigate container to overwrite and add your own header keys (see example below).The goal is to sign in to authentik and not have to type in another password for frigate, yet frigate is still secure and retains user roles. Because frigate's built-in auth is disabled, already created users and their assigned roles will not be used, modified or deleted.
Assumptions
authentik.mydomain.comwhich points tohttps://192.168.10.10:9443internally)frigate.mydomain.comwhich points tohttps://192.168.20.20:8971internally)Frigate
Tip
To make things easy for myself, I set up a separate frigate install to test this on before running it on prod. I would highly recommend doing the same
Custom headers to pass username/role
Frigate can be configured to allow using custom header keys to set username and/or user role. This is accomplished via config and using a mount in the docker compose file.
The frigate docs example uses the same usernames between authentik and frigate. Meaning, your logged-in authentik username will be the same in frigate. You can configure and pass a different header key pair for the username. I did this to pass the user role, so if you want, you can use that method to pass frigate a username if you don't want the same username as you have in authentik.
Create the override file
Warning
The header names in this file ARE case sensitive
The default data was pulled by running:
docker exec -it frigate bash, once inside the container run:cat /usr/local/nginx/conf/proxy_trusted_headers.confproxy_trusted_headers.confin the same dir as your frigate docker compose fileEdit docker compose file
Remember to recreate the container after editing:
docker compose up -d --force-recreateConfig
As mentioned, the built-in auth must be turned off. To keep things secure, there is an extra header that frigate can be configured to receive a secret known only to the reverse proxy and frigate. Frigate will only accept requests with that secret header key pair
Note
It's essential that SSL is used to encrypt the secret in transit
Generate
auth_secretSee https://docs.frigate.video/configuration/authentication/#proxy-configuration
python3 -c 'import secrets; print(secrets.token_hex(64))'on a machine with python3 installedAuthentik
Application and provider config
Applications > ApplicationsCreate with Provider), name it, and leave the rest of the settings as default, clickNextNextAuthorization flow(I use implicit), scroll downhttps://frigate.mydomain.comhttps://192.168.20.20:8971Internal host SSL validation(unless you have a valid SSL chain for your internal host), clickNextNextSubmitOutpost config
An outpost is basically a reverse proxy protected by authentik.
Note
the authentik web GUI and the embedded outpost use the same ports, if your SSL authentik endpoint uses port 9443, so does the outpost
Applications > Outposts:authentik Embedded OutpostAvailable Applicationsand add it toSelected ApplicationsPassing the custom headers via an authentik group
Note
You can also pass custom headers using user attributes. I find groups a better fit, YMMV.
Two groups will need to be created to pass each user role:
Directory > GroupsCreatefrigate-adminorfrigate-viewer)attributes, this is where we can pass extra headers{}X-Frigate-Username: <username>if needed.Warning
The header names here ARE case sensitive
DNS
frigate.mydomain.commust point to the authentik instanceauthentik.mydomain.com, as authentik will handle auth and act as a reverse proxy.Cloudflare tunnels
Change the
frigate.mydomain.compublic hostname to point towards the internal authentik SSL endpoint (https://192.168.10.10:9443) instead of the internal frigate SSL endpoint (https://192.168.20.20:8971).How it works
Because frigate's built-in auth is turned off, you can use whatever username (even ones existing in frigates auth system) and assign it whatever role using the authentik
Groupsand theattributesadditionalHeadersconfig. You can assign yourself as admin and family members as viewers through their authentik login and which group they are a member of.Flow
frigate.mydomain.comHopefully this is clear enough to follow, if it isn't, let me know!
All reactions