[BUG] Can't seem to get OIDC groups rules to work

Describe the bug
I did setup Tinyauth and Pocket ID, everything seems to be working, except for the fact that no matter what groups I specify in the container labels the users can always access the resources, even if they don't have the group.

To Reproduce
Traefik container with dashboard protected by Tinyauth:

container_name: traefik
image: traefik:v3.6.5
labels:
      - wud.watch=true
      - wud.tag.include=^v\d+\.\d+\.\d+$$
      - wud.link.template=https://github.com/traefik/traefik/releases/tag/v$${major}.$${minor}.$${patch}
      - traefik.enable=true
      - traefik.http.routers.traefik.rule=Host(`traefik.${DOMAIN}`)
      - traefik.http.routers.traefik.service=api@internal
      - traefik.http.routers.traefik.middlewares=tinyauth
      - tinyauth.apps.traefik.config.domain=traefik.${DOMAIN}
      - tinyauth.apps.traefik.oauth.groups=admins
networks:
  - proxy
ports:
  - target: 80
    published: 80
    mode: host
  - target: 443
    published: 443
    mode: host
volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - /srv/config/traefik/traefik.yml:/etc/traefik/traefik.yml:ro
  - /srv/config/traefik/routes.yml:/etc/traefik/routes.yml:ro
  - /srv/letsencrypt:/letsencrypt
  - /srv/log/traefik:/var/log/traefik
restart: always

Tinyauth container:

container_name: tinyauth
image: ghcr.io/steveiliop56/tinyauth:v4
labels:
  - traefik.enable=true
  - traefik.http.routers.tinyauth.rule=Host(`auth.${DOMAIN}`)
  - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik
environment:
  - APP_URL=https://auth.${DOMAIN}
  - PROVIDERS_POCKETID_AUTH_URL=https://id.${DOMAIN}/authorize
  - PROVIDERS_POCKETID_CLIENT_ID=${CLIENT_ID}
  - PROVIDERS_POCKETID_CLIENT_SECRET=${CLIENT_SECRET}
  - PROVIDERS_POCKETID_REDIRECT_URL=https://auth.${DOMAIN}/api/oauth/callback/pocketid
  - PROVIDERS_POCKETID_SCOPES=openid profile email groups
  - PROVIDERS_POCKETID_TOKEN_URL=https://id.${DOMAIN}/api/oidc/token
  - PROVIDERS_POCKETID_USER_INFO_URL=https://id.${DOMAIN}/api/oidc/userinfo
  - PROVIDERS_POCKETID_NAME=Pocket ID
  - OAUTH_AUTO_REDIRECT=pocketid
networks:
  - proxy
volumes:
  - tinyauth_data:/data

Authentication is being required as expected, but it is allowing users even if they don't have the admins group.

Also, just curious, why do we need to specify tinyauth.apps.[app].config.domain? I understand this is how it matches the [app] name on the labels, but it feels redundant, I assume this could be accomplished in a different way. Like wud for example, you can just define the same labels in each container and don't need any custom label name per container.

Expected behavior
It should filter and block users that don't have the required role.

Screenshots
N/A

Logs
N/A

Device (please complete the following information):

OS: [e.g. iOS] Alpine Linux on Docker
Browser [e.g. chrome, safari] Zen / Firefox
Tinyauth [e.g. v2.1.1] v2.6.1
Docker [e.g. 27.3.1] v28.3.3

**
Additional context
Add any other context about the problem here.

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

Create Plan

Examples

_{You can configure auto-planning by selecting labels in the issue_enrichment configuration.}

🔗 Similar Issues

Possible Duplicates

[BUG] v4 subdomain detection with oauth groups issue #399

Related Issues

🔗 Related PRs

#329 - refactor: unify labels [merged]
#337 - feat: header based acls [merged]
#340 - revert: "feat: header based acls" [merged]
#422 - feat: ACL labels from environment variables [merged]

👤 Suggested Assignees

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

You need to add the docker socket as a volume to the Tinyauth container. Check here.

You need to add the docker socket as a volume to the Tinyauth container. Check here.

Oh yeah, that makes total sense, can't believe I missed that 🤦🏻

Also, do you have any comment on my other question above?

Also, just curious, why do we need to specify tinyauth.apps.[app].config.domain? I understand this is how it matches the [app] name on the labels, but it feels redundant, I assume this could be accomplished in a different way. Like wud for example, you can just define the same labels in each container and don't need any custom label name per container.

Initially Tinyauth only used the container name to match with the subdomain and only one set of labels was allowed. In v4 I changed my approach to allow multiple labels per app. This way you can put all of the labels on the Tinyauth container itself if for example the target apps are not running with docker. As for the redundancy, generally you only need the tinyauth.apps.[app] and Tinyauth will be able to match everything perfectly. But, I tend to recommend the config option more because you specificy the domain directly and you don't need any matching logic. Realistically they are both the same though.

Initially Tinyauth only used the container name to match with the subdomain and only one set of labels was allowed. In v4 I changed my approach to allow multiple labels per app. This way you can put all of the labels on the Tinyauth container itself if for example the target apps are not running with docker. As for the redundancy, generally you only need the tinyauth.apps.[app] and Tinyauth will be able to match everything perfectly. But, I tend to recommend the config option more because you specificy the domain directly and you don't need any matching logic. Realistically they are both the same though.

Ok, makes sense, thanks!

Navigation Menu

Repository navigation

[BUG] Can't seem to get OIDC groups rules to work #530

📝 CodeRabbit Plan Mode

🔗 Similar Issues

🔗 Related PRs

👤 Suggested Assignees

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Can't seem to get OIDC groups rules to work #530

Description

Activity

coderabbitai commented on Dec 18, 2025

📝 CodeRabbit Plan Mode

🔗 Similar Issues

🔗 Related PRs

👤 Suggested Assignees

steveiliop56 commented on Dec 18, 2025

dougmaitelli commented on Dec 18, 2025

steveiliop56 commented on Dec 19, 2025

dougmaitelli commented on Dec 19, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions