[REQUEST] Generic OAUTH support in app/helm/deployment

[Lutherwaves]

Feature Request: Generic OAuth Provider Support

Is your feature request related to a problem? Please describe.

The sim Helm chart currently only supports Google and GitHub OAuth providers through built-in Better Auth integrations. Many organizations use other OAuth providers (Auth0, Okta, Keycloak, custom OIDC providers) and cannot configure them without modifying application code. This limits deployment flexibility and requires code changes for each new OAuth provider.

Describe the solution you'd like

Add generic OAuth provider support in the Helm chart, similar to how openwebui handles OAuth. This should:

1. Add environment variables for generic OAuth configuration:

   • OAUTH_CLIENT_ID - OAuth client ID
   • OAUTH_CLIENT_SECRET - OAuth client secret
   • OAUTH_AUTHORIZATION_URL - Authorization endpoint URL (e.g., https://your-domain.auth0.com/authorize)
   • OAUTH_TOKEN_URL - Token endpoint URL (e.g., https://your-domain.auth0.com/oauth/token)
   • OAUTH_USERINFO_URL - User info endpoint URL (e.g., https://your-domain.auth0.com/userinfo)
   • OAUTH_SCOPES - OAuth scopes (default: openid profile email)
   • OAUTH_PROVIDER_ID - Provider identifier for Better Auth's genericOAuth plugin (e.g., auth0, okta, custom)

2. Support both direct value configuration and Kubernetes secret references (like openwebui):

   app:
     env:
       OAUTH_CLIENT_ID: ""  # Direct value
       # OR via secret reference (to be implemented in templates)
   

3. Update values.schema.json to include validation for these new OAuth environment variables.

4. Update the application deployment templates to pass these environment variables to the pods.

This enables users to configure any OAuth 2.0/OIDC provider (Auth0, Okta, Keycloak, etc.) without code changes, using Better Auth's genericOAuth plugin.

Describe alternatives you've considered

1. Adding provider-specific configs (Auth0, Okta, etc.) - This approach doesn't scale well and would require chart updates for each new provider.

2. Hardcoding provider URLs in application code - This reduces flexibility and requires code changes for each deployment.

3. Using only built-in providers (Google/GitHub) - This doesn't meet enterprise requirements for custom identity providers.

Example configuration

app:
  env:
    OAUTH_CLIENT_ID: "your-oauth-client-id-here"
    OAUTH_CLIENT_SECRET: "your-oauth-client-secret-here"
    OAUTH_AUTHORIZATION_URL: "https://your-domain.auth0.com/authorize"
    OAUTH_TOKEN_URL: "https://your-domain.auth0.com/oauth/token"
    OAUTH_USERINFO_URL: "https://your-domain.auth0.com/userinfo"
    OAUTH_SCOPES: "openid profile email"
    OAUTH_PROVIDER_ID: "auth0"

[waleedlatif1]

@Lutherwaves will look into this, but feel free to make a PR if this is a blocker for you :) sounds like a great addition

[Lutherwaves]

@Lutherwaves will look into this, but feel free to make a PR if this is a blocker for you :) sounds like a great addition

Not a blocker at all, but is a super common feature across OSS projects like this. If I find some time I'll put a PR.

[Lutherwaves]

I find the openwebui approach a good balance of features/complexity - something to check out @waleedlatif1:

• https://docs.openwebui.com/getting-started/env-configuration/#oauth
• https://docs.openwebui.com/features/auth/sso/

[Lutherwaves]

@waleedlatif1 I actually found what I can use for login with Auth0 through the https://github.com/simstudioai/sim/blob/main/apps/sim/lib/env.ts#L221 env variables, however by chance having a generic OAuth Integration support is also something I need.

Two birds with one stone 🐦 🐦

[51doge51]

Yes, all this helped.