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