starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-25 05:46:01 +03:00

[GH-ISSUE #1717] Bypass login screen with OIDC enabled #490

New issue

Open

opened 2026-02-26 18:47:16 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 18:47:16 +03:00

Owner

Originally created by @koehn on GitHub (Mar 19, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/1717

Feature Description

I use OIDC for authentication, and I'd like for my users to never need to push the "OIDC" button to login. Instead, it should simply send them to the OIDC flow.

Also, OIDC users should never be able to use the Documenso password reset functionality, as it provides a security hole (details below).

I looked for a setting to do this but couldn't find one in .env_example; apologies if there's one that I missed.

Use Case

For users of systems with external authentication (OIDC/OAuth), it could be confusing to be presented with a login screen that won't accept their credentials. Instead they all need to know to push the "OIDC" button (or whatever it's renamed to using NEXT_PRIVATE_OIDC_PROVIDER_LABEL).

Users might attempt a password reset, which would inadvertently give them a password on Documenso that's could be less secure (e.g., no 2FA) than the one they have setup with OIDC. Their Documenso account wouldn't be disabled when the OIDC system disables their account, granting them access to Documenso when they shouldn't have it.

Proposed Solution

An environment variable to enable access to the password screen whenever an external authentication system is used.
By default the password screens (login and password reset) should be disabled if an external authentication system has been configured.

Alternatives (optional)

At the very least, users from an external authentication system should not be allowed to reset/create passwords on the Documenso system. Those passwords should be disabled.

Additional Context

No response

Please check the boxes that apply to this feature request.

I have searched the existing feature requests to make sure this is not a duplicate.
I have provided a detailed description of the requested feature.
I have explained the use case or scenario for this feature.
I have included any relevant technical details or design suggestions.
I understand that this is a suggestion and that there is no guarantee of implementation.
I want to work on creating a PR for this issue if approved

Originally created by @koehn on GitHub (Mar 19, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/1717 ### Feature Description I use OIDC for authentication, and I'd like for my users to never need to push the "OIDC" button to login. Instead, it should simply send them to the OIDC flow. Also, OIDC users should never be able to use the Documenso password reset functionality, as it provides a security hole (details below). I looked for a setting to do this but couldn't find one in `.env_example`; apologies if there's one that I missed. ### Use Case For users of systems with external authentication (OIDC/OAuth), it could be confusing to be presented with a login screen that won't accept their credentials. Instead they all need to know to push the "OIDC" button (or whatever it's renamed to using `NEXT_PRIVATE_OIDC_PROVIDER_LABEL`). Users might attempt a password reset, which would inadvertently give them a password on Documenso that's could be less secure (e.g., no 2FA) than the one they have setup with OIDC. Their Documenso account wouldn't be disabled when the OIDC system disables their account, granting them access to Documenso when they shouldn't have it. ### Proposed Solution An environment variable to enable access to the password screen whenever an external authentication system is used. By default the password screens (login and password reset) should be disabled if an external authentication system has been configured. ### Alternatives (optional) At the very least, users from an external authentication system should not be allowed to reset/create passwords on the Documenso system. Those passwords should be disabled. ### Additional Context _No response_ ### Please check the boxes that apply to this feature request. - [x] I have searched the existing feature requests to make sure this is not a duplicate. - [x] I have provided a detailed description of the requested feature. - [x] I have explained the use case or scenario for this feature. - [x] I have included any relevant technical details or design suggestions. - [x] I understand that this is a suggestion and that there is no guarantee of implementation. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

status: triage

label

2026-02-26 18:47:16 +03:00

kerem commented

2026-02-26 18:47:17 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 19, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Mar 19, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem commented

2026-02-26 18:47:17 +03:00

Author

Owner

@ethan-hann commented on GitHub (Jun 27, 2025):

I think this is a good idea. Especially in an environment with less-than-tech-savvy users. Someone might try logging in with the company email and password, and then find out it doesn't work. They would then try to reset their password leading to the case mentioned by @koehn.

I'm not sure how to implement the bypassing of the login screen though, but hiding the form was easy.

I did a quick test in the code to hide the login form all together when either Google SSO or a generic OIDC provider is enabled.

Happy to contribute to the project but I'm wondering if this should be dynamically set or if we should expose an environment variable to override?

@ethan-hann commented on GitHub (Jun 27, 2025): I think this is a good idea. Especially in an environment with less-than-tech-savvy users. Someone might try logging in with the company email and password, and then find out it doesn't work. They would then try to reset their password leading to the case mentioned by @koehn. I'm not sure how to implement the bypassing of the login screen though, but hiding the form was easy. I did a quick test in the code to hide the login form all together when either Google SSO or a generic OIDC provider is enabled. Happy to contribute to the project but I'm wondering if this should be dynamically set or if we should expose an environment variable to override? ![Image](https://github.com/user-attachments/assets/187818be-0d9d-45a9-b59c-81870a159d08)

kerem commented

2026-02-26 18:47:17 +03:00

Author

Owner

@ethan-hann commented on GitHub (Sep 26, 2025):

Is this going to be considered? It would be a really useful feature to have.

@ethan-hann commented on GitHub (Sep 26, 2025): Is this going to be considered? It would be a really useful feature to have.

kerem commented

2026-02-26 18:47:17 +03:00

Author

Owner

@KarloDerEchte commented on GitHub (Nov 20, 2025):

@KarloDerEchte commented on GitHub (Nov 20, 2025): +1

kerem referenced this issue

2026-02-26 19:31:26 +03:00

[PR #497] [MERGED] fix: Error in Pricing Page Validation for Signup Now Modal #1006

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#490

No description provided.

Rows
Columns