How to: Use authentik for SSO and assign user roles (admin / viewer).

[baudneo]

The breakdown

Frigate has its own auth with user based roles: admin and viewer. 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 is installed: public facing with SSL, users setup and working for other applications: (this example uses authentik.mydomain.com which points to https://192.168.10.10:9443 internally)
• frigate is installed: public facing with SSL: (this example uses frigate.mydomain.com which points to https://192.168.20.20:8971 internally)

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.conf

• open and edit a file named: proxy_trusted_headers.conf in the same dir as your frigate docker compose file
  • add the default data and then add the custom headers at the end

# Header used to validate reverse proxy trust
proxy_set_header X-Proxy-Secret $http_x_proxy_secret;

# these headers will be copied to the /auth request and are available
# to be mapped in the config to Frigate's remote-user header

# List of headers sent by common authentication proxies:
# - Authelia
# - Traefik forward auth
# - oauth2_proxy
# - Authentik

proxy_set_header Remote-User $http_remote_user;
proxy_set_header Remote-Groups $http_remote_groups;
proxy_set_header Remote-Email $http_remote_email;
proxy_set_header Remote-Name $http_remote_name;
proxy_set_header X-Forwarded-User $http_x_forwarded_user;
proxy_set_header X-Forwarded-Groups $http_x_forwarded_groups;
proxy_set_header X-Forwarded-Email $http_x_forwarded_email;
proxy_set_header X-Forwarded-Preferred-Username $http_x_forwarded_preferred_username;
proxy_set_header X-authentik-username $http_x_authentik_username;
proxy_set_header X-authentik-groups $http_x_authentik_groups;
proxy_set_header X-authentik-email $http_x_authentik_email;
proxy_set_header X-authentik-name $http_x_authentik_name;
proxy_set_header X-authentik-uid $http_x_authentik_uid;
# custom headers to pass role (and username if you need)
proxy_set_header X-Frigate-Role $http_x_frigate_role;
proxy_set_header X-Frigate-Username $http_x_frigate_username;

Edit docker compose file

Remember to recreate the container after editing: docker compose up -d --force-recreate

    volumes:
      # example data
      - ./certs:/etc/letsencrypt/live/frigate:ro
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - /frigate:/media/frigate
      # add the headers file
      - ./proxy_trusted_headers.conf:/usr/local/nginx/conf/proxy_trusted_headers.conf

Config

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_secret

See https://docs.frigate.video/configuration/authentication/#proxy-configuration

• execute and save the output from: python3 -c 'import secrets; print(secrets.token_hex(64))' on a machine with python3 installed

auth:
  enabled: false  
proxy:
  auth_secret: <from the saved python output>
  # header names here are case insensitive
  header_map:
    # this will use the authentik username
    user: x-authentik-username
    # the custom header for user role
    role: x-frigate-role

    # if using the custom header for username
    #user: x-frigate-username

• restart frigate

Authentik

Application and provider config

• login to the admin interface, navigate to Applications > Applications
• click (Create with Provider), name it, and leave the rest of the settings as default, click Next
• select 'Proxy Provider', click Next
• this is now the provider configuration, select an Authorization flow (I use implicit), scroll down
• enter the external and internal hosts
  • external should be the public facing domain: https://frigate.mydomain.com
  • internal should be the authorized endpoint (default port: 8971) as the unauthenticated (default port: 5000) endpoint does not support user roles: https://192.168.20.20:8971
• disable Internal host SSL validation (unless you have a valid SSL chain for your internal host), click Next
• this is now the binding config, leave it as is, click Next
• click Submit

Outpost 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

• navigate to Applications > Outposts:
• click the edit button for the authentik Embedded Outpost
• find your newly configured frigate proxy application in the Available Applications and add it to Selected Applications
• click 'Update'

Passing 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:

• navigate to: Directory > Groups
• click Create
• name the group (ie. frigate-admin or frigate-viewer)
• leave the defaults except for attributes, this is where we can pass extra headers
  • I prefer YAML, the code box accepts JSON or YAML, the default is an empty JSON entry of {}
  • optional: add X-Frigate-Username: <username> if needed.

Warning

The header names here ARE case sensitive

additionalHeaders:
  X-Frigate-Role: admin
  X-Proxy-Secret: <copy the frigate auth_secret here>

• repeat for the other user role
• edit both groups to add users to the groups

DNS

frigate.mydomain.com must point to the authentik instance authentik.mydomain.com, as authentik will handle auth and act as a reverse proxy.

Cloudflare tunnels

Change the frigate.mydomain.com public 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 Groups and the attributes additionalHeaders config. You can assign yourself as admin and family members as viewers through their authentik login and which group they are a member of.

Flow

• client requests frigate.mydomain.com
• lands at the authentik endpoint
  • authentik handles auth
    • if not already logged in, you will be asked to login
    • if logged in, you are passed through
  • once authorized, authentik proxies the requests to the frigate endpoint that has auth turned off (but is using SSL and a secret header that only authentik and frigate know).

Hopefully this is clear enough to follow, if it isn't, let me know!

[shannonyea]

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?

[baudneo]

No issues with my setup at all. I haven't seen that behavior.

What version are you running? I've tested this setup on 0.16.0, 0.16.1 and dev branch 0.17.x builds so far. Even the Hass notification proxy endpoints work.

[shannonyea]

I'm running version 0.16.0-678ae87, I'm using the the frigate:678ae87 docker image for compatibility with Hailo.

[baudneo]

Hmm. I would assume it's something to do with the producing by nginx. I use CloudFlared as external to internal proxy and have 0 issues this far.

I would check your nginx config and logs tonsee if something strange is happening.

[shannonyea]

Thank you for the advice, I believe I may have fixed the issue.

In my case I was using NPM (Nginx Proxy Manager) and i enabled the "Cache Assets" feature, this seemed to have been causing issues and disabling it on the proxy caused the review images to be loaded properly.

I believe this may be a result of the API changes for the review items made in 0.16.0 and the image caching was causing issues.