New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Generic OAuth OIDC option for SSO #1090
Comments
Thank you for opening your first issue and for being a part of the open signing revolution! |
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? |
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. |
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. |
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:
wellKnown
host part.clientId
parameter.clientSecret
parameter.Perhaps optional to be configurable, since there are reasonable defaults:
state
&pkce
should be a reasonable default. If PKCE is not default enabled, an option needs to exist to enable it.openid email profile
should be a reasonable default.Alternatives (optional)
No response
Additional Context
Please check the boxes that apply to this feature request.
The text was updated successfully, but these errors were encountered: