[BUG] Groups-only OAuth access still denied under `ACLS_POLICY=deny`

[zhorvath83]

Describe the Bug

After upgrading to v5.1, apps configured with only OAUTH_GROUPS (no OAUTH_WHITELIST) deny all OAuth users.

On v5.1.1-rc.1 the problem is only partially fixed: it works with the default allow policy, but with TINYAUTH_AUTH_ACLS_POLICY=deny the exact original symptom is still present. An app that has only OAUTH_GROUPS set (no per-app OAUTH_WHITELIST) denies every OAuth user — including users who are members of the allowed group. The /.*/ whitelist workaround from #1009 is still required per app.

Possibly related: with a deny policy and no global OAUTH_WHITELIST, login itself is also refused ("Email not whitelisted") until a global OAUTH_WHITELIST=/.*/ is set. This one may well be intended deny-by-default for login, but it looks like the same "empty whitelist" handling, so I'm noting it in case the two are meant to behave consistently.

How to Reproduce

1. TINYAUTH_AUTH_ACLS_POLICY=deny
2. Configure an app with a group ACL and no whitelist:

   TINYAUTH_APPS_MYAPP_CONFIG_DOMAIN=myapp.example.org
   TINYAUTH_APPS_MYAPP_OAUTH_GROUPS=myapp_users
   

3. Log in as an OAuth user who is a member of myapp_users.
4. Result: access denied — "User is not allowed to access resource".
5. Add TINYAUTH_APPS_MYAPP_OAUTH_WHITELIST=/.*/ → access works again (the [BUG] OAuth groups access control broken in v5.1.0 - empty app OAuth whitelist denies access #1009 workaround).
6. For contrast, set TINYAUTH_AUTH_ACLS_POLICY=allow with the step-2 config → access works.

Expected Behavior

Setting only OAUTH_GROUPS should be enough — an OAuth user in the allowed group should be permitted regardless of ACLS_POLICY, without also having to set OAUTH_WHITELIST (or /.*/).
The empty-whitelist = "not configured" behavior from #1010 should apply under a deny policy too, at both the login gate and the per-app check.

Additional Context

• Reproduced on v5.1.1-rc.1 (distroless), Kubernetes + Pocket-ID as the OIDC provider.
• With ACLS_POLICY=deny, working config currently requires both a global OAUTH_WHITELIST=/.*/ and a per-app OAUTH_WHITELIST=/.*/ on every app, on top of the intended OAUTH_GROUPS.

Logs

Per-app check:

{"level":"warn","stream":"app","user":"<user>","resource":"<host>","message":"User is not allowed to access resource"}

Login gate:

{"level":"warn","stream":"app","email":"<email>","message":"Email not whitelisted, denying access"}
{"level":"warn","stream":"audit","event":"login","result":"failure","reason":"email not whitelisted"}

Operating System

macOS

Browser

Arc

Tinyauth Version

v5.1.1-rc.1

Docker Version (if applicable)

K8s

Human Written Confirmation

• I confirm this issue was written by me and not generated by an LLM or AI assistant.

[dosubot]

Hi @zhorvath83! I'm Dosu and I'm helping the Tinyauth team.

There are actually two separate issues at play here, and they have different root causes:

1. Per-app access check ("User is not allowed to access resource")

The fix in PR #1010 / v5.1.1-rc.1 changed RuleUserAllowed so that an empty OAUTH_WHITELIST returns EffectAbstain instead of EffectDeny [1]. This correctly lets RuleOAuthGroup evaluate group membership afterward [2]. However, under ACLS_POLICY=deny, EffectAbstain is resolved to deny by the policy engine's effectToAccess function [3]. So even though the whitelist rule now correctly abstains, the deny policy converts that abstention into a denial — and since RuleUserAllowed is evaluated before RuleOAuthGroup in the rule chain [3], a deny result from the whitelist check short-circuits before the group check ever runs.

This means the fix works under ACLS_POLICY=allow (abstain → allow → group check proceeds) but not under ACLS_POLICY=deny (abstain → deny → short-circuit). The group rule never gets a chance to allow the user.

2. Login gate ("Email not whitelisted")

This one is by design. The login-time email check in IsEmailWhitelisted also returns EffectAbstain when the global OAUTH_WHITELIST is empty [4], and the policy engine converts that to denial under a deny policy [5]. Under deny-by-default, an empty global whitelist effectively means "no one is explicitly allowed to log in." This is consistent with deny-policy semantics, though it does mean a global OAUTH_WHITELIST=/.*/ (or specific emails) is required to let users through the login gate.

Summary: The core problem for the per-app check is that EffectAbstain from an empty whitelist gets short-circuited to denial under deny policy before the group rule can run. A potential fix would be to have the empty OAuth whitelist return EffectAllow (rather than EffectAbstain) when groups are configured on the same app — or to change the rule evaluation so that abstention from the whitelist check doesn't short-circuit the group check. The current workaround of OAUTH_WHITELIST=/.*/ remains necessary under deny policy.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[steveiliop56]

@zhorvath83 correct me if I am wrong but this mostly a feature rather than a bug.

In a deny-by-default approach, you need to be super explicit on who you allow and apart from the groups and IP controls which follow an allow-on-empty approach, everything else strictly denies when the whitelist is empty. In your case, you would need to both allow the emails in TINYAUTH_OAUTH_WHITELIST and in the ACLs if you want a deny-by-default setup. There is no way to allow an empty whitelist and still call it deny-by-default even if your OAuth users are controlled with groups. I believe the solution you are currently using with the regex is fitting for your setup.