[Bug]: OIDC login allows new user registration even when REGISTER_ENABLED=0

[mginfn]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

v0.25.6

RAGFlow image version

v0.25.6

Other environment information

RAGFlow installed via Helm chart

Actual behavior

I configured RAGFlow OIDC authentication following the documentation:
https://ragflow.io/docs/configurations#oauth

I also set:

REGISTER_ENABLED=0

My expectation is that user self-registration should be disabled. In this setup, only users already created in the RAGFlow database by an administrator should be allowed to log in through OIDC.

However, users who do not already exist in the database can still authenticate via OIDC and are automatically registered/created in RAGFlow.

Could you clarify whether this is the intended behavior?

Expected behavior

With REGISTER_ENABLED=0:

• Existing users can log in via OIDC.
• New users are not automatically created via OIDC.
• User accounts must be created beforehand by a RAGFlow administrator.

Steps to reproduce

Configure OIDC authentication and set REGISTER_ENABLED=0, register as a new OIDC user.

Additional information

No response

[dosubot]

Hi @mginfn! I'm Dosu and I'm helping the InfiniFlow team.

You've correctly identified the behavior — the OIDC/OAuth callback handler does not check REGISTER_ENABLED before creating new users. Looking at the code, the REGISTER_ENABLED check is only enforced on the password-based registration endpoint [1], while the OAuth/OIDC callback at /auth/oauth/<channel>/callback unconditionally calls user_register() when it encounters an email that doesn't already exist in the database [2].

So this is a gap in how the setting is applied rather than explicitly intended behavior — REGISTER_ENABLED was designed to gate email/password sign-ups but wasn't wired into the OAuth flow.

Workaround options today:

1. Restrict access at the identity provider (IdP) level — only assign the RAGFlow OIDC application to users you want to allow in.
2. Modify the callback handler to add a REGISTER_ENABLED check before the user creation block (around line 232 of api/apps/restful_apis/user_api.py) [3].

A code fix would involve adding something like:

if not REGISTER_ENABLED:
    return server_error_response(ValueError("Registration is disabled"))

before the new-user creation logic in the OAuth callback handler.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Lynn-Inf]

I don't think we need to restrict OIDC users from being auto-created in RAGFlow. Since the OIDC provider already authenticates them, allowing login and creating accounts on the fly is expected behavior — it's not the same as open public registration.

[mginfn]

Hi @Lynn-Inf, I understand the distinction between public self-registration and OIDC-based authentication, however, in my organization the OIDC provider is shared across a much larger user base than the intended RAGFlow audience. There are hundreds of valid, authenticated OIDC users, but only a small subset should be allowed to access our RAGFlow instance.
So while OIDC confirms that the user belongs to the organization, it does not necessarily mean that the user should be provisioned in RAGFlow or be allowed to consume resources there. Our RAGFlow deployment is still intentionally small, and we cannot afford to allow any authenticated organizational user to log in and automatically create an account.

[Lynn-Inf]

I think it's better to add constraints to OIDC login — e.g., only allow users with certain roles or group memberships to access RAGFlow.

[mginfn]

Hi @Lynn-Inf, what about a dedicated variable eg. OIDC_REGISTER_ENABLED, so as to keep the behaviour separate from public registration?

[Lynn-Inf]

The best way is to restrict access at the OIDC provider level by allowing only specific groups or roles. If that's not feasible, you can modify async_fetch_user_info and normalize_user_info in api/apps/auth/oidc.py to fetch group/role info and add a validation check. Alternatively, our Enterprise Edition has a whitelist feature that can also solve this.