feat: OAuth Provider Group-to-Appwrite Team Mapping

[alexfreeman90]

🔖 Enhancement description

Add configurable mapping between OAuth provider groups (Azure AD, Google Workspace, Okta, GitHub) and Appwrite Teams, evaluated automatically during OAuth login.

Current behavior: Appwrite creates a session from OAuth but ignores the user's group memberships from the identity provider. Developers must separately call provider APIs (e.g., Microsoft Graph) from application code to check groups and manually manage Appwrite Team assignments.

Proposed behavior: In Console (Auth → Settings → OAuth Provider), admins configure a group-to-team mapping:

Provider Group ID	Appwrite Team	Role
bb9b19e0-...	admin	owner
a1b2c3d4-...	developer	member
(default)	guest	member

During OAuth login, Appwrite reads the groups claim from the ID token (or calls the provider's group API if unavailable), then adds/updates the user's team memberships automatically.

Optional toggle: "Deny login if user is not in any configured group"

🎤 Pitch

Group-based access control is standard in enterprise identity management. Every Appwrite project using enterprise SSO currently re-implements the same workaround: store provider API credentials in the app, call Graph API after session creation, manually sync teams.

This has real problems:

• Provider API secrets live in the app layer instead of Appwrite
• Sessions are created before group checks, creating a race condition
• No automatic sync — membership only updates if the developer builds it
• Every project duplicates the same logic

Auth0 (Actions/Rules), Keycloak (group-to-role mapping), and Firebase (custom claims from OIDC) all solve this natively. Adding this to Appwrite would eliminate application-side provider API calls, centralize credential management, and make Appwrite a stronger choice for enterprise SSO.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[aniruddhaadak80]

Hello @alexfreeman90,

Thanks for opening this up! Usually, with these kinds of underlying issues, the first step is double-checking if there is a minor version mismatch in your installed environment tooling vs the actual framework requirements.

Have you tried outright clearing the respective local build/cache directories, forcing a clean slate reinstall, and ruling out any implicit breaking changes from recent patches?

If you are still hitting the exact same bottleneck, dropping a minimal reproduction steps (or specifically the raw error logs) here usually gets it sorted out way faster by the maintainers.

Hope this helps point you in the right direction. Let me know if you make any progress!