starred/documenso

Fork 0

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

[GH-ISSUE #1090] FR: Generic OAuth OIDC option for SSO #325

New issue

Closed

opened 2026-02-26 18:46:31 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 18:46:31 +03:00

Owner

Originally created by @jinnatar on GitHub (Apr 9, 2024).
Original GitHub issue: https://github.com/documenso/documenso/issues/1090

Feature Description

Instead of implementing every OAuth provider under the sun, support standard OpenID Connect (OIDC). Most brand name providers could actually be implemented via the exact same integration giving an admin freedom to implement a provider you don't want to provide on the flagship instance.

Use Case

An organization implementing esigning on-premise is likely to have an identity provider in use and the diversity in the field is quite vast. Providing a well documented standard generic option for defining SSO gives them a way to plug it in on their own. OIDC is a modern alternative for SAML and well supported in IDMs. It's also significantly easier to configure for everyone involved than SAML.

Proposed Solution

Utilize the NextAuth OAuth provider, allowing plugging in required config values via ENV variables. To simplify, only support the "well-known" autoconfig path. (Well supported by most identity providers, even open source ones.)

The parameters that need to be collected from ENV variables are:

OIDC endpoint, i.e. the parameter to provide the next-auth wellKnown host part.
Client ID, i.e. the clientId parameter.
Client secret, i.e. the clientSecret parameter.
Provider name, i.e. how do to label the button for selecting it.

Perhaps optional to be configurable, since there are reasonable defaults:

Checks. For example state & pkce should be a reasonable default. If PKCE is not default enabled, an option needs to exist to enable it.
Scopes. openid email profile should be a reasonable default.

Alternatives (optional)

No response

Additional Context

next-auth oauth connector: https://github.com/nextauthjs/next-auth/blob/v4/packages/next-auth/src/providers/oauth.ts
Documentation: https://next-auth.js.org/configuration/providers/oauth#using-a-custom-provider

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 @jinnatar on GitHub (Apr 9, 2024). Original GitHub issue: https://github.com/documenso/documenso/issues/1090 ### Feature Description Instead of implementing every OAuth provider under the sun, support standard OpenID Connect (OIDC). Most brand name providers could actually be implemented via the exact same integration giving an admin freedom to implement a provider you don't want to provide on the flagship instance. ### Use Case An organization implementing esigning on-premise is likely to have an identity provider in use and the diversity in the field is quite vast. Providing a well documented standard generic option for defining SSO gives them a way to plug it in on their own. OIDC is a modern alternative for SAML and well supported in IDMs. It's also significantly easier to configure for everyone involved than SAML. ### Proposed Solution Utilize the NextAuth OAuth provider, allowing plugging in required config values via ENV variables. To simplify, only support the "well-known" autoconfig path. (Well supported by most identity providers, even open source ones.) The parameters that need to be collected from ENV variables are: - OIDC endpoint, i.e. the parameter to provide the next-auth `wellKnown` host part. - Client ID, i.e. the `clientId` parameter. - Client secret, i.e. the `clientSecret` parameter. - Provider name, i.e. how do to label the button for selecting it. Perhaps optional to be configurable, since there are reasonable defaults: - Checks. For example `state` & `pkce` should be a reasonable default. If PKCE is not default enabled, an option needs to exist to enable it. - Scopes. `openid email profile` should be a reasonable default. ### Alternatives (optional) _No response_ ### Additional Context - next-auth oauth connector: https://github.com/nextauthjs/next-auth/blob/v4/packages/next-auth/src/providers/oauth.ts - Documentation: https://next-auth.js.org/configuration/providers/oauth#using-a-custom-provider ### 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

2026-02-26 18:46:31 +03:00

closed this issue
added the
status: triage
label

kerem commented

2026-02-26 18:46:31 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 9, 2024):

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 (Apr 9, 2024): 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:46:31 +03:00

Author

Owner

@tankerkiller125 commented on GitHub (Apr 12, 2024):

Digging into some of the code, this looks simple enough I might try implementing it myself this weekend. (It's been years since I touched NodeJS projects, but this looks pretty straight forward the more I look at it.

Once of the questions I have though, would it make sense to support an array of OIDC providers? So instead of only defining a single OIDC provider, you could define several?

@tankerkiller125 commented on GitHub (Apr 12, 2024): Digging into some of the code, this looks simple enough I might try implementing it myself this weekend. (It's been years since I touched NodeJS projects, but this looks pretty straight forward the more I look at it. Once of the questions I have though, would it make sense to support an array of OIDC providers? So instead of only defining a single OIDC provider, you could define several?

kerem commented

2026-02-26 18:46:31 +03:00

Author

Owner

@jinnatar commented on GitHub (Apr 12, 2024):

That could make sense for a more public instance such as the flagship. I imagine though that hobbyists and various organizations tend to have only one provider in use.

@jinnatar commented on GitHub (Apr 12, 2024): That could make sense for a more public instance such as the flagship. I imagine though that hobbyists and various organizations tend to have only one provider in use.

kerem commented

2026-02-26 18:46:32 +03:00

Author

Owner

@tankerkiller125 commented on GitHub (Apr 16, 2024):

I think that most orgs only have one provider, but with Microsoft now doing their "Multi-Tenant Orgs" feature available in public preview, I know of several orgs that intend to split out their Azure AD by division/sub-companies, which would require multiple OIDC providers if they shared a single documenso install.

With that said, for now I've created the PR with a single provider in mind since that should cover most orgs that would be looking to use documenso I think, along with general home self-hosters that have SSO implementations.

@tankerkiller125 commented on GitHub (Apr 16, 2024): I think that most orgs only have one provider, but with Microsoft now doing their "Multi-Tenant Orgs" feature available in public preview, I know of several orgs that intend to split out their Azure AD by division/sub-companies, which would require multiple OIDC providers if they shared a single documenso install. With that said, for now I've created the PR with a single provider in mind since that should cover most orgs that would be looking to use documenso I think, along with general home self-hosters that have SSO implementations.

kerem referenced this issue

2026-02-26 19:30:52 +03:00

[PR #325] [MERGED] docs: fix typo in CONTRUBUTING.md #877

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#325

No description provided.

Rows
Columns