🔖 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?
🏢 Have you read the Code of Conduct?
🔖 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:
bb9b19e0-...adminownera1b2c3d4-...developermemberguestmemberDuring OAuth login, Appwrite reads the
groupsclaim 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:
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?
🏢 Have you read the Code of Conduct?