In TinyAuth v5, there is currently no built-in feature to apply group-based access control directly on OIDC clients. Any authenticated user can be authorized for any registered OIDC client.

What OIDC Client Configuration Supports#

The only configurable options per OIDC client are:

TINYAUTH_OIDC_CLIENTS_<NAME>_CLIENTID=...
TINYAUTH_OIDC_CLIENTS_<NAME>_CLIENTSECRET=...
TINYAUTH_OIDC_CLIENTS_<NAME>_TRUSTEDREDIRECTURIS=...
TINYAUTH_OIDC_CLIENTS_<NAME>_NAME=...

There is no LDAP_GROUPS or equivalent restriction setting per OIDC client. The TINYAUTH_APPS_<APP>_LDAP_GROUPS setting applies only to forward auth (proxy-based) apps, not to OIDC clients.

How LDAP Groups Are Handled#

LDAP group information is passed through as a groups claim in the OIDC token. TinyAuth itself does not filter based on groups — it delegates that decision to the downstream OIDC client. The group query is hardcoded as (&(objectclass=groupOfUniqueNames)(uniquemember=%s)), optimized for LLDAP.

Example LDAP configuration for LLDAP:

TINYAUTH_LDAP_ADDRESS=ldap://lldap:3890
TINYAUTH_LDAP_BINDDN=uid=tinyauth,ou=people,dc=example,dc=com
TINYAUTH_LDAP_BINDPASSWORD=<password>
# OR use a file path (e.g., for Docker/Kubernetes secrets):
# TINYAUTH_LDAP_BINDPASSWORDFILE=/run/secrets/ldap_password
TINYAUTH_LDAP_BASEDN=dc=example,dc=com
TINYAUTH_LDAP_SEARCHFILTER=(uid=%s)
TINYAUTH_LDAP_GROUPCACHETTL=900

Note: You can supply the LDAP bind password either directly via TINYAUTH_LDAP_BINDPASSWORD or via a file path using TINYAUTH_LDAP_BINDPASSWORDFILE. Use only one of these options, not both. The file-based option is useful for better security practices, such as mounting secrets from Kubernetes, Docker secrets, or other secret management systems.

Alternative Approaches#

1. Control on the downstream OIDC client side: Request the groups scope, then check whether the groups claim in the ID token includes family and enforce access accordingly.
2. Control via forward auth: Place a reverse proxy in front of the OIDC client and use TINYAUTH_APPS_<APP>_LDAP_GROUPS=family to restrict access.
3. Use deny-by-default ACL policy: As of TinyAuth v5, you can configure a deny-by-default ACL policy that affects access to all apps globally. Set auth.acls.policy: deny in your configuration (or TINYAUTH_AUTH_ACLS_POLICY=deny via environment variable). When set to deny, access to apps will be blocked by default unless explicitly allowed via other ACL rules. The default value is allow (allow-by-default) for backward compatibility. This global policy determines the outcome when ACL rules abstain from making a decision.

The most practical current solution is to implement group claim validation (groups claim containing family) on the OIDC client side, or use the deny-by-default ACL policy in combination with explicit allow rules for your app.