[Discussion] Which OAuth providers need more configuration?

[Meldiron]

Background

In the past couple of weeks, we have made an effort to improve our Project API (used in the Console and CLI), with the aim of allowing all server SDKs to have capabilities such as managing project platforms, webhooks, auth security settings, and more.

Managing connected OAuth applications was one of our focus areas, and we made multiple improvements, including:

1. Separate methods for each provider, so IDE autocomplete is better. For example: project.updateOAuth2GitHub({ enabled: true })
2. Parameter names terminology accurate with each provider, making it easier to know which value belongs where. For example: project.updateOAuth2Dropbox({ appKey, appSecret }) (Commonly it's Client ID and Client Secret, but Dropbox chose different terminology)
3. Documentation for parameters and response models to include sample values, so it's even easier to recognize where each value belongs. For example: 'Client ID' of Bitly OAuth2 app. For example: d95151000000000000000000000000000067af9b

Advanced OAuth2 configuration

Thanks to community feedback, we noticed some OAuth behaviors are not strictly defined by the standard. A great example is the Google OAuth2 provider, which has a custom parameter called prompt=select_account. It controls whether the OAuth2 flow remembers the last chosen account and automatically uses it for sign-in, or if the user is asked to select an account every time. Having this configured can be extra friction for some, but it is a necessary feature when customers often use multiple accounts.

Share your insights

While prompt parameter specifically is part of OIDC standard and there are more insights we can already gain from there, we are certain there are more edge cases like these really specific problems solved by really specific implementations.

Please share with us the OAuth2 providers you are using and any specific configuration you lack the ability to control when implementing with Appwrite. The new endpoint structure, combined with your feedback, is exactly what allows us to make Appwrite focused on a great developer experience.

[hardikkaurani]

Really good direction overall. OAuth integrations are one of those areas where “standardized in theory” still ends up highly provider-specific in practice, so exposing provider-aware configuration APIs is a big DX improvement.

The move toward explicit provider methods like:

project.updateOAuth2GitHub()
project.updateOAuth2Dropbox()

instead of generic config blobs should make integrations much easier to understand, especially when combined with provider-specific terminology and example values.

A few OAuth/OIDC edge cases that would be extremely useful to configure:

Google

Google is probably the biggest one because its behavior varies heavily depending on the app type and user flow.

Useful controls:

• prompt=select_account
• prompt=consent
• access_type=offline
• incremental auth scopes
• hosted domain restriction (hd)
• forcing account chooser behavior
• login hint support

Especially for multi-account users, select_account becomes important very quickly.

Related:

• [Google OAuth Docs](https://developers.google.com/identity/protocols/oauth2?utm_source=chatgpt.com)

---

Microsoft / Azure AD

Microsoft auth flows can become surprisingly complex in enterprise environments.

Useful controls:

• tenant selection (common, organizations, tenant-specific IDs)
• single-tenant vs multi-tenant apps
• login hints
• conditional access compatibility
• PKCE enforcement
• prompt behavior
• incremental consent

Related:

• [Microsoft Identity Platform Docs](https://learn.microsoft.com/en-us/entra/identity-platform/?utm_source=chatgpt.com)

---

GitHub

GitHub is simpler overall, but some controls are still valuable:

• org restriction
• enterprise GitHub instances
• device flow support
• optional re-consent prompts
• fine-grained scope management

Related:

• [GitHub OAuth Apps Docs](https://docs.github.com/en/apps/oauth-apps?utm_source=chatgpt.com)

---

Discord

A common issue with Discord auth is missing refresh-token flexibility and guild-related scopes.

Useful controls:

• guild join permissions
• forced re-auth
• bot + OAuth combined flows
• prompt behavior

---

Apple Sign In

Apple has several non-obvious implementation quirks:

• private relay email handling
• nonce validation
• response mode configuration
• JWT signing key rotation
• strict redirect URL validation

This provider usually benefits from extra documentation/examples more than most others.

Related:

• [Sign in with Apple Docs](https://developer.apple.com/sign-in-with-apple/?utm_source=chatgpt.com)

---

Generic OIDC Providers

For self-hosted enterprise IdPs and regional providers, advanced OIDC controls become very important:

• custom scopes
• discovery URL override
• JWKS refresh behavior
• claim mapping
• role/group mapping
• custom authorization params
• clock skew tolerance
• logout endpoint behavior

This becomes especially valuable for:

• Keycloak
• Authentik
• Okta
• Auth0
• GitHub Enterprise
• internal enterprise IdPs

---

One thing that could become extremely powerful long-term would be exposing a low-level “advanced params” object for providers while still keeping typed provider APIs.

Something like:

project.updateOAuth2Google({
  enabled: true,
  clientId,
  clientSecret,
  advanced: {
    prompt: "select_account",
    access_type: "offline",
    hd: "company.com"
  }
})

That preserves good DX while still allowing provider-specific flexibility without waiting for SDK updates every time a provider introduces new behavior.

Overall this seems like a really strong direction for improving OAuth developer experience, especially for production apps with enterprise auth requirements and multi-provider setups.

[krishkhinchi]

Really nice direction. Having provider-specific methods and parameter names makes the API much easier to understand compared to generic OAuth configs.

One thing that would be very useful is support for provider-specific extra params/scopes without needing workarounds. Examples:

• Google → prompt=select_account, access_type=offline
• Discord → forcing guild/member scopes
• Microsoft → tenant-specific auth
• GitHub → fine-grained scope handling

A flexible additionalParams or provider-specific advanced config object could help cover many edge cases without constantly changing the API surface.

---

If this answer solve your all doubts so can you please mark my answer as solved
or if did not solved yet so please tell me your doubt